Note that this includes some failing tests because I want to make the
uri handling better and more specific. It's a little bit too general
right now so I want to lock it down to:
1. macOS only; and
2. valid mac address values
because that's how the macOS private Wi-Fi address thing works;
randomizes your mac address and sets that as your hostname.
I am actually not sure if this was meant as a sly pun. It definitely works that way, terminals are _de jour_ meaning _of the day_, but the contrastive with _de facto_ makes me lean toward typo / malaprop.
The thing is it's a good pun, and I almost let it be for that reason. But I lean towards unintended, so here's a patch, feel free to close it if I read it wrong, er, right? Y'know.
Some Intel MacBook Pro laptops have both an integrated and discrete
GPU and support automatically switching between them. The system
uses the integrated GPU by default, but the default Metal device on
those systems is the discrete GPU. This means that Metal‐using
applications activate it by default, presumably as the intended
audience is high‐performance graphics applications.
This is unfortunate for productivity applications like terminals,
however, as the discrete GPU decreases battery life and worsens the
thermal throttling problems these machines have always had. Prefer
to use an integrated GPU when present and not using an external GPU.
The behaviour should be unchanged on Apple Silicon, as the platform
only supports one GPU. I have confirmed that the resulting app runs,
works, and doesn’t activate the AMD GPU on my MacBook Pro, but have
not done any measurements of the resulting performance impact. If
it is considered sufficiently noticeable, a GPU preference setting
could be added.
See <https://github.com/zed-industries/zed/issues/5124>,
<https://github.com/zed-industries/zed/pull/13685>,
<https://github.com/zed-industries/zed/pull/14738>, and
<https://github.com/zed-industries/zed/pull/14744> for discussion,
measurements, and changes relating to this issue in the Zed
project. The logic implemented here reflects what Zed ended up
settling on.
The [Metal documentation] recommends using
`MTLCopyAllDevicesWithObserver` to receive notifications of when
the list of available GPUs changes, such as when [external GPUs
are connected or disconnected]. I didn’t bother implementing that
because it seemed like a lot of fussy work to deal with migrating
everything to a new GPU on the fly just for a niche use case on a
legacy platform. Zed doesn’t implement it and I haven’t heard
about anyone complaining that their computer caught fire when they
unplugged an external GPU, so hopefully it’s fine.
[Metal documentation]: https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/multi-gpu_systems/finding_multiple_gpus_on_an_intel-based_mac
[external GPUs are connected or disconnected]: https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/multi-gpu_systems/handling_external_gpu_additions_and_removalsCloses: #2572
This fixes a hack we had around apple paths since we do this now
upstream in zig-objc. This also adds in support for NSFastEnumeration
needed for #2586
Fixes#2565
This appears to be a bug in macOS 15. Specifically on macOS 15 when the
new native window snapping feature is used, `cascadeTopLeft(from: zero)`
will move the window frame back to its prior unsnapped position.
The docs for `cascadeTopLeft(from:)` explicitly say:
> When NSZeroPoint, the window is not moved, except as needed to constrain
> to the visible screen
This is not the behavior we are seeing on macOS 15. The window is on the
visible screen, we're using NSZeroPoint, and yet the window is still
being moved. This does not happen on macOS 14 (but its hard to say
exactly because macOS 14 didn't have window snapping).
This commit works around the issue by saving the window frame before
calling `cascadeTopLeft(from: zero)` and then restoring it afterwards
if it has changed.
I've also filed a radar with Apple for this issue.
adw_application_window_destroy and gtk_application_window_destroy do not
exist. I believe that this didn't trigger a compile error because the
errdefer got compiled out because there are no potential error returns
after this code in the function.
The explanation now refers to RFC 793 instead of just claiming some
arbitrary value as truth. The previous value was correct, but now there
is a proper source for the correct value.
Fixes#2537
This matches Terminal.app. iTerm2 requires cmd+option (our old
behavior). Kitty doesn't seem to support rectangle select or I couldn't
figure out how to make it work. WezTerm matches Terminal.app too.
Outside of terminal emulators, this is also the rectangular select
binding for neovim.
Fixes#2519
This sets up the colorspace for terminal windows in the base controller.
This also modifies some of our logic so its easier for subclasses of
base controllers to specify custom logic when the configuration reloads,
since that's likely to be a common thing.
When resetting the terminal screen, the memory buffer allocated for the
scrollback is now cleared by reinitializing the screen and falling back to the
current method if any of the attempts to reinitialize fail.
Closes#2464
