Comment by csmlab notes on "From Bytes to Glyphs: How a Terminal Emulator Actually Works"

On the wide-character part: when a double-width character arrives with only one column left, alacritty_terminal pads that cell with a LEADING_WIDE_CHAR_SPACER flag and wraps the character to the next line. Does MistTerm's run merging treat that leading spacer the same as the trailing WIDE_CHAR_SPACER cells, or does it skip it? Copying text across that wrap is where I'd expect a stray space to show up.

Yep — leading spacer is handled the same as the trailing one. In the egui path we skip both flags and don't put a real cell into the text run; copy goes through alacritty's bounds_to_string, which also drops those spacer cells. So you shouldn't get an extra space at the wrap. If you do hit a case where selection still picks one up, send a repro — that'd be on our selection path, not the merge.

Thanks, that makes sense. One edge I noticed in line_to_string: when a selection ends on the leading spacer but not on the wide char after the wrap, it appends that wide char anyway (the comment there reads "If wide char is not part of the selection, but leading spacer is, include it"). Does your egui selection highlight extend to the wrapped glyph in that case, or can copy pick up a character that wasn't highlighted?

Good catch — highlight and copy aren’t the same path. The egui paint only covers cells inside the selection, so if the selection ends on the leading spacer, the wrapped glyph on the next line stays unhighlighted. Copy goes through alacritty’s line_to_string, and that branch still appends the wide char when the spacer is selected and the glyph isn’t, so you can get a character that wasn’t highlighted. That’s upstream selection→string behavior, not the run merger. I’ll double-check against the current line_to_string before changing anything on our side.

Search Hashnode