[BUG] mv operation should not interfere with

[nonumeros]

Version of Kakoune

2024.04.25

Reproducer

mv say the same file say foo-'bar-baz'-foo from the preceding bug reporting to a dir of your choosing

it returns:

shell stderr: <<<
mv: cannot stat 'foo-bar-baz-foo': No such file or directory
>>>
Error: no selections remaining

Outcome

shell stderr: <<<
mv: cannot stat 'foo-bar-baz-foo': No such file or directory
>>>
Error: no selections remaining

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 a file in it, the dir and not the file should be used for autocompletion . That is, the dir 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

[nonumeros]

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>

[nonumeros]

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 #5160 which had to be closed off for obvious reasons (can't reproduce it with the latest head)

[nonumeros]

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.