Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2).

On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.



There are a good number of Emacs users who also use a Lisp dialect such as Scheme for their day-to-day work. Emacs Lisp has enough small, slightly strange differences from more mainstream Lisps that I can imagine that being kind of frustrating.

For myself I think that Emacs Lisp is a pretty good language for configuring a text editor. A lot of its warts actually make it easy to use in that context, in my opinion. Personally I wouldn't mind moving closer to Scheme or CL. Though I wouldn't want to lose "special" variables (with dynamic binding) no matter what happens -- they're a key tool in tweaking behavior to get it just how you want. But for people who are trying to build packages, especially large ones on the order of Org or Magit, I can see having a more, let's say production code oriented language, being a nice prospect.


Emacs Lisp now arguably has a better type inferencing compiler than SBCL[1].

[1] http://akrl.sdf.org/gccemacs.html#orge596749


Would this pure-gtk branch avoid GTK's famous X11 connection bug? https://gitlab.gnome.org/GNOME/gtk/-/issues/221

Every few years I'm tempted to try the GTK version of Emacs, but it doesn't take long before this bites me and I go back to Lucid!


Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?


pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.


No, I mean emacs was designed for terminals. The whole GUI is build ontop of this and is suffering from it. Is pure-gtk changing this and decouple from the terminal-design or still working with it, replicating the same hacks just in a different GUI?


Sorry, I just don't understand. I don't really use terminals except to do a system update. Is there a specific issue?


Terminals work with characters, meaning, lines, columns, fontsize. GUIs usually are working with pixel, meaning x/y-coordinates and free sizes.

In case of emacs this means there is a bunch of hacks to translate pixel-coordinates to line/column-coordinates. This often are working well enouhg, but sometimes not. For example, with my emacs there is always a free space at the bottom when maximising the window, Resizing the window also works in terms of lines, not pixels. Positioning of completion-dialogs is linked to chars, not the pixel-coordinates of a the word which in certain cases get's ugly.

It's overall not what I would call a hard issue, but still ugly. But it also kinda limits what you could do with Emacs in GUI-world. As Emacs has no understanding of z-axis, there are overlapping widgets and free-positioning of elements outside the text-flow.

An additionally, it seems the too many laysers and additional complexity has some speed-impact in GUIs which the terminal-version has not.


FYI There /is/ `frame-resize-pixelwise` and `window-resize-pixelwise`, to help with a few of those issues.


It also doesn’t offer smooth scrolling on macOS except in a third party port.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: