Emacs GUI Library

So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. It's the most Emacs way of doing things.

However! There is one big thing you lose. I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. And it is currently the case that programs written for Emacs almost always degrade smoothly from the graphical display to the terminal, which makes Emacs apps like ement.el, nov.el, or mastodon.el the absolute best TUIs available for their respective tasks. That's something I'd dearly hate to lose.

You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot, and gives you something possibly not much better than what we have now.

This post just made me check out XWidget support in Emacs, and oh my bejebus is this amazing.

Yes, it's not like running an actual browser, but this is so much better than anything I expected.

https://macowners.club/posts/using-xwidgets-on-macos/ gave me a quick and nice overview of how it looked.

Anybody should feel free to do what they like to emacs, it's free software. But this would be a fork I would have absolutely no interest in whatsoever.

The author sees the fact that emacs UIs are textual as a negative, but it's the reason I love it, the reason I've been using it for 20 years and I dare say the reason some have been using it twice as long. Ditching terminal support and replacing emacs TUIs with GUIs would not be progress, and if that's what you want I doubt modifying emacs is going to be a rewarding way of trying to achieve it. Just use vscode.

Recently I've been consolidating my workflow. First is using a single monitor, and then using shortcuts to switch to other Windows when I need to. I find that for me it's easy to get distracted when I have multiple different Windows up.

I also have moved from a workflow in Emacs where I split my buffer and have things side by side, to one where I make new frames and then flip to the frames. This is easier on my eyes as I can have a large window for larger fonts, and I don't have to deal with wrapping in both Windows.

I love Emacs but I agree with the poster about how everything as text can have its drawbacks. I'd love to see a NeoEmacs that addresses some of these issues

> Speaking of terminals, Emacs can actually run in a terminal! You can start it with emacs -nw and it will happily transform your terminal into Emacs.

I love how this is written, as if there wasn't a time that running emacs in the terminal was the only way to run emacs.

> Lately, my Magit buffer broke once again because of something weird going on with major mode

It's 2023, and emacs still sucks in exactly the same way as it did when I first used it in 1995, and when I last used it for everyday coding in 2009-2010. Every time I tried to buff emacs with extra functionality, I found it constantly breaking. I would post to mailing lists about code changes I had to make to get modes working, and I found that other users treated it as a totally normal part of the user experience to have to rewrite some code to get things working in your setup. Comments like this let me know that it happens even to the emacs gurus; they just don't mind it as much and (presumably) can fix it faster than the rest of us.

Emacs doesn't need a GUI library. It needs a rewrite with a different architecture for modern times, and people who love emacs should keep trying despite the many past failures.

Correction: emacs doesn't need anything. It can continue in its present form for decades, but I think it would be nice if it had a bigger, brighter future that might bring me back to it someday.

> And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs?

Because I'm doing non-trivial (but probably not extensive) work on a server that does not have windowing.

Tramp is a hassle for some use cases, especially if you use SSH FIDO to authenticate; either you need set up the session somewhere and use SSH channel multiplexing from a session you established previously, and some protected environments limit the number of channels per SSH connection (often, to one).

Handling a text terminal emulator is a lower common denominator for sure than elisp to fulfill those functions.

I'd also like to point out that emacs has been praised by those with issues with their eyesight for its textual interface working with screen readers far better in practice. Other applications inevitably break their accessibility far more often, because their programming model makes it more expensive to do and keep in good order.

I don't mean to suggest this is how "text editors oughta be," but it's good at least one editor is this way, in regard to its relationship to UI elements and text.

I tried to switch to EMacs a year or so ago. I used it for a couple months and I enjoyed the configurability in elisp.

One of the last straws for me was that when scrolling down, the cursor moved to stay on the screen. This is one of the quirks of it being a TUI originally. (There is of course a package to for this functionality, but I found it would break frequently.)

> It’s easy to forget about it, and use such things like Treemacs, Customize, heck, even Org Mode, thinking that you’re interacting with UI elements (file nodes in Treemacs, text-boxes in Customize, Org Modes sub-trees and drawers). However, it is an illusion, though neatly crafted. It’s still text.

Org mode, in particular, is a real pain to script. It's a tree based workflow, but behind the scenes it is all text parsing. There's no "node" structure. When you compare it with Leo[1], the elisp to manage org mode nodes is horrible.

Nevertheless, I am not in favor of this post's primary thesis. The fact that you can attempt forward-sexp in a Magit buffer is a good thing. One of the joys with Emacs is utilizing commands from one Emacs package in another without either author intending it. I, for one, would be very upset if the Magit buffer disabled forward-sexp without a good reason.

[1] https://leo-editor.github.io/leo-editor/

A future for Emacs would be to separate out the underlying engine from the ui layer.

That way the TUI and a more GUI based Emacs could evolve separately without one being hamstrung by the other.

> You start your WM of choice1, you launch Emacs, and as long as the Emacs window is focused, you live in Emacs.

what if there is no WM?

