Also refresh tree icons when hitting F4

[grindax]

.

[admin]

F4 should refresh the icon of the folder your are on. More I cannot do at the moment.

[grindax]

.

[admin]

Perhaps it would be possible to instead make the rebuild command (Ctrl+Shift+F4) not collapse a locked tree?

Hmm, now that you ask for it, and since we now have Remember Tree State that would be possible indeed. Only I'm not sure if everybody would be happy with that change... Rebuild Tree has its behavior for many years now.

[grindax]

.

[admin]

Hmm, now that you ask for it, and since we now have Remember Tree State that would be possible indeed. Only I'm not sure if everybody would be happy with that change... Rebuild Tree has its behavior for many years now.

What I've been thinking about recently is: now that the tree expansion can be controlled separately, why not merge the functionality of Refresh Tree and Rebuild Tree, making one robust way to make sure that the tree is fully up-to-date? Having two completely separate functions is a bit difficult to understand (especially with regards to how their functionality overlaps).

While I'm mentioning this, maybe even the functionality of Shift+F4 could be folded into this as well. To this day, I still don't understand what that does that's different.

I think they each have their merits functionally and performancewise.

I agree that Refresh Tree should ideally care for the icons as well, but that's currently not possible. These commands were written in a time where tree icons did not change... since they are superoptimized it's very hard to add something like refresh icons to them.
The easiest way would be to combine Rebuild Tree and Tree State, but it would be notably slower than Refresh Tree.

[grindax]

.

[admin]

The easiest way would be to combine Rebuild Tree and Tree State, but it would be notably slower than Refresh Tree.

I believe that would be a good approach for now.

But longer-term, thinking through the use cases for where I've wished to refresh the tree...

Since most of the time the tree is already current, there are only (relatively) occasional times where I see something that is out-of-date. In those cases I find that it's almost always necessary to do a rebuild to get the problem corrected.

Perhaps the set of functions concerning the tree could be changed to something like this:

• Refresh Tree (which means do a rebuild as well. Usually I expect that doing a 'refresh' means that it will be fully current afterwards, just like I expect this for F5 on the file list)
• Reset/Collapse Tree (either as separate options or combined. Could potentially just do the quick stuff that F4 currently does, plus collapses the tree. I myself don't fully understand where the quick version helps since I usually have to resort to rebuild, but maybe this is still required in some scenarios)

I hear you, but: These commands are all very old, and how they are now has been shaped by accumulated experience. It's very difficult to improve these commands without the source code where all the changes and reasons have been anotated over the years. In short: trust me, it's good as it is.

[grindax]

.

[admin]

I think the argument that something can't/won't be improved primarily because it's very old is a weak one.

And if no-one can explain or remember why Refresh (F4) doesn't actually do a full refresh, or why the pseudo-refresh in it's current form is more useful, then I don't see how you can say that it's good the way it is.

Sometimes things that have been designed and developed in the past can be improved upon.

Well, that "no-one can explain or remember" why something is as it is is also a weak argument for changing it. More interesting for me is the fact that no-one (apart from you) ever complained about these commands.

But wait for the next version, I figure you will like the new Rebuild Tree...

[grindax]

.

[nas8e9]

I do still wonder who would have a need for Refresh Tree (F4) now. It seems that between Auto-refresh and Rebuild Tree all bases are covered. Maybe someone not using auto-refresh and/or is using some other combination of settings. Anyway, I'll take your word for it that there is a use case somewhere that is helped by it.

One of the reasons would be this, unfortunately.