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.
In a way Lisp and S-Expressions would are tailor-made to define an abstract UI structure like JSX, SwiftUI and such, which then gets rendered into concrete UI widgets or a TUI. Something like defining a common editor layout this:
> 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.
I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose.
> I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose.
In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly.
> 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 [...]
It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.
feels like the right thing here is for the library present a declarative API ("i need these pieces of info of this kind") and then have separate GUI and TUI backends, with the ability to override the rendering options for either
but, yeah, that kind of thing always sounds great in theory, but is always ridiculously hard to get right in practice
Just tried the install given in the above blog and the resulting emacs wouldn't take any input. All of it was read by the Terminal where I started emacs-mac.
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.
I have long wanted something that was basically a modern~ish Smalltalk environment, that spends more energy integrating with the rest of the world. Emacs is as close as we can get to a system that is inspectable, plastic, and open; I want those qualities in my entire computing environment, and there is literally nothing available for any price better than Emacs at this, but Emacs isn't good at it.
I believe the web currently possesses the capabilities to make a networked Emacs/Smalltalk style system, souped up with AI, targeting web applications that don't require downloads; I've been pursuing such a system for a while and hope to have a prototype soon. There isn't really anything like this - Emacs is stuck in Unix-land, Replit is tied to React/Next.js (blegh), and Urbit sees obscurity as a virtue.
Then go ahead and build it. All I'm saying is that A) that's a fork of emacs I won't be remotely interested in and B) I highly doubt starting with emacs will be good way to achieve it (but go ahead and try by all means).
(Anything that removes terminal support from emacs will be a fork.)
When did VS Code get the same level of user discoverability, customizability, and interactivity as Emacs? I took a look at it a few years ago and it didn’t have anything remotely close to what Emacs offers while working considerably worse out of the box for development than Doom. Is it worth taking another look?
Discoverability and interactivity are debatable, but customizability is still not VSCode's forte. It's easy to knock up some quick elisp to scratch an itch in Emacs, whereas just printing Hello World in VSCode requires a bunch of scaffolding as an extension.
Some customizing being easier, doesn't mean it's overall more customizable. Both have a different focus in customizing, and different areas where it's easy or hard.
What is the benefit of drawing the interface for `M-x customize-group` as if it was plain text in the terminal when running the Emacs GUI?
It makes sense for `emacs -nw` and I don't think there’s many Emacs users who are advocating for ditching terminal support. But it looks like a hack in the GUI.
The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs. I can use all of my usual navigation keys to move around the documentation of the variable, evaluate things inline, etc.. Just as if it were more text, which is what Emacs is already great at. I would mind the buttons getting a more modern look, but I think everything being text what makes it works this seemlessly, and it would be much tougher to get a uniform feel with graphical windows.
There's no reason keyboard navigation can't work in a GUI context. In fact it might be easier to define things like "up" or "forward" since widgets will often have a natural hierarchy with direct references to each other, so there's no need to parse anything to figure out what the "sexp" is.
One problem is that macros currently work even in things like the settings buffer. If you change that to GUI, depending on the implementation, I'm not sure if that stays true.
For a settings buffer, maybe it doesn't matter. However macros working everywhere in your editor as a default is quite powerful.
I don't follow. Macros are literally just vectors of input events; if keyboard navigation works, then so will a macro that replays that navigation. (It is also already possible to record a macro that includes mouse events.)
>Ditching terminal support and replacing emacs TUIs with GUIs would not be progress
Graphical debuggers are one of the most important tools developers have gotten in the last few decades compared to the TUI and command line era. There exist packages like dap-mode for emacs which do an admirable job in simulating more graphical workflows, but they are limited by the capacities that Emacs has.
If you want to put Emacs on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system.
> There exist packages like dap-mode for emacs which do an admirable job in simulating more graphical workflows, but they are limited by the capacities that Emacs has.
> If you want to put Emacs on the same footing with modern IDEs I don't think you get around to at some point getting it to a modern GUI system.
Maybe I'm in the minority on this, but I'm not interested in emacs being on the same footing with modern IDEs. I'm happy with what it is, and would be sad if it didn't exist as it does today. (I only ever use emacs without -nw by accident)
And ideas like these (there are tons amongst longer emacs users) is part of the reason of why I left emacs after 8 years of running my own config. I just can't stand the reasoning "No no don't change things I like how they are, cowebs and all". There are lots of places emacs should improve to became a better modern editor, not necessarily to attract more people but to make the life of those who use it better.
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
There have been tiling window managers based around Emacs before. I think the most recent I tried was https://github.com/ch11ng/exwm -- in this case the window manager is itself emacs, and your windows are buffers in emacs etc.
It makes a lot of sense, since Emacs does its own tiling, and one is usually familiar with the keystrokes already, and then you don't have tiling in tiling.
So I keep meaning to go back and try this again, or something similar, but I recall it having issues with a lot of my commonly used applications back when I tried it.
When I get in the tiling mood, I use regolith, which is a nice packaging up of i3 in with the gnome environment. I'd love to have something like that, but built around emacs.
(The crazy thing is I'd probably end up editing source code in CLion inside that... since the CLion Rust plugin is superior to anything I can get in emacs)
> 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
What are the top 3 or 5 things or so you think a NeoEmacs should solve/improve?
Iam pretty sure emacs was capable of rendering any images (invluding svgs) more than a dekade ago. I remember because I was really excited as I realized.
> I'd love to see a NeoEmacs that addresses some of these issues
I believe the Nyxt browser project is eventually looking to add editing support. If they manage to do that robustly it might be just what you’re looking for.
to be fair, I've been using emacs since 1992, and from about 1994 on-wards almost all of that usage was in an X windows session, unless I was doing something remote
> 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.
> > 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.
Indeed, of the ~7 machines I work on regularly, 5 of them are via ssh and need no GUI. `emacs -nw` is so much quicker and efficient than having to deal with an X server (or equivalent). And the GUI provides me with really no benefit.
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.)
I think it's misguided to think of Emacs having moved away from the TUI paradigm at all. I have lived in Emacs for two years and have never even considered scrolling with my mouse. My hand never touches the mouse.
As I move through the document, I already have the location of the cursor origin saved in a register and can jump there, or any of several other locations with a single keypress.
I've always considered the mouse & menu system to be an emergency backup for beginners who have hit a wall. They will probably never be first class citizens.
Thanks for sharing your view. I definitely prefer a GUI editor, I’m currently using Sublime.
I was attracted to emacs because I like writing lisp and I hoped that the high level of customizability would let me smooth over any rough edges. But even though Sublime is not very flexile at all, it’s closer to what I want than I was able to script emacs to be.
Implying a dichotomy between TUI and mouse scrolling is very strange to me. I use my mouse to scroll in TUIs, including emacs, all the time. Emacs has full mouse support and scarcely discourages it's use.
> I've always considered the mouse & menu system to be an emergency backup for beginners who have hit a wall. They will probably never be first class citizens.
Perhaps, but ideally you'd want your on-ramp experience (or your gateway experience) to be smooth, rather than a full cold-turkey.
I'll split the window and then open up the same buffer in the other window. Now I have a separate window that I can scroll (using alt-pgup with alt-pgdn) while keeping my cursor and editing state right where I want it in the original window.
This is a fun one, all told. The Mac way of leaving the cursor at the top of a document is infuriating to me. Why would I want the cursor to be off of the visible screen?
Point being that I suspect this is very much a learned behavior and you can grow to like either way. Not that one is superior to the other.
> 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.
As someone immersed in the emacs project for the last several years,
I can say with some authority the org enthusiasts are by and large
non-programmers by trade. I can also say the earlier half of org code is
quite good, but the latter half is quite bad, a direct reflection of
the deterioration in personnel quality.
> behind the scenes it is all text parsing. There's no "node" structure.
But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools.
Rather than being forced to think in "org" and manipulate its "objects", you just manipulate text, and if you happen to shape that text into something org recognizes, then it knows how to work with it.
This is amazingly inviting because you never feel "stuck" like you converted something to the wrong type of thing and now can't get it back, or whatever. Instead if you make a mistake you just.. change it to what it should be. It feels very fluid and you learn it quickly because you're not presented with trying to fit your thoughts into someone else's abstractions. You just write what you want and progressively learn more and more how to naturally shape your work into something that org can help you with.
> But I feel like this is one of the strongest things about org mode and something that keeps it really apart from similar tools.
Having manipulated nodes in both Leo and Org mode, the former is one to two orders of magnitude easier (no exaggeration!), and I did not find anything lacking in it compared to text parsing org nodes in elisp.
I'm not arguing that text parsing should not work, or not be available. But there really should be a solid, robust API to do simple things like:
1. Move a node from one place to another.
2. Get the body of the node (sans any children, drawers, and other metadata).
3. Traverse nodes in whatever order you want (DFS, BFS, random, etc).
The underlying implementations of these functions can handle the text parsing. I shouldn't have to do it every time.
Elsewhere, the author makes the point that with TRAMP, your local (gui) Emacs can transparently operate your remote machines (bringing with it of course all the customizations and functionality you've built into your local config--and of course your local window management).
I've known this was possible for many years; but on a lark, I just wrote a microfunction that opens, in my local Emacs, a remote file I often have to edit as root. I don't live in Emacs, but there's no denying that, if I'm already in Emacs and I need to edit this file, I just saved myself a small amount of faffing about; I've also added my local init as a site for future automations.
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.
You certainly can stage regions. The author is complaining of a bug - not one I've seen and possibly some sort of interaction with another package he's using. Magit's author is awesome so maybe worth raising a github issue... and donating!
Yeah, it works at the line level (as indicated by the way it highlights the selected lines) which I think is a limitation as much of git itself as magit. (I'm not sure what subline staging would even do.)
But the author isn't trying to stage a region, let alone a subline one. He's trying to stage a whole hunk and says its only working if point is at the start of the line.
Makes sense. I definitely took the complaint to mean that it only works at the line level. Probably because that was the only way I could see the behavior not working?
Subline staging makes sense for some changes. In that, if it does subline indications of what changed, I would expect I could accept one of the changes, but not the others. That said, I agree it is likely a limitation of git, as much as of magit. And, again, I can't imagine this comes up that often.
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.
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.
Emacs pretty clearly needs to be split into 3 layers.
Elisp
The editor - written in elisp
GUI/TUI - Also in elisp that call back to the editor functions.
Just out of curiosity, what would you expect the value-add to be in this? From my perspective, if you're using emacs, it's value comes from being the 'top layer' that ties together all the functions and coordinates between the things you need.
This is a genuine question coming from a place of relative ignorance, mind you. I haven't touched VSCode since the dark ages so I don't really know what it adds to the experience.
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.
> 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 have heard of it, but did not look into it. As I understand it's rather big (deployment, memory), yet limited (in terms of the widget set). In fact, I hear a lot of hot and cold with Racket, and have for some time. Enough to be off-putting for me, so, no I did not consider it.
Being an Emacs guy, I can recommend weblorg - I guess most people haven't heard about org-mode indeed, but it's one of the biggest reasons I stuck to Emacs, worth a look.
Got curious what this guy uses for the site, but couldn't find a public repo for it with a few minutes of digging. Mostly you couldn't really tell what static site generator someone uses unless it's one that supports themes, and they use one of the popular ones.
I have not tested it on modern Emacs, but it was fun to write. (It basically finds the largest size that each slide can be displayed in, and displays it at that size. And it of course syntax highlights code blocks with Emacs.)
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).
For better or for worse, Emacs is in a unique spot with package availability and with how easy it is to extend.
Do you have a good copyleft alternative that its maintainers can't just turn into closed source, or one that is fully open source and isn't injected with telemetry?
Emacs is also very old, rooted in antiquity, and has cruft that really needs to be jettisoned. What prevents us from creating copyleft alternatives to Emacs that are rooted in a modern paradigm?
What prevents us is probably the willingness to put in the hours and the coordination to do so. It is not easy to write an alternative that improves on it but is also capable of running Org and Magit which are two nontrivial packages that make people stick with Emacs.
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.