Menu

#2440 [PATCH] Fix default session not being loaded on start with arguments

Bug
closed-fixed
nobody
5
2024-08-21
2024-06-01
No

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.

1 Attachments

Discussion

  • Neil Hodgson

    Neil Hodgson - 2024-06-03

    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 .

    When you start SciTE loading a specific file from command line last session will not restore even if "save.session" variable is set to "1". This makes "save.session" safe to use - you will never open a couple of files when you are trying to open just one, specific file.

     
    • Mavroudis Chatzilazaridis

      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.

      This makes "save.session" safe to use - you will never open a couple of files when you are trying to open just one, specific file.

      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?

       
  • Neil Hodgson

    Neil Hodgson - 2024-06-05

    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.

     
  • Neil Hodgson

    Neil Hodgson - 2024-06-06

    this behaviour is present when opening a file through the desktop environment too, not just the CLI

    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.

     
  • Mavroudis Chatzilazaridis

    Sorry for the late reply.

    Users have different perspectives and use patterns and it can be difficult to understand these as our own point of view colours our thinking.
    Both these roles should be possible at the same time with multiple SciTE instances.

    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.

     
  • Neil Hodgson

    Neil Hodgson - 2024-06-11

    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.

     
  • Mavroudis Chatzilazaridis

    Alright, thank you. I'll get to it as soon as I can.

     
  • Neil Hodgson

    Neil Hodgson - 2024-08-01

    The documentation change doesn't mention that check.if.already.open needs to be set for load.session.always to activate. This may confuse users who try load.session.always and see no effect.

     
  • Neil Hodgson

    Neil Hodgson - 2024-08-04
    • labels: scite --> scite, session
    • status: open --> open-fixed
     
  • Neil Hodgson

    Neil Hodgson - 2024-08-04

    Committed as [20551b].

     

    Related

    Commit: [20551b]

  • Neil Hodgson

    Neil Hodgson - 2024-08-21
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.