Personally, and contrary to the article, I do prefer Emacs's plain text widgets over more "GUI-like" ones. Plain text widgets minimize the differences between TUI and GUI Emacs and also inherently offer text selection, searching, copying, and pasting, which nicely integrates with Emacs. I mean, not many GUI frameworks let you place a cursor within a button and select its text, do they? I believe this is a unique advantage of text-based widgets: while other GUI applications require a dedicated mechanism for searching through their settings, text-based widgets allow you to use any text-searching packages to perform these actions.
Reading through the article, the author seems to be hoping for a pure GUI approach with Emacs-like navigation mechanisms, but I am not convinced that this can be as flexible as text-based widgets. However, for packages used exclusively within a GUI environment (like el-easydraw [1], which relies quite heavily on SVG-based widgets), it would be nice to have a dedicated GUI widget library.
(There was a discussion on Reddit about this a week ago [2], and I saw some comments defending GTK and PGTK that might be worth reading.)
I agree and only use emacs in the console and love it. With the advent of lsp modes and real time typescript and linting it’s fantastic. But one thing I don’t like about the console is when LSP mode is giving you an in-line error on the right side of the terminal it’s wrapped and beautifully interspersed amongst your code, but it’s impossible to select multi line errors in order to paste into tools like ChatGPT. Since selecting the error, also selects your code on the left side.
This is what I was referring to when I talked about "rich verbs".
Many people feel that way. The idea here is not to tell you that you're wrong, but understand what you want and do it better on the GUI side. TUIs can do a lot and we should recognise their benefits. GUIs can do that too, and can sometimes do better things.
The text-based widgets done graphically do the trick. We can add stuff that can't be done in a TUI and see if they give you anything useful. If it can be done with text widgets means that it can be done in principle. GTK can't do it, and that's why I'm leaving it behind.
> (There was a discussion on Reddit about this a week ago [2], and I saw some comments defending GTK and PGTK that might be worth reading.)
The author of those comments abused their power on reddit. I will not get into the weeds, just say that I'd be happy to respond to the critique presented here in good faith.
There's also the Emacs Widget Library[1] (which I hoped this posted would be about). It's a plain text widget library that's quite powerful. Unfortunately (and surprisingly for Emacs), the documentation for it could use some love.
My understanding of the Widget Library is that it attaches various keywords and plists to a symbol which is considered the "widget". The library otherwise consists of functions that expect certain keywords on the "widget" symbol in order to perform actions or to be drawn on the screen.
The challenge is, the documentation doesn't clearly lay out what the keyword API is. This makes it hard to compose widgets in ways beyond what's shown in the docs.
The idea is that we extend that and give it direct access to SDL. Such that we can e.g. run a shader in the buffer background, or allow you to have floating windows (frames) interacting with each other.
I am very aware of the advantages conferred by TUI and I seek to expand those to the GUI; not dumb-down to the level of modern GUI toolkits (that to be fair are dealing with a completely different problem). Hopefully, this can lead to some ideas being easier to implement from within Emacs.
Personally, and contrary to the article, I do prefer Emacs's plain text widgets over more "GUI-like" ones. Plain text widgets minimize the differences between TUI and GUI Emacs and also inherently offer text selection, searching, copying, and pasting, which nicely integrates with Emacs. I mean, not many GUI frameworks let you place a cursor within a button and select its text, do they? I believe this is a unique advantage of text-based widgets: while other GUI applications require a dedicated mechanism for searching through their settings, text-based widgets allow you to use any text-searching packages to perform these actions.
Reading through the article, the author seems to be hoping for a pure GUI approach with Emacs-like navigation mechanisms, but I am not convinced that this can be as flexible as text-based widgets. However, for packages used exclusively within a GUI environment (like el-easydraw [1], which relies quite heavily on SVG-based widgets), it would be nice to have a dedicated GUI widget library.
(There was a discussion on Reddit about this a week ago [2], and I saw some comments defending GTK and PGTK that might be worth reading.)
[1] https://github.com/misohena/el-easydraw/
[2] https://www.reddit.com/r/emacs/comments/1kcgwme/the_emacs_wi...
I agree and only use emacs in the console and love it. With the advent of lsp modes and real time typescript and linting it’s fantastic. But one thing I don’t like about the console is when LSP mode is giving you an in-line error on the right side of the terminal it’s wrapped and beautifully interspersed amongst your code, but it’s impossible to select multi line errors in order to paste into tools like ChatGPT. Since selecting the error, also selects your code on the left side.
Anyone have a good solution to this ?
Author of the article.
This is what I was referring to when I talked about "rich verbs".
Many people feel that way. The idea here is not to tell you that you're wrong, but understand what you want and do it better on the GUI side. TUIs can do a lot and we should recognise their benefits. GUIs can do that too, and can sometimes do better things.
The text-based widgets done graphically do the trick. We can add stuff that can't be done in a TUI and see if they give you anything useful. If it can be done with text widgets means that it can be done in principle. GTK can't do it, and that's why I'm leaving it behind.
> (There was a discussion on Reddit about this a week ago [2], and I saw some comments defending GTK and PGTK that might be worth reading.)
The author of those comments abused their power on reddit. I will not get into the weeds, just say that I'd be happy to respond to the critique presented here in good faith.
Why did you delete the page?
There's also the Emacs Widget Library[1] (which I hoped this posted would be about). It's a plain text widget library that's quite powerful. Unfortunately (and surprisingly for Emacs), the documentation for it could use some love.
My understanding of the Widget Library is that it attaches various keywords and plists to a symbol which is considered the "widget". The library otherwise consists of functions that expect certain keywords on the "widget" symbol in order to perform actions or to be drawn on the screen.
The challenge is, the documentation doesn't clearly lay out what the keyword API is. This makes it hard to compose widgets in ways beyond what's shown in the docs.
[1] https://www.gnu.org/software/emacs/manual/html_mono/widget.h...
The idea is that we extend that and give it direct access to SDL. Such that we can e.g. run a shader in the buffer background, or allow you to have floating windows (frames) interacting with each other.
I am very aware of the advantages conferred by TUI and I seek to expand those to the GUI; not dumb-down to the level of modern GUI toolkits (that to be fair are dealing with a completely different problem). Hopefully, this can lead to some ideas being easier to implement from within Emacs.
Somewhat off topic, but I love all the references to Led Zeppelin’s incredible song, Stairway to Heaven.
404
Page Not Found
Sorry, this page does not exist.
You can head back to the homepage.
Hi. I just migrated my blog to Hugo yesterday. The correct link is:
https://appetrosyan.github.io/posts/emacs-widget/
PSA: Use The Lucid Toolkit https://irreal.org/blog/?p=12672
https://old.reddit.com/r/emacs/comments/1hlj04t/emacs_using_...
That's the best thing to do for the moment.