Re: SDL terminal type

Po Lu <[email protected]>
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
"Lina Bhaile" <[email protected]> writes:

> 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.

I 100% agree, but this neither requires SDL nor is a consequence of
vector graphics or using window system's raster graphics library for
rendering as such (for example, X servers accelerate all graphics
operations performed by Emacs when possible, i.e. on practically all
modern systems).

> 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.

Please do let's leave GTK out of any future windowing arrangements for
Emacs :-)

> 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.

It wouldn't be necessary to use any toolkit in order to obtain window
decorations, which is really all that SDL provides on Wayland.  Instead
it would be sufficient to link to:

   https://gitlab.freedesktop.org/libdecor/libdecor

It is the same standard interface for window decorations on Wayland
which is used by SDL.  It would also be possible to port the oldXMenu
library to Wayland, used on X when no toolkit is enabled, or to provide
something like to it there, inasmuch as this has already been achieved
for MS-DOS.  This would also be sufficient to satisfy Emacs's
requirements.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.