{{ message }}
Repository navigation
IME pre-edit is rendered differently than the committed text #8709
Description
I have an IME that allows me to enter characters by their unicode code point.
For example, if I invoke the IME and then enter a9, the pre-edit in alacritty looks like this:
U+a9 = ©When I press enter, this becomes
©However, if I instead enter control characters, the output is unexpected:
After pressing enter, I get the expected output ^A and ^B for the first two and the effects of Ctrl-C and Ctrl-D for the latter two.
Activity
chrisduerr commentedon Oct 17, 2025
I'm not sure where the IME is getting its character representations from, but in principle at least that's not entirely surprising to me. Your issue seems to be with what the IME displays, not Alacritty's actions, so that's up to the IME.
mahkoh commentedon Oct 17, 2025
The IME does not display anything. Alacritty draws the string here:
alacritty/alacritty/src/display/mod.rs
Line 1129 in a513d13
For comparison, here is how chrome handles this:
Which makes sense because U+1 = SOH: https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C0_controls
kchibisov commentedon Oct 17, 2025
maybe shaping issue? Could you share the log from
winit?mahkoh commentedon Oct 17, 2025
I don't know how to do that, but here are the logs from alacritty:
The font at the end is loaded when the preview for the control character appears.
kchibisov commentedon Oct 17, 2025
Ah, sorry for not providing instruction.
--print-eventsshould do that.mahkoh commentedon Oct 17, 2025
kchibisov commentedon Oct 17, 2025
Given that character is the same in
PreeditandCommitthey should render the same, so will open to look into it.sigprof commentedon Oct 31, 2025
The mentioned Terminus font has glyphs in the 0x00...0x1F range which match the old X11
fixedfont (AFAIK Xterm used at least the line drawing characters from that range):Maybe Alacritty should perform some preprocessing to avoid rendering characters from the C0 control code range directly, so that it won't be tricked by such fonts with nonstandard encodings.
kchibisov commentedon Nov 9, 2025
Isn't the whole issue is that control bytes can not be rendered really, because they are control sequences, thus even if you type
0x01, it'll either be altered by kernel to entered as^A, or it'll beexecuted by alacritty (and thus ignored, since we ignore \0xa1) in particular?But IME preview is not aware of any of that, thus it just renders characters as is according to the font. Chrome also being a GUI application doesn't have an issue of actually reacting to those bytes, etc, etc.
So, I'd say that the display is correct, it's just it cannot be represented as it originally was in 0x01 form later on.
Yeah, that's what it sounds like. @chrisduerr what do you think for doing that for IME preview, otherwise they'll always be desynced?
chrisduerr commentedon Nov 9, 2025
That's essentially my take, yes. That's why I closed the issue.
Well we technically don't know what it's actually going to look like. So the argument of "keeping it in sync" is something I disagree with. Having a nicely rendered version for these characters is an argument I can somewhat get behind, but that's something fonts can already do as shown in terminus (the terminus font itself is just broken).
I'm not sure if explicitly replacing these glyphs makes sense, though I do see why you would always want some renderable representation. That said, why should Alacritty be doing that? If IME is requesting us to render text, and that text is considering invisible characters, why should Alacritty replace these characters? That doesn't make sense to me and seems like something IMEs would actually find harmful. If your IME doesn't want the invisible character, why are they sending it?