Closed nonumeros closed 2 months ago
the magic here also involves the infamous <backspace>
autocompleting the dir
lookup as it was brought up before, with the cd
operation
of course. The cd
operation (of which I don't know if it's acting up, as I didn't have time to check it) but is pretty much reminiscent of the same usual behavior that you pointed out a while back when the discussion came up.
So yep. It'd be the tab
key but mostly is the backspace
thereafter and its ever-lasting relationship with mv
and cd
and so forth
If the dir
in question , lo and behold, has a file
in it, <backspace>
key is unusable. So yes. Although the tab
key would allow you to go over the dirs
and select the dir
as long as the dir
has no file in it. If the dir
has a file in it, then <backspace>
is no longer usable. So one is stuck there.
Furthermore. This can become a pain in the rear really. And I don't know whether it is this or the preceding issue that deals with this, but this behavior may also lead to overwriting a file as no other dirs
would be available for the uselessness of the <backsspace>
this is still an ongoing issue even with the latest head
Let's say that if:
d=path1 c=path1/file1 b=path1/subdirectory a=path1/directory
and a file2 is written elsewhere,
and later on a mv
operation is invoked with that very same file2 that was written elsewhere; thus, taking it over to any of the above destinations' directory/subdirectory, as soon as it <tab>
reaches over the subdirectory where the list of files are at, it's simply untenable to get back at any of the expected subdirectories or directories with the <backspace>
key as before
The prior message to reproduce it no longer applies so disregard the following:
shell stderr: <<<
mv: cannot stat 'foo-bar-baz-foo': No such file or directory
>>>
Error: no selections remaining
The above message is/was intertwined to https://github.com/mawww/kakoune/issues/5160 which had to be closed off for obvious reasons (can't reproduce it with the latest head)
Closing it. Nothing here. The problem comes up after a long long filename that may be used during the mv
operation. That's all.
backspace
also may not be used if another file is selected, but any mv
operation can be cancelled right after and until after the dir
or subdir
is properly selected.
e.g., mv file2 /dir1/subdirectory/file1
, if filename consists of a string of characters with a long filename, then is more evident
Mainly the reason for the whole confusion, was due to the fact that once that file2 would be moved over to the subdirectory of a file1 then once there, if that file1
was selected, backspace
would be therefore, and for practical terms, useless.
Version of Kakoune
2024.04.25
Reproducer
mv
say the same file sayfoo-'bar-baz'-foo
from the preceding bug reporting to adir
of your choosingit returns:
Outcome
Expectations
file should be moved over to the dir without any issue whatsoever, irrespectively whether an extension exists or not
Anyhow. The extension is the least of the problems really.
Also
If the
dir
exists with afile
in it, thedir
and not thefile
should be used for autocompletion . That is, thedir
should take precedence over the autocompletion rather than the file.(I think we went over this a while back but I just don't have the time to look it up now).
Additional information
No response