[BUG] mv operation should not interfere with about kakoune

[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.