Skip to content

Enhance: Open in Terminal: no option to open a new tab instead of a new window #712

Closed

Description

@goneng

"Open in Terminal" always creates a new terminal window. When a terminal is
already open, a new tab in the existing window is usually what you want, and
today there is no way to ask for that.

Current behaviour

PBTerminalUtil hardcodes window creation for both handlers
(Classes/Util/PBTerminalUtil.m):

  • iTerm2: createWindowWithDefaultProfileCommand:, then writes the cd
    command into win.currentSession.
  • Terminal.app: doScript:in:nil, which by definition opens a new window.

Proposal

Add an "Open as tab" checkbox to the Integration pane of Preferences,
directly under the existing terminal-handler popup, stored alongside
PBTerminalHandler in PBGitDefaults.

The option applies to iTerm2 only: use createTabWithDefaultProfileCommand: on
term.currentWindow, and fall back to creating a window when there is no
current window (iTerm2 not running, or no windows open). The generated
scripting bridge header already exposes this, so no regeneration is needed.

Terminal.app has no Apple Event for "new tab", so the checkbox should be
disabled whenever Terminal is the selected handler - grayed out rather than
silently doing nothing.

Screenshot

Image

Notes

  • Apple Event delivery is already covered by the existing entitlements work, so
    the tab call should not need anything new for iTerm2.
  • The fallback path in runCommand:inDirectory: (iTerm2 failing over to
    Terminal) needs to keep working when the tab option is on.

Found while implementing

Two things turned up that the proposal above either gets wrong or does not
cover. Both are fixed in #713.

Falling back to a new window when iTerm2 is not running is the wrong move.
Sending createWindowWithDefaultProfileCommand: to an iTerm2 that is not
running launches it, iTerm2 opens a window of its own as it starts, and the
event then adds a second one on top. The result is two windows and two
sessions, in both modes, which is why the tab preference looked like it was
being ignored. Measured with iTerm2 closed beforehand: windows=2 sessions=2
before, windows=1 sessions=1 after waiting for the window iTerm2 opens for
itself, which took 1.63s. The other half of the fallback, creating a window
when iTerm2 is running with none open, is correct and stays.

"Open in Terminal" throws away the scrollback. The command GitX writes into
the session begins with clear, which on macOS emits ESC[3J before clearing
the screen. iTerm2 interrupts the new session to ask whether discarding the
scrollback should be allowed; Terminal.app discards it silently. This is
pre-existing on master rather than anything to do with tabs - it has been there
since iTerm2 support was added - and it surfaced here only because it is the
same code path. tput clear emits only ESC[H ESC[2J, which is all GitX
wants in a session it has just opened.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions