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.)

Yeah, it's true. And Emacs would be a very poor substrate for this.

> (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.

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.

https://pharo.org/ ?

Is there a modern smalltalk that focuses on building TUI?

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.

> The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs

Not only the uniformity in use, but also the uniformity in how you extend would be lost.

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.)

XEmacs 24 on SunOS 5 was cool: code, web, mail, data all-in-one!

Pixel Fold & Tablet 5G + living in Emacs on Android at the cafe, beach and golf resort is totally do-able ;)

https://www.reddit.com/r/emacs/comments/ugxfi2/fyi_i_install...

>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.

> 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)

> 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.

Limited by emacs or by developer time?

XEmacs was what made me actually enjoy Emacs back in the day.

And ideas like this (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.