Change histories items order

[johnd0e]

Description of the new feature or improvement

Since build 5773 the histories behavior changed and it's hard to find recently closed files/folders. Reason: the list is sorted in order of their opening.

5773 was useful, as it (1) helps to keep histories in several Far instances in sync (2) saves history even if far crashes.

• https://bugs.farmanager.com/view.php?id=1859
• https://bugs.farmanager.com/view.php?id=2843

Still, I'd like to see another order, as accessing recently closed files is rather common task.

Proposed technical implementation details (optional)

I suppose that the most compatible behavior can be achieved if update item's timestamp both on opening and closing.

[johnd0e]

Linked issue: these two macros are broken now, and it's impossible to fix them (except in far itself):

• https://github.com/FarGroup/FarManager/blob/master/extra/Addons/Macros/Panel.AltBS.lua
• https://github.com/FarGroup/FarManager/blob/master/extra/Addons/Macros/OpeningLastFile.lua

[plastikat]

I hope there is a chance for the suggested workaround to be implemented.

[alabuzhev]

I suppose that the most compatible behavior can be achieved if update item's timestamp both on opening and closing.

Ok, as requested. 6051.

[plastikat]

I see the code was modified to handle a directory change on multiple events, but this modification does not seem to resolve this issue (at least not in the way I would expect it to). I will share my test case to back up my words.

• Open two Far instances from the same folder (I will call these far1 and far2).
• In far1 run cd Legacy.
• In far2 run cd Documentation So far we have the following in folders history:

╔══════════════════ Folders history ══════════════════╗
╟──────────────────── 05.02.2023 ─────────────────────╢
║  D:\Temp\Far30b6060.x86.20221208.test\Legacy        ║
║  D:\Temp\Far30b6060.x86.20221208.test\Documentation ║
╚═════════════════════════════════════════════════════╝

• Now in far1 run cd ..\Addons. And the folders history becomes:

╔══════════════════ Folders history ══════════════════╗
╟──────────────────── 05.02.2023 ─────────────────────╢
║  D:\Temp\Far30b6060.x86.20221208.test\Legacy        ║
║  D:\Temp\Far30b6060.x86.20221208.test\Documentation ║
║  D:\Temp\Far30b6060.x86.20221208.test\Addons        ║
╚═════════════════════════════════════════════════════╝

While I would instead expect the following history:

╔══════════════════ Folders history ══════════════════╗
╟──────────────────── 05.02.2023 ─────────────────────╢
║  D:\Temp\Far30b6060.x86.20221208.test\Documentation ║
║  D:\Temp\Far30b6060.x86.20221208.test\Legacy        ║
║  D:\Temp\Far30b6060.x86.20221208.test\Addons        ║
╚═════════════════════════════════════════════════════╝

This is because in far1 I am moving from Legacy (and its history item's timestamp should get updated upon leaving the directory) to Addons (and its history item's timestamp should get updated upon entering the directory), whereas in fact I do not see the Legacy history item's timestamp getting any update (for it remains above the Documentation item).

---

My understanding of the proper implementation of the suggested solution, which was:

update item's timestamp both on opening and closing

is that the last two history items would always be the following:

• The most recent folder that was left.
• The most recent folder that was entered.

This way, we would be certain that the second to last history item always points to the folder that was most recently left and all we would have to do to fix our macros (relying on the "recently left" folder) is to pick this second to last item instead of the last one. Please let me know if my understanding is incorrect (or if there are any technical difficulties preventing its implementation).

[alabuzhev]

@plastikat your expectations are logical, it should work like that, and it actually does when navigating "normally".

However, "cd ..\Addons" happens in the command line context, not file panel, and the command line manually updates the file panel state. The problem is, it changes panel's "current directory" first and then invokes usual ceremonies, including history update, so basically instead of "add current, add new" file panel adds the new directory twice.

In other words, it's a bug. The only technical difficulty is that the related code is more "evolved" than "designed", so who knows what fixing it might break. Guess we will find out.

[plastikat]

@alabuzhev, my personal feedback would be that everything works as expected and no unexpected behavior has come up so far. Thank you for the fix, it's of great value to me.