Hi,
A very handy feature of Sumatra is its intuitive behavior on Back/Forward press (Alt + Left/Right arrow). This allows to easily “jump” between different parts of a file, which is very handy when multiple parts of the same file are needed.
However, this “history” is deleted on Sumatra restart, crash, or simple file close. Would it be possible to have it maintained persistently?
Thanks,
Shlomi
I was intending to add to similar topics about a files fixed rotation / toc history etc. however this one is more specific to the session history.
There have been requests to disable gobackto history as it causes problems with touchpad scrolling. But here you wish it stored between sessions, there was an experimental means of storing jump locations in the smx files which are no longer used, also there were attempts at a “virtual” bookmarking system that could have replaced favourites, but that also had issues.
Whilst it may well be possible to store a stack of pages visited, in the current single settings file, it too would rapidly build up undesired by many users “enhancement” entries, leading to more requests for “On/Off/Maybe” feature creep
AFAIK the step back in visit history function is part of core MuPDF viewing library, thus as it stands is easy to implement, but enhancing it to retain history needs somebody willing and able to add all the necessary robust code, with the normally expected demands for more whistles and bells on that.
Thanks @GitHubRulesOK! Yes, I understand that such a feature might not be implemented soon…
The rationale behind this request is that, ideally, no event (file close / computer reboot / Sumatra crash / whatever) should interrupt the user’s workflow. Remembering open files and file positions goes a long way towards achieving that. Storing also the file’s goto history would make two distinct Sumatra sessions indistinguishable from the user’s perspective.
Storing the stack of visited pages sounds great. Perhaps it’s worth storing it separately per file, rather than in the single settings files. That would prevent clutter in the settings file, and make it more robust. How about placing stack-files aside the main settings file, one for each goto-history stack? So, if one of the stacks gets out of control, then only the relevant stack-file needs to be deleted, affecting nothing else.
The only caveat I see here is if a file is opened simultaneously more than once. e.g., in two Sumatra instances.