- Output to stdin instead of a file
- Less nesting
- Utilize ranged for loops instead of while loops
- Eliminate unnecessary state tracking
- Put help in a struct
Doc strings attached to fields of the Config struct and doc strings
attached to the run function of actions will be used to generate Zig
code that makes those doc strings available to be used at runtime.
Based on PR #853 by @Raiden1411
This gets `zig build -Dtarget=aarch64-ios` working. By "working" I mean
it produces an object file without compiler errors. However, the object
file certainly isn't useful since it uses a number of features that will
not work in the iOS sandbox.
This is just an experiment more than anything to see how hard it would be to
get libghostty working within iOS to render a terminal. Note iOS doesn't
support ptys so this wouldn't be a true on-device terminal. The
challenge right now is to just get a terminal rendering (not usable).
Generate Vim syntax and ftplugin files for the Ghostty config file that
highlight Ghostty config keywords and offer completion for valid config
keys. The list of configuration keys is generated at compile time.
The plugin files are installed to ${prefix}/share/vim/vimfiles, which is
a standard location for installing 3rd party Vim plugin files.
Installing resources directly under ${prefix}/share causes conflicts
with other packages. This will become more problematic whenever Ghostty
is opened and becomes packaged in distributions.
Instead, install all resources under a "ghostty" subdirectory (i.e.
${prefix}/share/ghostty). This includes themes, shell integration, and
terminfo files.
Only "/usr/share" style paths use the "ghostty" subdirectory. On macOS,
Ghostty is already isolated within its app bundle, and if
$GHOSTTY_RESOURCES_DIR is set then we assume that points to the actual
resources dir (without needing to append "ghostty" to it).
This uses separate strings for the keys for the conformance tests versus
just deriving them from the sliced path.
This fixed an issue for me where a few of the tests were showing up as
InvalidConformance (notably the "blocks" test), even though, oddly
enough, the key/value entries do appear to be there (e.g. if you iterated
over them). I did notice, though, that we currently sliced the key from
the file entry of the directory iterator, which is closed at the end of
conformanceSteps.
