Renaming a directory in a deeply nested path while executing a rename on a file will create a new nested directory if it doesn't exist

[nickjj]

If you rename a file that's in a nested directory and you decide to rename one of the nested directories to a name that doesn't exist yet, it will create a new directory instead of renaming the existing directory and your renamed file (even if the file name didn't change) will get located there.

Reproducible steps on Vim 8.1 using the latest master commit as of this issue's date:

1. Create a test file in a deeply nested directory:

mkdir -p /tmp/testfern/foo/bar/baz \
  && cd /tmp/testfern \
  && touch foo/bar/baz/hello

2. Open Vim with vim .

3. Open the hello file with :e foo/bar/baz/hello

4. Toggle and reveal hello in fern

5. Execute fern-action-move on hello

6. Notice how fern is asking you to rename the hello file

7. Rename foo to foo2 in the destination path and but the leave the file name alone

You will end up with tmp/testfern/foo2/bar/baz/hello and /tmp/testfern/foo/bar/baz will be empty. The file was moved to a new directory instead of the existing foo directory being renamed to foo2.

I'll admit, I'm not 100% on what the expected behavior should be here. Personally I feel like it should probably rename the existing directory to foo2 without creating a new one. It's worth bringing up that if both foo and foo2 directories exist beforehand it will move the file between them as expected.

[bluz71]

This one could go both ways.

It may be legit for fern to state that renames/moves are bound to the tail of a path only.

Depends how complicated the internal logic is.
Ideally we should want fern to have a simple internal implementation, which may sacrifice some corner edge cases. To-be-determined.

It may be worth finding out how vimfiler handles the same case, vimfiler being more similar to fern than NERDTree.

[nickjj]

It may be legit for fern to state that renames/moves are bound to the tail of a path only.

Perhaps but if the source and destination nested directories already exist then fern will move the file to that existing directory, which I think means it's already looking at other bits of the path beyond just the tail.

It's tricky because it operates like mv would work if both nested directories exist (which is nice), but if the destination nested directory doesn't exist, it drastically changes behavior by creating a new directory for you, when I think if you're working with a move / rename operation you would expect a change of the name in any part of the path, not a new copy -- especially since if you rename the file, it renames the file, not creates a new one.

[bluz71]

Yes, I understand the confusion.

fern maybe could display a warning stating that rename/move effects only tail elements.

Note, I too prefer that intermediates be moved. But I also understand that it may complicate the internals, aka too hard. Maybe, maybe not.

Whatever vimfiler does with intermediate moves fern should do the same.

[nickjj]

fern maybe could display a warning stating that rename/move effects only tail elements.

I guess that's the thing. It already handles moving a file to intermediate directories. It's just the behavior is different based on the intermediate existing beforehand or not. When it exists it does a move operation, when it doesn't it creates a new directory.

[bluz71]

Yes, the base issue should be resolved.....or the operation should not occur at all with a helpful informative message.

[nickjj]

Yep, I think as long as you can execute a rename / move on hello.txt in foo/bar/baz/hello.txt and it gets moved to foo2/bar/baz/hello.txt when both foo and foo2 already exist then we'll be in good shape.

That is super common behavior (moving a file from directory A to B) and in this case it requires manipulating an intermediate directory. This is how NT works and while I never tried other tools, I would guess they work the same. Otherwise you wouldn't be able to move files to a new directory.

Fortunately this specific issue is kind of an edge case in behavior consistency because if you wanted to rename foo to foo2 you would likely select that directory instead of a file that exists somewhere within there. Let's see what happens.

[bluz71]

Yep, I think as long as you can execute a rename / move on hello.txt in foo/bar/baz/hello.txt and it gets moved to foo2/bar/baz/hello.txt when both foo and foo2 already exist then we'll be in good shape.

Agreed.

[lambdalisue]

This is basically the same as #111 but this issue has more info thus I close the #111 and continue here.

I know vimfiler cannot handle it and NERDTree is out of scope (it doesn't have a feature similar to exrename/renamer right?) But this is a point why I could not believe exrename on vimfiler thus I'd like to find a way to make it stable.

I'm challenging it on #141 👍

[nickjj]

When you say you're challenging it, do you mean you're working towards a solution that would rename A to B even if B doesn't exist when moving / renaming a file that exists either directly in A / B or somewhere down the directory path chain?

[lambdalisue]

I don't get the meaning but cases I'm trying to solve is listed on #141