With the “Automatically check for updates” setting turned on, I receive prompts for new versions when I open PDFs and usually click on the “Install and relaunch” option. On relaunch, I am shown the splash screen (attached). I think that it would be ideal if the last open file is reopened in this edge case even if the “Remember opened files” setting is turned off.
I think that was some experimental behavior of some older versions, during update. The rule is normally based on holding two tabs or more is needed for settings, but for update a single tab would re-open.
That may have been inconsistent after multiple windows were introduced, e.g. could not reopen unknown number of windows. see issue Restore Multiple Windows and other related comments
When question was last raised as not working the same, (in more recent pre-release versions) - More a query than issue ReopenOnce that inconsistency was removed.
Having gone through the links, I am left with the understanding that the reasoning @kjk used about this case is that the last single open file would be visible on the splash screen. I believe that such is not the case when the “Remember opened files” setting is turned off: I am not completely sure if that is the correct interpretation of it all, but if it is, I think a distinction between the relaunching-after-update and closing-normally-followed-by-opening-again cases. To me, the naturally expected behaviour in the former is for the previous session to be restored since the user was in the middle of reading before the update prompt, while the latter is interpreted as the user implicitly signalling (by deliberately closing) not expecting to return to this session.
As an aside, perhaps an elegant way to handle it would be to take inspiration from Paint.NET’s way of handling updates on launch: providing an option to have the update downloaded in the background and finally installing it when the user closes the application.
On Windows 7 32 bit Portable keeps the session active whilst the download of a new zip is in progress to a desired location thus I manually close session to unpack and update.
The installed version is slightly different it needs to close SumatraPDF & Windows explorer in some cases before update (I have an open issue with that not working sometimes, but still trying to decide exactly why explorer is locking SumatraPDF out.)
However if remember open files is ON the fresh install correctly re-opens the session exactly where I left off. Basically it works well,as designed relative to file locking.
I see. Would it be too much wishful thinking on my part to expect the same behaviour for update and relaunch when “Remember open files” is OFF?
As Far As I Can Recall (AFAIK) that was the idea behind the experimental feature it was supposed to remember just the current file open at the time, obviously that had multiple issues, especially as more features were added.
So initially it could not remember multiple window positions, or which screen was in use last nor if tabs order was changed plus other niggles. I had not used it in years as a workaround for keeping only one file in focus. If you need the Session History restored it is simply easier to keep that option on, and work with the rule of 2 or more = session.
Just to recheck how current update works I opened two separate windows, one with two tabs the other with half a dozen tabs and ran update where both windows needed closing and on re-install via save and run then both windows were reopened with the files as before.
Too many permutations to test (e.g. whilst using annotation/rename/ cloud drives)
but for comparison I had a set of 3 single windows = without tabs active but with remember ON, for portable version update.
Which instantly closed all 3 windows, did the in place self update and auto re-launched the 3 remembered windows. however that would not work for just one single window since when reopening a single closed window (like it or not) we always start with the frequently read screen.
To store the current session for just one file would require a personal built compilation as described in the link to issue above, but to make that work for all potential user permutations would require significant testing to ensure it was robust for general users.
The one common case I know where a single file is required to be kept open during update is whilst running LaTeX Compilation with one fixed file at a time, (and possibly the reason the experimental feature was initially added) however that has its own mechanism to re open the one current file whist updating the contents, without using remember on.
