A user reported that ctrl-c and ctrl-\ had no effect
for them in bash when spawned in a particular way
on their system. It turned out that the spawning
environment had blocked SIGINT, SIGHUP and SIGQUIT
and that was propagated all the way down through
the wezterm process to the spawned shell.
Let's ensure that we clear all blocked signals
prior to launching our child process.
This one was a bit weird because something appeared to be a bit
non-deterministic. With this config:
```lua
local wezterm = require 'wezterm'
return {
window_frame = {
border_left_width = '1cell',
border_right_width = '1cell',
border_bottom_height = '0.5cell',
border_top_height = '0.5cell',
border_left_color = '#444',
border_right_color = '#444',
border_bottom_color = '#444',
border_top_color = '#444',
},
window_padding = {
left = '1.5cell',
right = '1.5cell',
top = '0.5cell',
bottom = '0.5cell',
},
}
```
starting wezterm could result in a terminal that reported either 23 or
24 lines. I got 24 when running the build from da7e29df but usually
23 when running a build out of my repo.
Looking closely, the issue is that the initial window size didn't
account for the configured border size, and that we'd subsequently
fix that up when we later do a resize fixup after creating the window.
This commit refactors the window border logic so that it can be
used prior to having fully constructed the terminal window and then
uses that to fixup the initial computed dimensions.
I also noticed with this config that increasing the font size
with CTRL-+ could also result in an inconsistency between the displayed
terminal size and the pty size we set in the kernel: it was missing
the border adjustment as well, so I added it in there.
refs: #3333
Really, this is adjusting the logical line breaking behavior, or the
lack thereof.
The situation is this: conpty can decided to reinterpret and flush
large sections of its buffer as a continuous stream of unbroken
characters with no breaks when it repaints the full screen.
When we receive such an update, we see it as one long logical line,
and when we subsequently select multiple lines we can run into the
maximum logical line length and insert invalid synthetic line breaks
into the data that we send to the clipboard.
This commit adjusts the wrapping logic at the time that we receive
the text so that we don't tag the line as a logical line continuation
if:
* The alt screen is active. Full screen apps will re-render on resize
anyway, and we don't reflow long lines on resize either for the same
reasons
* If we are talking to ConPTY:
* If the last character in the line is not alphanumeric or
punctuation (in other words: it doesn't look plausibly like
text that should be a line continuation).
refs: #3278
refs: #3177
* Update ssh_backend.md
* Update normalize_output_to_unicode_nfc.md
* Update strikethrough_position.md
* Update underline_position.md
* Update underline_thickness.md
* Fix lua config docs titles to be formatted as inline code
* Mention how suggested alphabet for quick select is choosen
* Mention update-status and update-right-status for status_update_interval
* Fix docs for all keyassignments to be formatted as inline code
* Fix Lua object index titles
* Fix titles of `wezterm.*` module index pages
* Fix title of `Color` object & `wezterm.color` functions
We reduce titles from h2 to h1 because mkdocs defaults the page title to
the page file name if no h1 header is found.
* Unify title of all object methods
* Add index page for Gui events
Fixes this:
```
> wezterm.GLOBAL.foo = {"bar", "baz"}
> wezterm.GLOBAL.foo
[
"bar",
"baz",
]
> #wezterm.GLOBAL.foo
runtime error: [string "repl"]:1: attempt to get length of a userdata value (field 'foo')
stack traceback:
[string "repl"]:1: in main chunk
>
```
and allows this:
```
> for k, v in pairs(wezterm.GLOBAL.foo) do print(k, v) ; end
```
Hello, I encountered some issues when upgrading to latest version with Homebrew. I believe this would be the required change is that correct?
Or should 20.04 be used? 22.04 is LTS as well.
Pull in the enhanced scheme that includes wezterm metadata and colors.
Co-authored-by: Thomas Croft <103956335+thomascft@users.noreply.github.com>
closes: https://github.com/wez/wezterm/pull/3208
