savannah: Development request: inserting a new directory entry inside the directory history list, not at the top

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/5
Reporter	slavazanko (@slavaz)

Original: http://savannah.gnu.org/bugs/?8977

Submitted by:	None	Submitted on:	Sun 16 May 2004 02:13:54 PM UTC
Category:	Core	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	4.6.0|Operating System:|GNU/Linux

Original submission:

Currently, changing to a new directory appends a directory entry in 
top of the directory history and removes any previous identical 
entries from the history. This unique append is a really handy 
feature, but isn't it more convenient and intuitive to insert the 
new directory entry right after the current directory in the history
list? This way when you want to visit all of the subdirectories of 
the current directory you can get back to the current directory 
conveniently with only one "back" command. As it is now, to get back
to the parent directory I have to go back in history an increasing 
number of times as each new subdirectory I visit is increasing the 
distance in the history list from the last entry to its parent.

Of course, this would involve changing list_append_unique in util.c 
and another parameter to this method indicating where in history we 
are currently. The method should still remove entries which are not 
unique.

I am waiting for your feedback in case you disagree with me.

Best Regards,
Vasco

Comment 1 by Anonymous at Mon 21 Jun 2004 02:24:16 PM UTC:

The problem is that the functions "Back" and "Forward" in history 
lose their appeal when the sequence of the history list changes. 
With the current functionality, they are also not consistent with 
the other history modifying commands. Every time the directory is 
changed, the directory item is placed at the top of the history list
except for the "Back" and "Forward" functions (quite understandably,
otherwise it will be a mess).

There are currently two acceptable proposals I could think of:

1. When the cursor is in the middle of the history list and a 
directory item is added, which is new to the list, the top of the 
history is pushed until there are no more elements in the top. This 
is done by removing the topmost element, whereas before the 
directory after the cursor was replaced with the new one. This 
change does not necessarily keep the newest directories in the 
history, if they are above the cursor in the history list.

When the cursor is at the top and a new entry is added, the element 
at the bottom is removed.

2. I liked the idea of only deleting the oldest accessed entry. 
However this makes it somewhat less usable to navigate with "Back" 
and "Forward". In order to have both, two lists should be maintained
(or a list of two-element objects, much better style). There's an 
internal list (or entry) of when each directory has last been 
accessed. The oldest item is deleted when a new entry is added. Then
there's the list of history entries which the user sees and which is
transformed into a ring: "Back" and "Forward" change the current 
directory and overwrap. A new directory entry is added right after 
the cursor in the ring. And when a directory is chosen from the 
history list (ring) the directory is changed without shifting the 
sequence of the list, i.e. no entry is popped at the top.

Does any of this make sense? Implementation is not the biggest 
problem here, I think, I'd just like to know what sounds more usable
and intuitive for others. The second model is a bit harder to 
comprehend but overall more sound and consistent, while offering 
both usability and functionality.

Regards,
Vasco

[mc-butler]

Changed by styx (@styx) on Feb 20, 2009 at 13:39 UTC (comment 1)

• Milestone set to 4.7

[mc-butler]

Changed by angel_il (@ilia-maslakov) on May 20, 2009 at 11:38 UTC (comment 2)

• Milestone changed from 4.7 to future releases

[mc-butler]

Changed by ossi (@ossilator) on Jan 11, 2014 at 15:21 UTC (comment 3)

• Description edited
• Branch state set to no branch