A few people were copying that snippet and were facing issues such as
"permission denied", and (after a subsequent `chmod`) "syntax error".
-----
From the [CONTRIBUTING.md]:
> Pull requests should be associated with a previously accepted issue.
I decided to ignore this for a single-word change, since creating a
discussion then waiting for it to be promoted to an issue seemed
pointless for such a minor change.
[CONTRIBUTING.md]:
https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#pull-requests-implement-an-issue
Based on both context and observed behavior, "now" was intended to be "not" in the paragraph describing the behavior of `focus-follows-mouse` is set to `true`.
This looks better than the regular dark color. It also happens to match
what Ptyxis does. It does not support non-libadwaita builds.
Signed-off-by: Tristan Partin <tristan@partin.io>
This was originally fixed in ghostty-org/website#152, but was
accidentally reverted in
[ghostty-org/website#99795d7882a5ee47437454c7c106c2874e0406dc](99795d7882).
P.S., you might want an PR template to discourage folks from making
unsolicited PRs like this :)
P.P.S., you can write issue templates as yaml files to stop folks from
ignoring them (required fields)
An exception is raised from the elvish integration module when
`TERMINFO` is set:
```
Exception: exec: "type": executable file not found in $PATH
ghostty-integration.elv:120:60-71: if (and (not $no-sudo) (not-eq "" $E:TERMINFO) (eq file (type -t sudo))) {
ghostty-integration.elv:38:1-123:1:
```
`type` is a builtin in bash and [in
fish](https://fishshell.com/docs/current/cmds/type.html) but it does not
exist in elvish. I suspect it is here as an accidental copy/paste from
the ghostty [fish
integration](https://github.com/ghostty-org/ghostty/blob/main/src/shell-integration/fish/vendor_conf.d/ghostty-shell-integration.fish#L71).
Maybe we can use the elvish
[`has-external`](https://elv.sh/ref/builtin.html#has-external) function
instead (or we could remove that check altogether).
Edit: I think this is in a merge-able state (and it would fix that
error!), but I have just converted this PR to a draft since I can see
other problems with the script. I'll give it a more thorough treatment
later and amend this PR (or also happy to merge this and do other fixes
in separate PRs).
macOS will create `.DS_Store` files in any directory it opens in Finder.
The `+list_themes` command would then list this file as a theme, and
attempt to preview it. `.DS_Store` is a binary file, and is silently
failing in the theme preview...I am on Linux and when I put a small
binary file in my user themes directory, I get a segfault. There is
something about the specific contents in `.DS_Store` that does not cause
this segfault, but lets us silently fail. We should investigate this
further - the issue is in `Config.loadFile` I believe.
In either case, we need to ignore `.DS_Store` so that it is not listed
as a theme.
From the 'CONTRIBUTING.md':
"Pull requests should be associated with a previously accepted issue. If
you open a pull request for something that wasn't previously discussed,
it may be closed or remain stale for an indefinite period of time. I'm
not saying it will never be accepted, but the odds are stacked against
you."
I understand this, and I make a PR without an issue because I feel like
this is actually binary.
On discord I've been informed the quick terminal is macOS only, and in
the documentation I don't think this is expressed, please correct me if
wrong and close this.
If it's correct and the documentation should contain it, then here's my
PR adding that information on the bottom of the section.
If the location of the added information does not fit the style
guidelines I can change it.
We do not currently support bitmap fonts in a real capacity, and they
often are missing some tables which we currently rely on for metrics,
and we don't handle the metrics calculations failing gracefully right
now.
macOS will create `.DS_Store` files in any directory it opens in Finder.
The `+list_themes` command would then list this file as a theme, and
attempt to preview it. `.DS_Store` is a binary file, and is silently
failing in the theme preview...I am on Linux and when I put a small
binary file in my user themes directory, I get a segfault. There is
something about the specific contents in `.DS_Store` that does not cause
this segfault, but lets us silently fail. We should investigate this
further - the issue is in `Config.loadFile` I believe.
In either case, we need to ignore `.DS_Store` so that it is not listed
as a theme.
Fixes: #3378
`type` is a bash builtin and should not be used in elvish.
```
Exception: exec: "type": executable file not found in $PATH
ghostty-integration.elv:120:60-71: if (and (not $no-sudo) (not-eq "" $E:TERMINFO) (eq file (type -t sudo))) {
ghostty-integration.elv:38:1-123:1:
```
We can use the elvish `has-external` function instead.
The `Command.zig` tests reach outside the local source tree and look for
files on the host os machine. This introduces some portability issues
for the tests.
The nix build sandbox doesn't include `/usr/bin/env` making it error out
when `zig build test` runs `Command.zig` tests as part of a `nix build`.
Current ci and local development relies on `nix develop` sharing a host os
file system that includes `/usr/bin/env`.
Turns out `/tmp` and `/bin/sh` are available in the build sandbox in
nix so we swap these in to enable nixpkg builds to include testing
ghostty as part of any update cycle.
Update logic for generating `webgen_actions`.
Before the change, the following grouping was produced:
```md
## `copy_to_clipboard`
Copy and paste.
## `paste_from_clipboard`
## `paste_from_selection`
## `increase_font_size`
Increase/decrease the font size by a certain amount.
```
After the change, the following grouping is being produced
```md
## `copy_to_clipboard`
## `paste_from_clipboard`
## `paste_from_selection`
Copy and paste.
## `increase_font_size`
## `decrease_font_size`
Increase/decrease the font size by a certain amount.
```
Please note that this is my first time ever writing zig, so forgive me
violating zig best practices and feel free to make suggestions
Successor of [this](https://github.com/ghostty-org/website/pull/147) pr
in the website repo
The renderer must track if the foreground, background, and cursor colors
are explicitly set by an OSC so that changes are not overridden when the
config file is reloaded.
Duplicating a test process via fork does unexepected things.
zig build test will hang
A test binary created via -Demit-test-exe will run 2 copies of the test suite
Extracted from #3110
Initial fix is relatively basic, and catching it with a test only
required a little bit of extra scrutiny of the cursor state after one of
the tests that we already had.
However, the fix revealed faulty dirty tracking logic throughout the
`cursorScrollAbove` function (and therefore bad results that were being
tested for when they should not have been). I've ended up clarifying
things, fixing the asserted dirty states in all the `cursorScrollAbove`
tests, and then finally implementing another very trivial fix that
catches the mistake.
Fixing the dirty tracking is really just an exercise in correctness
though, since when the scroll happens it inherently invalidates the
viewport, and therefore will trigger a full rebuild in the renderer...
unless, I guess, another operation is performed that cancels things out
and results in the viewport pin being in the same place as the previous
render, but that seems an exceptionally difficult scenario to make
happen on purpose much less accidentally.
This PR is almost entirely changes to comments and tests, there are only
2 lines of real code it changes, the one added to the start of
`cursorScrollAbove` and the one modified at the start of
`cursorScrollAboveRotate`. I believe these changes are entirely safe. (I
wonder if they might have a bad effect on our `vtebench` scrolling
performance though...)
Extracted from #3110
A simple fix, with a unit test that covers the issue. This could cause
memory corruption and crashes in fairly realistic scenarios, since it
can occur whenever `cursorAbsolute` is used to move to a page that
happens to be at capacity for some form of managed memory and the cursor
is carrying some managed memory with it (style, hyperlink, etc.).
I really wish Zig had affine types so we could make `cursorChangePin`
"consume" its argument so it can't be accidentally used afterwards... I
think I'll audit the rest of the codebase anywhere we use
`cursorChangePin` to make sure we don't have similar problems.
Accounts for improved behavior due to prior memory corruption fix for
`cursorScrollAboveRotate` and reveals a new problem in a different
`cursorScrollAbove` sub-function.
