Dirspell and cdspell don't work when dealing with non-unixy filesystem structures

[Matteo Paolini]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='msys' -DCONF_MACHTYPE='x86_64-pc-msys'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS   -I.  -I. -I./include -I./lib
 -DWORDEXP_OPTION -Wno-discarded-qualifiers -march=x86-64
-mtune=generic -O2 -pipe -Wno-parentheses -Wno-format-security
-D_STATIC_BUILD -g
uname output: MINGW64_NT-10.0-22000 Ramanujan 3.3.3-341.x86_64
2022-01-17 11:45 UTC x86_64 Msys
Machine Type: x86_64-pc-msys

Bash Version: 4.4
Patch Level: 23
Release Status: release

Description:
In Git Bash, Windows volumes are represented as /.
This peculiarity appears to break the 'dirspell' and 'cdspell' options,
which fail when they try to correct a directory path which does not
follow the traditional unixy filesystem structure,
such as having users' home directories in '/home', even though a
possibly valid path might be available.

Repeat-By:
Consider this example proposed in this answer
https://stackoverflow.com/a/6438632:
1. open Git Bash an make sure sure that the current working directory
contains a drive letter in its path;
2. create a directory named 'spam/eggs' and a non-empty file 'spam/test';
3. ensure that the shell options 'dirspell', 'cdspell' and 'direxpand'
are active;
4. type the 'cat' command, giving it the test file's path as argument
and intentionally misspelling 'spam', then try to auto-complete the file's path;
5. try to 'cd' into 'spam/eggs/', but intentionally misspelling 'spam'.

You will notice that both steps 4 and 5 fail, even though they should
work on a proper Unix-like system.

Fix:
Workaround for the user: create symbolic links that follow the typical
unixy filesystem structure and point them to the directories you
usually use.
For instance, create a symbolic link named 'home' inside Git's
installation directory
(usually, 'C:\Program Files\Git'), which should point to 'C:\Users\'.
Then, modify your $HOME environment variable so that it contains the
path '/home/'.
After 'cd'ing into $HOME, retry steps 4 and 5 of the previous sequence,
and you will notice that the directory spelling correction features
work as expected.

Long-term fix: if possible, allow 'dirspell' and 'cdspell' to
understand non-unixy filesystem structures.

Matteo Paolini

How should 'vi-yank-pop' be used?

[Matteo Paolini]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -D_STATIC_BUILD
uname output: MINGW64_NT-10.0-19044 Eulero 3.3.5-341.x86_64 2022-07-08
09:41 UTC x86_64 Msys
Machine Type: x86_64-pc-msys

Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:
I recently discovered Readline's 'yank-pop' and 'vi-yank-pop' commands.
>From what I understand, 'yank-pop' is supposed to cycle through Bash's
internal kill-ring
after yanking the most recent killed text.
The command works as expected in Emacs mode, but trying to use its
counterpart in vi mode seems to just return an error (the bell sound
is played).

 This is what I have in my .inputrc:
set editing-mode vi
set bell-style audible
# See if you are in insert or normal mode
set show-mode-in-prompt on
set keymap vi-command
"o":vi-yank-pop

Repeat-By:
1) while in vi-insert mode, write some text;
2) switch to vi-command mode, then press '0D';
3) return to insert mode, then repeat steps 1 and 2 for a
couple of times;
4) switch to vi-command mode, then press 'p';
5) press 'o' (the key I bound to vi-yank-pop).
If 'vi-yank-pop' should work like 'yank-pop', pressing 'o' repeatedly should
cycle through the text you previously killed with 'D', but it seems
like an error is issued.

Best wishes,
Matteo Paolini

Re: How should 'vi-yank-pop' be used?

[Matteo Paolini]

Thanks for your reply.

>
> Thanks for the report. It looks like this behavior (which happens only at
> the beginning of a line) has been around since the original code was
> contributed in 2011.
>
That's strange, for me 'vi-yank-pop' issues an error regardless of the
cursor's position on the line.

Matteo