| <!DOCTYPE html> | |
| <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang=""> | |
| <head> | |
| <meta charset="utf-8" /> | |
| <meta name="generator" content="pandoc" /> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" /> | |
| <title>GHOSTTY(5) Version 0.1.0-HEAD+23c92414 | Ghostty terminal emulator configuration file</title> | |
| <style> | |
| html { | |
| line-height: 1.5; |
In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.
The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
| /// Returns a ComptimeStringMap for all of the capabilities in this terminfo. | |
| /// The value is the value that should be sent as a response to XTGETTCAP. | |
| /// Important: the value is the FULL response included the escape sequences. | |
| pub fn xtgettcapMap(comptime self: Source) type { | |
| const KV = struct { []const u8, []const u8 }; | |
| // We have all of our capabilities plus To, TN, and RGB which aren't | |
| // in the capabilities list but are query-able. | |
| const len = self.capabilities.len + 3; | |
| var kvs: [len]KV = .{.{ "", "" }} ** len; |
| /// This is demonstrating a strange behavior that I can't explain. | |
| /// | |
| /// This is a minimal SwiftUI application that renders a NSView that only implements NSTextInputClient, allowing | |
| /// it to behave like a text input field. The implementation is minimal. Any characters you type will be logged | |
| /// to the console wit the codepoints that are inserted. If you type "a" you should see "97" in the logs, for example. | |
| /// | |
| /// 1. Launch the program with the US traditional ("US") keyboard layout. | |
| /// 2. Type characters and notice they are logged. | |
| /// 3. Type a control character such as enter, backspace, notice they are _not_ logged (this is fine). | |
| /// 4. Switch to US international ("us-intl") keyboard layout. |
| //! Renderer implementation for Metal. | |
| //! | |
| //! Open questions: | |
| //! | |
| pub const Metal = @This(); | |
| const std = @import("std"); | |
| const builtin = @import("builtin"); | |
| const glfw = @import("glfw"); | |
| const objc = @import("objc"); |
| //! A zig builder step that runs "libtool" against a list of libraries | |
| //! in order to create a single combined static library. | |
| const LibtoolStep = @This(); | |
| const std = @import("std"); | |
| const Step = std.build.Step; | |
| const RunStep = std.build.RunStep; | |
| const FileSource = std.build.FileSource; | |
| pub const Options = struct { |
| const std = @import("std"); | |
| const builtin = @import("builtin"); | |
| const assert = std.debug.assert; | |
| const Allocator = std.mem.Allocator; | |
| const ArenaAllocator = std.heap.ArenaAllocator; | |
| const StreamingParser = std.json.StreamingParser; | |
| const Token = std.json.Token; | |
| const TokenTag = std.meta.FieldEnum(Token); | |
| /// Field options are options that can be set per-field on a struct at |
| const std = @import("std"); | |
| const assert = std.debug.assert; | |
| const Allocator = std.mem.Allocator; | |
| const builtin = @import("builtin"); | |
| const log = std.log.scoped(.flatpak); | |
| /// Returns true if we're running in a Flatpak environment. | |
| pub fn isFlatpak() bool { | |
| return if (std.fs.accessAbsolute("/.flatpak-info", .{})) true else |_| false; |
| const std = @import("std"); | |
| const assert = std.debug.assert; | |
| /// An intrusive heap implementation backed by a pairing heap[1] implementation. | |
| /// | |
| /// Why? Intrusive data structures require the element type to hold the metadata | |
| /// required for the structure, rather than an additional container structure. | |
| /// There are numerous pros/cons that are documented well by Boost[2]. For Zig, | |
| /// I think the primary benefits are making data structures allocation free | |
| /// (rather, shifting allocation up to the consumer which can choose how they |