Starting lf inside a hidden directory leads to inaccurate directory tree when show hidden files setting is off

[aral]

If hidden files are not being shown and you start lf in a hidden directory, the directory tree becomes corrupted. Instead of the hidden directory you’re in, the closest non-hidden directory is erroneously shown as the parent directory.

To reproduce

Ensure that hidden=false in lf’s settings. Then, in a project with a git folder, run:

lf .git

What should happen

lf should show that you’re in the .git folder.

What actually happens

lf shows you that you’re in some other folder.

Workaround

If you’re aware of this issue, you can toggle on hidden files with zh and then the correct parent directory is shown.

Suggested fix

If lf is started in a hidden directory, it should disregard the hidden file visibility setting and always show hidden files (so that the correct parent directory is shown).

[michaelferon]

The correct directory is shown in the prompt in the top line, it's just that this directory is not highlighted in the left pane (as it is hidden). This is not exclusive to starting lf in a hidden directory. This happens if, at any point, you are currently within a hidden directory but don't have the hidden option activated.

I do agree that this could be a little misleading. I think a better fix would be either a) leave hidden files hidden and don't highlight anything in the left panel, or b) leave hidden files hidden, excepting the hidden directory you're currently in, and highlight that in the left pane

[Limero]

I just checked and Ranger has the same as lf's current behavior.

I don't think we should show all hidden files/directories when in a hidden directory, but always showing parent directory makes sense to me (option b from @michaelferon).

There is an edge case here. If you launch lf in a hidden directory, lf .git, navigate one step left (h key), I expect the .git to still be shown, but then navigation another step left (h key) and then back again (l key), I don't expect it to still be shown or should it?

I also expect, standing on a hidden directory, toggling hidden files back and forth would continue to show that directory, not jump cursor to a non-hidden directory and remain there.

[aral]

I think a better fix would be either a) leave hidden files hidden and don't highlight anything in the left panel, or b) leave hidden files hidden, excepting the hidden directory you're currently in, and highlight that in the left pane

Let’s take this from first principles and approach it as a design problem:

lf’s file system navigation is based on the following mental model:

[Column A: Where I was.] Highlighted item: Where I am (outside) → [Column B: Where I am (inside)]

This has a strong logical and physical model. We can relate it to what is behind us and in front of us in physical space. We can also relate to being outside and inside a physical space. For example, outside a house and inside a house; outside a room and inside a room. These constitute strong landmarks we have while navigating physical space. In fact, the street/house analogy is a valuable one to translate into virtual space for this discussion.

Let’s imagine Column A is the street, the highlighted item in Column A is the outside of the house, and Column B is the inside of the house.

Here’s what happens current when you open lf in a hidden directory:

[Column A: I know what street I’m on] I don’t know what house I’m in → [Column B: I can see the inside of the house]

So I don’t know where I am but I know what’s inside it.

Clearly, this is problematic. The mental and physical model of our nagivation control breaks down.

a) leave hidden files hidden and don't highlight anything in the left panel, or

This is the status quo and so this will not fix the problem.

b) leave hidden files hidden, excepting the hidden directory you're currently in, and highlight that in the left panel

This initially appears to solve the design problem.

But does it?

The navigation control currently has two states related to hidden files: show hidden files, hide hidden files. By implementing option b, above, we are introducing a third state: a mixed state where all files and directories except one hidden directory are shown.

(This should immediately be a design smell.)

And, thinking it through, the new model breaks down completely if the person navigates to the parent of the hidden directory.

Take the following structure:

grandparent → .parent → child

If we implement (b) and the person launches lf in the child directory, .parent is shown.

However, if they navigate back to grandparent, .parent will suddenly disappear from the tree.

This is surprising and jarring to say the least. It will also stop the person from being able to go back into .parent.

(Most times, if you have things disappearing and reappearing from your interface, this is a design smell.)

We’re complicating the mental model, reducing the physicality of the control, breaking the consistency of navigation, removing a landmark, and increasing cognitive load.

So, going from first principles and working through the design problem, I would reiterate that the solution to this problem is to show all hidden files and directories when lf is launched from within a hidden directory without in any other way changing how lf works.

The remaining question is what happens if the person attempts toggle the hidden files/directories setting while in a hidden directory. My initial thought would be to ignore the request and show a status message informing them that they can’t. Something like: “Cannot hide hidden files when in a hidden directory.” (Currently, the behaviour is to dump the person out of the directory and into whatever directory is closest instead. Which, again, is hugely jarring.)

[michaelferon]

I agree that this could be tricky, and there are definitely quite a few nuances that would have to be attended to, as both you and @Limero have pointed out. I think your fix makes sense, but to me it's a bit of a nuclear option to just disable the toggling of hidden files just because you're in a hidden directory.