feat(open): support for new openInTerminal config option to be able to use terminal based applications for opening files in the same session

[ramonvermeulen]

PR Description

Closes #5623

This PR add support for openInTerminal in the same way that there is support for editInTerminal. When this value is set to true, lazygit will suspend until the configured open process returns, when the value is set to false behavior stays the same as is.

I decided to keep the naming conventional to editInTerminal, even though editInTerminal is named as is for backwards compatibility. Otherwise you would have suspendOnOpen and editInTerminal which doesn't really pair well, I'm fine renaming if that is desried.

Additional context: #5622

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here) -> when I run the formatter I get quite a huge diff on files that I didn't touch
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

Manual testing

I manually tested with the following configs:

With openInTerminal: true and a terminal based editor provided

  os:
    edit: 'nvim -- {{filename}}'
    editAtLine: 'nvim +{{line}} -- {{filename}}'
    editAtLineAndWait: 'nvim +{{line}} -- {{filename}}'
    editInTerminal: true
    open: 'nvim -- {{filename}}'
    openInTerminal: true

  promptToReturnFromSubprocess: false

  keybinding:
    universal:
      edit: e
      openFile: o

With this config open now behaves the same as edit in combination with editInTerminal, and I am able to open neovim within the same terminal session and after closing be back in lazygit because of the suspend functionality.

With openInTerminal: false and a terminal based editor provided

  os:
    edit: 'nvim -- {{filename}}'
    editAtLine: 'nvim +{{line}} -- {{filename}}'
    editAtLineAndWait: 'nvim +{{line}} -- {{filename}}'
    editInTerminal: true
    open: 'nvim -- {{filename}}'
    openInTerminal: false

  promptToReturnFromSubprocess: false

  keybinding:
    universal:
      edit: e
      openFile: o

For me this freezes lazygit and I have to close the app manually, this is the same behavior as what is currently on main.

With openInTerminal: false and a no editor provided

  os:
    edit: 'nvim -- {{filename}}'
    editAtLine: 'nvim +{{line}} -- {{filename}}'
    editAtLineAndWait: 'nvim +{{line}} -- {{filename}}'
    editInTerminal: true
    open: '' # keeps default behavior via GetPlatformDefaultConfig, which is `open -- {{filename}}`
    openInTerminal: false

  promptToReturnFromSubprocess: false

  keybinding:
    universal:
      edit: e
      openFile: o

Still keeps the original behavior, taking the system default via open -- and launching the default editor in a new process. In my case this opens the file in a GUI based editor in another process (in my case zed).

[ramonvermeulen]

Hi @stefanhaller,

If you have the capacity, I would like to get a review on this PR / feature request.
I've been running this build locally for the past few weeks and didn't run into any issues so far.

First typical question would be if this is something you would like to see added to lazygit at all?

From my personal experience I would really love a configuration option like openInTerminal (or suspendOnOpen). Main reason for me is that I can then also use the o keybinding to directly open a terminal editor from within lazygit instead of this just being possible with the e keybinding and editInTerminal.

[stefanhaller]

This doesn't make sense to me, and I don't understand why you are doing it (your PR description only explains what this does, but not why; that's the first thing a PR or issue should explain). It seems you want to achieve that o behaves the same as e, and I don't understand why.

o is for opening files in a GUI program (e.g. a PNG in an image editor, or a PDF in a PDF reader). e is for editing files; I don't see why we should mix up the two.

[ramonvermeulen]

@stefanhaller thanks for taking a look at this.

Sorry for not providing this thought in my original issue, but to elaborate a bit more on the why:

o is for opening files in a GUI program (e.g. a PNG in an image editor, or a PDF in a PDF reader). e is for editing files; I don't see why we should mix up the two.

That is indeed how it is currently implemented. The o for open AFAIK currently solely supports to open files in a GUI program (separate process), why not support both GUI as well as terminal based (child process) programs to open a file?

Even though the "original" purpose is purely open and not edit I think it adds value to support terminal based applications that can run as a child process to open a file, rather than just GUI based applications in a separate process. There are plenty of developers out there that use a purely terminal based workflow, and at least for me, staying in the same terminal session is an UX improvement.

Even for binary files such as .png, .pdf, etc. there do exist terminal based applications to open them. Why not offer the same flexibility for open as for the edit command and let the end-user define the behavior?

If it is just a clear no, it's only intended for GUI based programs, that is also fine, but at least I hope this makes you understand my chain of thought and why I would like to see this as a feature.

Edit: I just updated the issue description to be more complete.