In https://github.com/wez/wezterm/issues/2932 the user desired to have
brightened text without the boldness, as they were accustomed to that
behavior in a couple of other terminal emulators.
This commit changes the `bold_brightens_ansi_colors` from a simple
boolean to a tristate that allows for not changing the brightness,
changing the brightness, and changing the brightness while adjusting
the boldness down to normal levels.
boolean values are accepted for backwards compatibility.
This avoids a jarring situation where the width rubber-bands to fit
a run of narrower text when scrolling down through the list of options.
refs: https://github.com/wez/wezterm/issues/1485
```
thread 'main' panicked at 'Error in Surface::configure: Both `Surface` width and height must be non-zero. Wait to recreate the `Surface` until the window has non-zero area.', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.14.0\src\backend\direct.rs:274:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
refs: https://github.com/wez/wezterm/issues/2881
This is moderately painful to do, because of some objc/cocoa lifetime
concern that causes a crash when attempting to simply replace the
entire menubar, so we try to find/update items instead.
refs: https://github.com/wez/wezterm/issues/1485
Fixup CopyMode key assignments; they were all incorrectly
labelled as activating copy mode, which isn't correct.
We're just using Debug labelling for them at the moment,
need to get that fixed properly.
refs: https://github.com/wez/wezterm/issues/1485
This commit safely registers key equivalents with the menubar. Safe in
this context means "doesn't override a key assignment from a key table".
For example, it would suck to define an application-wide key assignment
for a key combination that has a different assignment in a key table
that may be activated conditionally by some user-defined state/mode.
refs: https://github.com/wez/wezterm/issues/1485
Similar to the equivalent functionality in the launcher menu,
syntheisze some default commands based on the current state
of the launcher menu (config) and mux (domains, workspaces).
This does mean that the launcher menu may show duplicates for these
if it has COMMANDS enabled.
refs: https://github.com/wez/wezterm/issues/1485
This commit introduces a rough first pass at a command palette modal.
It is an adaptation of the emoji character selector and needs
refinement.
Importantly, the default pane selector key assignment now calls
into this new command palette instead.
refs: https://github.com/wez/wezterm/issues/1485
re-structure it so that we have a list of default action values,
and a function that can compute the command description from them.
This allows describing user-specified actions in the future,
as well as reducing some boilerplate: we can now generate eg:
ActivateTab(n) description text without hardcoding similar
alternatives.
refs: https://github.com/wez/wezterm/issues/1485
This allows defining those help actions that open URLs in the main
commands list, and not just for the macOS Help menu.
refs: https://github.com/wez/wezterm/issues/1485
This took a decent amount of effort to thread through with context;
wrappers around NSMenu and NSMenuItem are added to reduce some of
the objc usability warts, and an additional NSObject wrapper is
added to help copy the KeyAssignment from the existing list
of command palette commands and associate it with the menu item.
When a menu item is selected, macOS will walk through the responder
chain and look for a responder that responds to the selector associated
with the menu item. In practice that means that our window/view class
will be tried first, and then later, our app delegate will be tried.
This commit implements routing from both of these: the window case
routes to the associated TermWindow and drops into the existing
perform_key_assignment method.
In case there is no window (not currently possible, but will be
in the future), the app delegate also has a placeholder for dispatching
key assignments, although it will only be able to perform a subset
of the possible actions.
A couple of things to note:
* Items aren't smart enough to disable themselves or adjust their
caption based on the context. To make that work, we either need
to recreate the entire menubar when any possible context changes
(doable, but feels heavy), or we need to assign a target to each
menu item and implement a validation handler on that target.
That seemed to mess with the responder chain when I briefly
experimented with it.
* There's some disabled code to add a Services menu. It is disabled
because when it is enabled, accessing either Services or Help
from the menu bar sends the process into a busy loop somewhere
in macOS's internals. It's unclear what it is unhappy with.
* No keyboard accelerators are associated with the menubar yet.
That needs some thought, as they would essentially become global
keyboard shortcuts and take precedence over the shortcuts defined
for other keys in the config. This feels like it should be something
that the user has control over, so there needs to be something to
allow that before we go ahead and wire those up.
refs: https://github.com/wez/wezterm/issues/162
refs: https://github.com/wez/wezterm/issues/1485
This allows removing a bunch of unwrap/expect calls.
However, my primary motive was to replace the cases where we used
Mux::get() == None to indicate that we were not on the main thread.
A separate API has been added to test for that explicitly rather than
implicitly.
Implement an app delegate to receive a callback when the system
requests that we open `.command` files, and then ask the mux
layer to spawn a window for it and execute it via the shell.
Also allow handling `.sh`, `.zsh`, `.bash`, `.fish` and `.tool`,
per kitty.
refs: https://github.com/wez/wezterm/issues/2741
refs: https://github.com/wez/wezterm/issues/2871
