Pre-edit text is drawn in reverse video, and there is no way to change it

While using IBus in kitty I noticed the pre-edit ("undecided") text is rendered in reverse video. Other applications on the same desktop underline it, following the attributes IBus supplies in `IBusAttrList`. In running text the inversion is considerably more distracting than an underline — it's a solid block moving through the line as you type. I can't find any way to change it. There is nothing for pre-edit styling in `kitty/options/definition.py`, and the styling is a single hard-coded line in `screen_draw_overlay_line()`: ```c // kitty/screen.c self->cursor->sgr.reverse ^= true; ``` That dates back to 5b1eaa741, the original "show the pre-edit text while the IME is in progress" commit, so I assume it was a first-cut choice rather than a considered one — but tell me if there's a reason for it I'm missing. ### The question behind this That attribute list describes how to decorate the pre-edit run — underline, foreground, background, each with a scope. It is visible in the very message glfw parses; the docstring in `glfw/ibus_glfw.c` shows it: ``` variant struct { string "IBusText" array [ ] string "ash " variant struct { string "IBusAttrList" <-- attributes array [ ] array [ ] } } ``` but `get_ibus_text_from_message()` extracts only the string and discards the attribute list, so by the time `screen.c` draws it there is nothing left to honour and a blanket style is the only option. For CJK conversion that loses a distinction that carries meaning: engines typically mark the segment currently being converted differently from the rest of the pre-edit run. Collapsing all of it into one inverted block hides which segment is active. ### What I'd propose Honouring the attributes properly is the "right" fix but a much larger job, and I don't want to assume you want that complexity for a feature this peripheral. The cheap version would be an option: ```conf ime_preedit_style reverse # current behaviour, default ime_preedit_style underline # straight underline ime_preedit_style curly # etc. ``` `Cursor.sgr` already carries `uint8_t decoration` alongside `reverse`, and kitty already renders all six underline styles, so the draw site becomes a lookup instead of a toggle — no new rendering work. Happy to implement whichever you prefer, or to drop it if you think the current behaviour is right for a terminal specifically. I can see the argument that underline collides with genuinely underlined output in a way it doesn't in a GUI text field, and that pre-edit displacing real line content is worth making unmistakable. Two questions, then: 1. Would you take an option here at all, or is this better left alone? 2. If yes — a simple style option, or would you rather the IBus attributes were plumbed through and honoured, with the option only as a fallback?