Repository navigation
Add support for Alacritty Terminal integration on MacOS - #2781
Merged
love-linger merged 2 commits intoOct 13, 2026
Merged
love-linger merged 2 commits into
love-linger merged 2 commits into
Conversation
Adds a very naive handler for `args` (which was previously the unused `string _` in the `OpenTerminal()` function signature) to allow for "weird" terminals like Alacritty which require the starting directory to be set via a commandline option (`--working-directory` in Alacritty's case). Critically, this is a simple, naive handling of `args`. Since the `open` command doesn't process anything after the `--args` flag, this setup requires a macOS terminal integration that sets `args` to also set the terminal's starting directory via those `args`. Personally, I think both the macOS and Linux implementations of `OpenTerminal` could do with more robust CLI parsing (which I'm happy to take a first pass at), but I felt it was outside the purpose of this branch.
Adds integration support for the Alacritty terminal on macOS. Alacritty is cross-platform and available for Windows and Linux as well, so adding support on those platforms should be trivial, but this is the platform I wanted it and could test it for. I tested this on my MacBook Pro both with the Alacritty terminal and with the default macOS Terminal to ensure compatibility with existing integrations. Alacritty differs slightly from other macOS terminals in that it doesn't allow setting the starting directory through `open` with `open -a Alacritty /path/to/dir`; instead, you have to set the starting directory using Alacritty's `--working-directory` CLI option, resulting in something along the lines of `open -a Alacritty --args --working-directory /path/to/dir`. Thus, adding support for Alacritty also required adding support for passing arguments to terminals on macOS, at least at a naive level.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR adds support for the Alacritty terminal as an integration on macOS. I tested the PR myself on my MacBook Pro with both Alacritty and the default macOS Terminal to test compatibility with existing integrations.
Alacritty is cross-platform and available for Windows and Linux as well, so adding support for it on those platforms should be trivial, but this is the platform I wanted it on and could test it on.
Alacritty's Starting Directory
Alacritty differs slightly from other macOS terminals in that it doesn't allow setting the starting directory through
openwithopen -a Alacritty /path/to/dir; instead, you have to set the starting directory using Alacritty's--working-directoryCLI option, resulting in something along the lines ofopen -a Alacritty --args --working-directory /path/to/dir.However, the macOS implementation of
OpenTerminalpresently ignores theargsparameter (and it's currently declared asstring _in the function signature). Thus, to make Alacritty work properly, I had to add some simple, naive argument handling for the macOS implementation.To be clear, this implementation of handling
argsis very simple. Critically, since theopencommand doesn't process anything after the--argsflag, this setup requires any macOS terminal integration that setsargsto also set the terminal's starting directory via thoseargs, rather than relying on default behavior.I considered writing a more robust CLI options handler for more complicated
args, but I felt that it was outside the scope of this PR since it would require either hand-rolling an options parser or adding an external dependency. I still think it could be worthwhile, though I know it's not SourceGit's primary concern.Feel free to comment with any questions/concerns, I'm happy to answer what I can.