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.
Emacs GUI Library
81–90 of 103 posts
Re: Emacs GUI Library
#82Earlier quoted context omitted.
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.
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.)
> (Anything that removes terminal support from emacs will be a fork.)
GNU/Emacs already has tons of features that don't work in terminal and it's not a fork. GUI has:
- better fonts and better colors
- childframe support, nice for posframes
- viewing images and pdfs
- SVG support
- icons and emojis
- etc.
Re: Emacs GUI Library
#83I 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 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".
Have you looked at racket/gui?
Re: Emacs GUI Library
#84> 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 par…
> 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 amazingl…
> 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.
Re: Emacs GUI Library
#85You 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.
Re: Emacs GUI Library
#86i 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
Re: Emacs GUI Library
#87> 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 par…
It's ironic how org mode is the tool of choice for computer geeks, yet the code quality is so poor
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.
Re: Emacs GUI Library
#88> 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.
Re: Emacs GUI Library
#89So, 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…
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:
(def-frame
(vertical-split (
(horizontal-split (
(scrollview (tree-list))
(scrollview (editor-buffer)))
(mode-line)
(minibuffer))))
Re: Emacs GUI Library
#90Earlier quoted context omitted.
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.)