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.
Emacs GUI Library
71–80 of 103 posts
Re: Emacs GUI Library
#72Earlier quoted context omitted.
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 w…
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.
Re: Emacs GUI Library
#73I 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…
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.
Re: Emacs GUI Library
#74Earlier quoted context omitted.
Since its a emacs guy its probably a self baked org/(e)lisp software capable of exporting posts in formats most people never heard of.
Sadly, it seems it is just hugo. He mentions hugo in a post[1]. [1]: https://andreyor.st/posts/2020-06-05-managing-background-pro...
He definitely is using Emacs for most of it. He authors his posts in org files, and uses ox-hugo to export to Hugo.
I do something similar for my blog, except Pelican is my backend.
https://andreyor.st/posts/2022-10-16-my-blogging-setup-with-...
Re: Emacs GUI Library
#75if 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 :)
Re: Emacs GUI Library
#76> 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.
Re: Emacs GUI Library
#77Earlier quoted context omitted.
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 w…
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.
Re: Emacs GUI Library
#78> 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 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.
Re: Emacs GUI Library
#79> 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
Re: Emacs GUI Library
#80Earlier quoted context omitted.
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.