When first running SciTE with arguments and check.if.already.open
set to 1, the previous session does not load.
This occurs because when ProcessCommandLine()
is called and phase == 0
, RestoreSession()
is never called. This is not an issue when SciTE is called without arguments.
However, with arguments, during phase == 1
the previous default session has already been overwritten by the time RestoreSession()
is called.
Thus, the session's files are not opened.
In addition, check.if.already.open
is evaluated so that non singleton configurations don't load duplicate sessions.
This is deliberate: sessions are only loaded if there is no explicit file argument. It's even documented on https://www.scintilla.org/SciTEDoc.html .
I see, I was not aware of this.
The thing that felt unintuitive to me was that this behaviour is present when opening a file through the desktop environment too, not just the CLI.
Double clicking on a file or using 'Open with' essentially overwrites your previous session. This has lost me multiple sessions.
While I was testing this patch, I didn't observe SciTE being less safe to use due to "save.session", could you please explain what you meant by that?
Personally I think appending the file doesn't cause any issues.
As far as I can tell the file gets appended to the session and is in focus, so the other files don't get in the users way.
Alternatively, would it make sense to put this behind a new flag?
This was implemented and documented by someone else. Its fairly old. 'safe to use' is likely addressing extra costs like time to open and memory use rather than data destruction.
Users have different perspectives and use patterns and it can be difficult to understand these as our own point of view colours our thinking.
One role that SciTE has fulfilled is as a fast ephemeral single-file editor for tasks like file viewing and commit message entry which may be initiated from the File Explorer or a source control GUI like TortoiseHg. Another role is of a central editor for a project with multiple files loaded. Both these roles should be possible at the same time with multiple SciTE instances.
Sorry for the late reply.
That's understandable, this is why I asked if adding a flag would be more appropriate, as I didn't see it negatively interfere with other use cases.
If that's something you'd like implemented, I can do that.
Otherwise, feel free to close this bug report.
In either case, thank you for looking into this.
New features are worthwhile when users can understand and then use them which requires them to be documented in a clear way.
How would the behaviour of the property be described along with its interaction with other properties? Writing the text for the 'Defined variables ...' section of SciTEDoc.html would solidify how it should work. The property should be just after or in the save.session item.
There will also need to be changes to the sessions section of the documentation and possibly other locations.
Alright, thank you. I'll get to it as soon as I can.
Sorry, finally got around to sending these.
I have made two patches, one with a new property and another that uses
save.session
to achieve the same result.Let me know what you think.
The documentation change doesn't mention that
check.if.already.open
needs to be set forload.session.always
to activate. This may confuse users who tryload.session.always
and see no effect.Thanks for catching that. Much appreciated.
Committed as [20551b].
Related
Commit: [20551b]