LWN: Comments on "Wayland support (and more) for Emacs"

Wayland support (and more) for Emacs

ocrete — Tue, 20 Jul 2021 16:56:21 +0000

It's really saved Emacs for me too using fractional scaling on my nice 4K display.

A huge thanks to the developers who did all the hard work.

Wayland support (and more) for Emacs

Hi-Angel — Sat, 20 Feb 2021 21:39:06 +0000

I'm kinda confused… Isn't there such list in lsp-mode's website https://emacs-lsp.github.io/lsp-mode/page/languages/

Wayland support (and more) for Emacs

pclouds — Fri, 12 Feb 2021 03:44:50 +0000

The problem with closing display is still there, but tracked elsewhere in https://gitlab.gnome.org/GNOME/gtk/-/issues/2315

Wayland support (and more) for Emacs

ejr — Thu, 11 Feb 2021 14:55:11 +0000

Gimp? That was the G in GTK.

Wayland support (and more) for Emacs

flussence — Fri, 05 Feb 2021 02:49:07 +0000

All things considered, Emacs deserves some congratulations for getting out a release with GTK3 support so soon. I would've expected the G in GTK to get there first.

Wayland support (and more) for Emacs

nix — Thu, 04 Feb 2021 17:36:44 +0000

Try disconnecting and connecting again on a *new X server*. Gtk used to get very confused in this case (but of course with an emacs --daemon on a remote host it is routine).

This was definitely still happening with Gtk 3 as of two or three years ago.

Wayland support (and more) for Emacs

mtk — Thu, 04 Feb 2021 13:43:52 +0000

as an emacs user since 1979(!) and a developer, i've always thought the primary challenge faced by emacs came from IDE's that parsed & analyzed edited source and made that semantic info available in useful ways. LSP is a great start and has generated lots of related tool development. but i'm lazy and don't want to spend months figuring out which language-specific back end (how many are there for python now?) or completion library from MELPA to use with it. i want a *curated* collection of LSP tools incorporated into the core.

Wayland support (and more) for Emacs

yaap — Thu, 04 Feb 2021 11:00:34 +0000

Sometimes I use Emacs in daemon mode with a Gtk build: "GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)". Connecting with gnuclient, closing the unique frame, and reconnecting later with a new frame has never been a problem. From what I understand this is the sort of client/server use that triggered the bug.

In the Gtk bug you pointed to a maintainer comment at the end says the ticket was closed as now irrelevant, being related to a Gtk2 issue (an I use Gtk3). I don't use the daemon mode much in the end, so don't really stress it, but so far it worked for me.

Wayland support (and more) for Emacs

nix — Tue, 02 Feb 2021 17:40:32 +0000

> Nonetheless, it was one of the first signs that Emacs may be moving away from X.

This is unlikely given the understandable but still notable lack of interest from the Gtk developers in bugs, some very old, which completely break important Emacs workflows: there are a bunch of obscure ones involving fonts (most of which seem to have been fixed now, probably as a result of the harfbuzz push): the big remaining one has to be https://gitlab.gnome.org/GNOME/gtk/issues/221... and note that it's unclear if this is *actually* a bug any more but in over a year nobody has checked. (I'm planning to check when I eventually bite the bullet and upgrade to 27.1, but my Emacs is so crucial and breaking it is so disastrous that I hardly ever upgrade it!)

One problem here is that Emacs does things with the display that more or less no other program does, so of course toolkit developers aren't going to care much about fixing them since fixing them only affects one program. The big one is to open multiple sorts of display connections at once, and outlive them. This is usually done via emacs --daemon, but can be done directly without that being involved at all: you can open terminal connections on Emacsen started connected to X, you can open X connections on Emacsen started connected to the console or to nothing at all, then closing them and having Emacs keep running, then reopening them later and everything still works... I think one variant that doesn't work is having all three of Win32 *and* X *and* console connections at once in an Emacs started on the console, because of limitations in the Win32 API, but every other combo I'm aware of works -- except Gtk. Close a Gtk connection and reopen it later and -- a decade ago, anyway -- Emacs crashed horribly inside Gtk. Whether it still crashes is, ah, unclear, but this sort of thing is a very common use case for those Emacs users who run our editors on beefy machines that aren't our desktop: we want the Emacs and all its state to persist even when the desktop is rebooted. So I doubt the crusty old core developers will allow the old Lucid X toolkit to be torn out until that problem is actually confirmed fixed.

Wayland support (and more) for Emacs

tgerdin — Mon, 01 Feb 2021 22:41:41 +0000

I think the commenter was referring to the required string conversion when moving between Emacs Lisp and Guile.

Wayland support (and more) for Emacs

