Re: SDL terminal type

On Sat, 22 Aug 2026, at 08:00, Po Lu wrote:
> GTK has already proved to have no promise as a long-term expedient for
> supporting Wayland, and I suggest pursuing a terminal backend using the
> Wayland APIs directly instead.  I have always intended to do so, but
> there is a project at work preventing me from improving Emacs on Unix
> systems.  Moreover, SDL generally supports keyboard input, input
> devices, and input method editors poorly, as was discovered by Luanti
> when they adopted it:
>
>    https://github.com/luanti-org/luanti/issues/14545
>
> And at least one of these modalities is the prop and stay of Emacs,
> limitations in which are much less acceptable here than in a video game.
> (GTK 3.x itself has a similar problem preventing `C-S-u' and `C->' from
> registering which has been reported repeatedly.)

I'm really pleased to hear that you've considered this as I highly appreciate your work on the Android and Haiku support. Though I don't mean to pressure you, I'd argue that some form of accelerated rendering to Wayland is a high priority for Emacs. On GNU/Linux I cannot have all three of graphics, responsive input, and sharp rendering at high resolutions, whereas on non-free operating systems I can. At the moment I've switched to TTY Emacs inside Ghostty as it seems to have the least amount of problems with modifier keys. I don't believe that splitting Lisp off the UI thread will help because it won't matter if I'm waiting for the UI to finish a frame.

I have wondered if it's possible to pick and choose between parts of SDL that Emacs can use and parts that are unsuitable. For example, if SDL_render could be used to draw the terminal area, and other widgets like menus and toolbars be left to i.e GTK3 (notwithstanding that, as you mention, GTK is moving away from the kind of immediate-mode processing that Emacs needs). In this case visual consistency between Emacs and the desktop environment is retained and having to write a OpenGL or Vulkan or whatever renderer from scratch could be avoided. If it turns out that SDL_render needs SDL's event loop I understand if it'd be too much fuss.

I am extremely unemployed at present and I am pretty eager to use graphical Emacs on my computer again, so if you have an outline of what is needed I can work on this, unless you'd wish to start it yourself. I should warn though that I do not have much experience in working on such a large feature. I am loath to run an LLM on Emacs's source to have it figure out the details of the internal terminal APIs, so I'd suggest that some form of internal documentation on the terminal code, based off the newer backends like nextstep, Android and Haiku, would be very helpful for porting Emacs to another window system.