7.90.410 History chgs causes loss of useful data..not ideal.

[j_c_hallgren]

So in v410, we have this:

Code: Select all

! History: With "History without duplicates" ON, the strategy when going to a new place while being somewhere in the middle of history (= in the past) was to *somehow* preserve the old future (by shifting blocks of history to new positions) -- the results were not satisfying. Now, the future is simply purged -- the common practice in history management.

Well, the intent may be good but the effect is not, IMO!

I tried it just to see...it means that I lose a lot of useful history data...let me give an example:
I have 255 entries in history, from doing various tasks...I need to go back to entry 201 to check something and that folder is not important enough to catalog or otherwise mark...when I'm at 201, I need to go to a sub-folder of it to see one thing...ok, so I do...but when I'm done, I want to resume where I was originally at 255...now, with this change, the old 202 and up are gone! I can't continue where I 'paused' or near that and keep going...and/or go back to entry 250+- and continue..

I've got history per tab, and I typically only use 3-4 tabs max, with those tabs always used for certain types of work, and that's my best way of working for me...so now what?

Maybe I'm used to doing things a different way, but this change has had a negative effect and that's not what I prefer obviously...

Addendum: Here's a maybe imperfect analogy: You record a bunch of video from TV...go back to replay a snippet from 2 hrs ago...you then take a look at what is currently on TV live...but by doing so, you now have erased the rest of the recorded video...see?

[Gandolf]

I agree totally.

The concept that because it's "in the past" and therefore no longer required is not how I see history. It's a location that I have been to recently, and may want to go to again.

[Pagat]

i disagree. if i go back in history and then move to a different location i create a new branch. Therefore i don't need the old anymore.

[j_c_hallgren]

i disagree. if i go back in history and then move to a different location i create a new branch. Therefore i don't need the old anymore.

I'll agree that it's a new branch...but...that still doesn't mean that all more recent history should be discarded...If I work on task A, then task B, C, D, and E...and then go back to folders for task A for a bit more work (thus some related new locations), does that mean that all the places related to tasks B-E are now worthless? With this change, it seems to be that way...but in my work flow, I do still need those locations related to B-E as well.

[Gandolf]

And another example:

I go back in my history to an edit session that still happens to be in the history (C:\......\May\15\) and look at a sub-directory of that edit (happens to be called PV21).
Right, I've seen what I want and now require to look at somewhere I visited yesterday - it must be in the history - but no - it's gone!
How can that be good if every time I use history I can only view the path that is in that history entry, and can't view any sub-directories.

Incidentally, J.C., if you "exit without saving" then you can still get the old history back. I assume the history is written to disk on exit.

[admin]

I think 2 different concepts are mixed up here, history and MRU.

If you go to a new location...
... a history should create a new branch and discard the old one (if any).
... a MRU should put the new location to the top, and shift all other down (losing the last one of the store is filled to the max), OR if the location is already contained in MRU, simply move it to the top.

So, what you are missing now is currently not existing in XYplorer (because the Hotlist also draws on the history).

If we simply turn the history into a MRU then an important feature (or maybe it is not so important for a file manager?!) of a history is lost: you cannot go back the way you came here!

BTW, I agree that the current new state is not good!