swilmet — Fri, 29 Jan 2021 21:09:18 +0000

> if there are developers who could provide GTK help

While I cannot help for the Emacs's GTK code, I have written this guide:
https://people.gnome.org/~swilmet/glib-gtk-book/

To understand the GTK API, a basic knowledge about GLib and GObject is required. That's what the guide describes (bottom-up approach).

You may also be interested by the Emacs "plugin" for Devhelp, the API browser:
https://wiki.gnome.org/Apps/Devhelp
https://gitlab.gnome.org/GNOME/devhelp/-/blob/master/plug...

Wayland support (and more) for Emacs

zuki — Fri, 29 Jan 2021 14:26:29 +0000

I installed the version from Fedora copr, and I'm very pleasantly surprised. The font rendering is, wow, much crispier. This is most likely because of a hidpi screen. Compared to the wayland version, the Xwayland version is simply blurry.

Wayland support (and more) for Emacs

daenzer — Fri, 29 Jan 2021 13:41:40 +0000

GTK4 uses OpenGL for its drawing by default, so that one stone should get an extra bird.

Wayland support (and more) for Emacs

dottedmag — Fri, 29 Jan 2021 09:43:41 +0000

Oh, wonders. I was thinking of doing the port myself, and... it is already done!

Wayland support (and more) for Emacs

felixfix — Fri, 29 Jan 2021 05:02:13 +0000

I got a tape in 1989 or 1990 to port to a "Regulus" real-time Unix whose file names had two fewer characters. That was quite a chore but I got it working.

Wayland support (and more) for Emacs

atai — Fri, 29 Jan 2021 01:03:41 +0000

not knowing the details, but it would seem strange that scheme and Emacs Lisp have semantic gap in boxing and unboxing...

Wayland support (and more) for Emacs

iabervon — Thu, 28 Jan 2021 23:30:51 +0000

It's definitely the case that Emacs has some special complicated data types, and one of these is what Emacs considers an ordinary string.

Wayland support (and more) for Emacs

mmaug — Thu, 28 Jan 2021 22:29:04 +0000

I had spoken with one of the Emacs/Guile developers at LibrePlanet in '17 or '18 (I think). Performance was definitely an issue, but a lot of that problem was rooted in the fact that Emacs and Guile represented text chunks in very different ways and the need to convert back and forth between the two. I do not remember the details, but there was some discussion of the issue in the repo along side of the code. Unlike the GUI, Lisp is fundemental to the Emacs engine itself and the extra boxing/unboxing on every Lisp call is neither trivial nor efficient regardless how much faster the Lisp engine itself is. From what I recall of the conversation, this was seen as a significant problem and neither interest nor resources were available to address it.

Wayland support (and more) for Emacs

jem — Thu, 28 Jan 2021 19:41:37 +0000

Guile Emacs's startup speed was/is slower, not the speed in general. Also, the ability to run "most" Emacs Lisp was the state of things in 2014. In 2017 version 2.2.0 was released, which "provided a complete Emacs-compatible Elisp implementation, implementing all of Elisp's features and quirks in the same way as Emacs."

Wayland support (and more) for Emacs

IanKelling — Thu, 28 Jan 2021 19:13:00 +0000

> real consideration

I should have said real preparation or momentum to switch. But, I do agree there is a social problem as well.

Wayland support (and more) for Emacs

IanKelling — Thu, 28 Jan 2021 19:11:23 +0000

> able to reliably run most Emacs Lisp code." And yet the reaction has been: "meh".

Afaik, it ran significantly slower. Also "most" needs to be more specific. Before any real consideration it would need to be really close, like 99%, "most" could mean 80%.

Wayland support (and more) for Emacs

jem — Thu, 28 Jan 2021 18:39:05 +0000

Other desired changes are more "socially easy", but are hard technically; these include making elisp faster so that more of Emacs could be written in Lisp rather than C.

We have GNU Guile 3.0, which features a JIT native code generator, and provides a "complete Emacs-compatible Elisp implementation"¹. Work on Guile-emacs was started maybe a decade ago, and "as of October 2014, the implementation had reached a stage where Guile Emacs is able to reliably run most Emacs Lisp code." And yet the reaction has been: "meh".

I really doubt a faster Elisp isn't a social problem.

Wayland support (and more) for Emacs

atai — Thu, 28 Jan 2021 18:28:58 +0000

May you still get code from/to RMS, in whatever medium appropriate for that time, at 2085.

Wayland support (and more) for Emacs

JoeBuck — Thu, 28 Jan 2021 17:33:48 +0000

I remember getting the tape (probably made by RMS himself) in the mail at work in '85 or '86 (yes, I'm, shall we say, experienced). I also remember the skull drawing in the comment block above the display code.