I do most of my work on a cloud machine where i run emacs in screen, for example

I'm actually surprised you can't stage regions in magit, as it clearly seems to indicate that you can. Mark a section and it will ask about regions. Clearly, this hasn't come up that often for me, or I may have already known this. (More likely, if it came up often, someone would have made it work. :D )

I do think regarding things as "text" goes a long way to underestimating what can be done with it. As easy to think of it as serialized symbols, where the symbols can have specific meaning. At this point, the power seems a bit more manifest. If you are lucky (and someone else has put in the work), then you can use familiar "textual" symbol manipulations and that will keep meaning in the other domain that is being represented.

Among the array or reasons to hold tight to text: Emacs really doesn't care if there is a desktop or not. If one wanders headless in the clouds over SSH, the same configuration works fine; lasts a long time. "Pixels to those that require them", say I.

One problem with "leave windowing yo your window manager" is now when I automate workflows by scripting that window manager and no longer enjoy emacs extensibility benefits.

Perhaps the author could say something about how his suggestion would improve usability and me getting my work done better. AFAICS all he's saying is he wants it to be prettier.

Many have tried to have a GUI in emacs, but it is always doomed to fail. In Emacs, the tyranny of the text buffer is real. There is just not much you can do to escape it.

It is surprising how after all these years, Emacs still doesn't have the all the GUI capabilities as Zmacs, or Interlisp Executive/SEdit.

You boomers who are screaming that Emacs doesn't need a GUI layer perhaps need to wake up. It's 2023 and we're constantly dealing with an enormous amount of data. The data that's begging to be visualized. Lisp (especially Clojure) is one of the best tools to deal with data. You can slice it, dice it, chunk it up, measure it, convert it, analyze it, etc. Having a composable, extensible graphics layer in Emacs is only the natural next step in its evolution. When it finally gets added, you will happily be using its awesome features while shaking your heads, remembering that at some point you were against them.

What is the current state of using emacs within VSCode? Is it just keybindings or is there something more like what vscode-neovim has?

I was looking for something along this line a while ago. Closest I saw was SVG support in emacs, but for whatever reason, I couldn't get it to work, and it really wouldn't have been adequate anyway.

For those questioning the judgement of having a GUI toolkit in emacs, the answer is simply that the role and scope of emacs has long left behind being a mere text editor. For folks who like the "Lisp Machine that is emacs" I'm surprised the idea of having a modern GUI capability is so looked down upon. I think lots of folks would like a portable lisp machine with a "real" GUI. I mean, if it doesn't impact the closed loop coding and editing experience that folks are used to, what's the harm?

I had some personal projects that I would have liked to, perhaps, do in Lisp. But a requirement was that it be cross platform. I wanted to share my applications with others, and cross platform is a requirement.

And I'm lazy, I do not want to "mess with it", I want it to "just work".

I considered Pharo, but (when I looked), their raw drawing model was still very, very primitive. It was nowhere near what the Browser Canvas model or Java2d is like with their transformations and clipping and paths and what not. The Pharo model was little more than global coordinate line drawing. Plus, they keep redoing their widget toolset. GUIs are really not Pharos drive. Just enough to do another browser is their drive.

Flutter wasn't ready for the desktop yet, friend of mine is a big fan of Flutter right now. But, boy, are (were) Flutter builds slow. You're supposed to be able to a bunch of hot reloading, but that only goes so far.

The Electron style solutions just seemed overwhelming with the scope of browser frameworks (I'm not a front end dev, and I do find the front end world utterly overwhelming). Plus it's huge, the dev turnaround seemed slow when building your project, etc. Serious consideration, people have great success with it, but I chose not to.

I went with JavaFX as I'm a Java person already. Release sizes on par with Electron style apps, but my Clean/Build dev turn arounds are < 10s. I've tested it across Mac/Ubuntu/Windows, and it all seems to work. (JavaFX does not support Wayland, so I don't know what the real impact of that is.)

I did not consider Clojure, but did look at potentially using ABCL, but I honestly just didn't want to have to redo the bindings for everything from CL to JavaFX (and back). It would have been a hybrid model, and likely "the worst of both worlds". Maybe that's not true, that was just my sense.

And there's really no other decent Lispy -> cross platform GUI solution. I'm sure it could be done, but just a lot of work. I like Lisp, but I like getting stuff done more.

So, if eMacs had a rendering model and a decent GUI toolset, I could very well given it serious consideration for my dabblings and madness.

if kept sensible[0], this could lead to great many talks and projects

[0] be sure to review lisp culture of homoiconicity, so not to add too many layers, a bit like M-x customize.. but be a bit crazy too :)

I really like this blogs ui! I think it was made with hugo.

i wish so badly that ccl was ported to ARM mac so that you could build GUI programs with the cocoa interface on a newer machine

Unpopular take; let's move beyond this and ditch Emacs - invest in newer things (glad I can only get downvoted to -4, which I fully expect with this comment).

NYET, EMACS IS FINE.