which parts of emacs are old exactly?

I have heard many people complain about the ui layer being old and hacky, as well as some bits of the c core. I am not knowledgeable enough to know why this is though. Would emacs benefit from an agressive refactoring of its code a la neovim?

The Emacs UI layer, called “redisplay” in the code, is a highly–refined system for minimizing the number of bytes that need to be written to the terminal in order to update the display after every keystroke. 40 years ago when every baud mattered it was extremely impressive; these days you would probably never notice. Would Emacs benefit from removing that code? Not really. The Emacs GUI is more complicated. There are a number of different implementations. There’s one for Windows and at least one for Macs (one for Cocoa and one for Carbon, I believe), plus an implementation using Gtk widgets for modern Linux computers, and several using older toolkits such as Athena and Motif for older Linux and Unix computers. Which of those would you remove, and what would the benefit be?

There are some rather odd limitations like the background of all windows and buffers must be the same for example. I think thats where the age etc kinda shows but apart from these smaller issues its just fine.

This discussion was brought up just last week regarding the interaction between redisplay and the "GUI": https://paste.debian.net/1250782/ tl;dr: the emacs gui is basically a terminal, which is the worst way to build a gui. The author details how he improved the visual performance of this monstrosity, and some of the challenges inherent in this design.

For more on redisplay, see the link in [my other comment](https://www.reddit.com/r/emacs/comments/x0foln/which_parts_of_emacs_are_old_exactly/im81s08?utm_medium=android_app&utm_source=share&context=3). One of the other problems people have had with the C core is that it's not really extensible in lisp because it's, well, C. Ideally the whole program would be a neat little lisp interpreter that bootstraps itself, or compiles to machine code with `native-comp`. At present there's kind of a hard line between malleable extension code that can be freely refactored, and legacy implementation code that can't be changed without breaking a lot of what sits on top of it. Attempts have been made to port emacs to a core written in Guile or CL, but such attempts have proven futile. I do have high hopes for neovim going forward, and I have no doubt that in 15 years it will fully surpass emacs in every way. But for now, emacs has a much deeper ecosystem of extensions, and those extensions can change the editor on a much deeper level than neovim's can.

> I do have high hopes for neovim going forward, and I have no doubt that in 15 years it will fully surpass emacs in every way. What do you mean? Neovim is never going to be able to rid itself of its Vim core which is way larger than the C core of Emacs, so this passage does not really agree with the rest of your comment.

Does neovim still use vim's weird scripting language ? One major advantage, imho, emacs has over vim is that it is configured with a real programming language

They make a shift to Lua, although Vimscript is fully supported up to version 9, I believe

Here's a more readable version of the text at that link, pasted as comments in an r/emacs thread discussion about it at the time: https://www.reddit.com/r/programming/comments/5o846i/comment/dchct7h/ (The original was posted on Facebook.)

first one is perhaps readable in Org-mode!

> Ideally the whole program would be a neat little lisp interpreter that bootstraps itself Which Emacs is. > t's not really extensible in lisp because it's, well, C There are always some implementation details in an interpreter or compiler not exposed to client code. That is the nature of software, and is not something characteristic for just Emacs. There are parts of SBCL , CCL and other Lisp compilers and interpretters that are not exposed to the Lisp environment, and has to be changed by modifying the compiler or interpretter themselves. Why do you think there are different "releases" and "versions" of say SBCL, ECL or you name which Lisp compiler there is? Emacs is not different. Emacs C core appears to be bigger than some other Lisp implementations, but that is partly due to Emacs not having a compiler (in sense of machine code compiler), so many Lisp functions are implemented for the speed in C, but you can re-write them and re-install them in Lisp if you prefer. Anything exposed to Lisp is re-definable to say so. Even such core Lisp parts like car, cdr, map, if etc. > At present there's kind of a hard line between malleable extension code that can be freely refactored, and legacy implementation code that can't be changed without breaking a lot of what sits on top of it. Not to be rude, but can you explain a bit more? What exactly do you mean with that? Do you mean API? Emacs is a 40 years old application. Of course, you can't just go back and change the existing API to left and right. However, nothing prevents changes under the hood as long as the API is kept the same. That is nothing inherent to Emacs, it is the same with any library or middleware used by third party code if you wish to keep the API backwards compatible, which Emacs does.

Did someone ever tried to make emacs event driven instead of read eval loop?

> the emacs gui is basically a terminal, which is the worst way to build a gui Gives us reason why is it "the worst way"? The Emacs models a character-based text renderer, based on characters placed in columns and rows. The same rendering model is implemented by terminals, but I wouldn't say that Emacs GUI is a terminal. There is more to Emacs GUI than just its text renderer. There is nothing bad in controlling the renderer yourself. Gtk gives you the option to run your own event loop and do your own painting. Also, in general, nothing says that you have to really do drawing in WM_PAINT. Various applications may do rendering based on different needs. As an illustration, you could batch your paint calls if they are too frequent, maybe optimize them and then render the final result, especially if you render to a texture or something similar. Emacs works on many systems, graphical and non-graphical, and a REPL is somewhat similar to a game loop. In my opinion, it makes sense to abstract the low-level drawing to a window and do it yourself in Emacs case. > The author details how he improved the visual performance of this monstrosity, and some of the challenges inherent in this design. Indeed, Daniel rants about Emacs way to control the rendering surface, in a humorous way, but *the monstrosity*, as you call it, is there for a reason. Emacs runs on many different platforms, some of which do not have double buffering, some of which might be over the network. Local applications such as beloved Notepad can do everything *immediately* in WM_PAINT since they run locally *and* implement an immediate visual response to user actions. But you certainly don't wish to send over the network lots of immediate rendering steps, just to be discarded before the user even can see them. Also, in Emacs, text can be programmatically changed, and many of the user actions are a combination of different changes some of which *might appear* as if the user made input (for example if you run a macro). You certainly wouldn't like to see all the immediate steps of some script, cursor jumping between different windows and what not when executing something like this: ( ... ) (select-window other) (previous-buffer) (select-window current) ( ... ) Instead, Emacs displays only the final rendering result. Different applications have different rendering needs. Emacs is quite complex and advanced application, I think it should be seen in its own light, not how other applications do stuff.

> “redisplay” in the code, is a highly–refined system for minimizing the number of bytes that need to be written to the terminal No, it's a highly-refined system for minimizing the amount of stuff redrawn on the glass. And that can never become old or obsolete. Moreover, as displays become more and more high-definition, you need to move more and more pixels on the screen for the same stuff. Thus, the importance of redrawing as little as possible will never disappear.

> tl;dr: the emacs gui is basically a terminal, which is the worst way to build a gui. Nothing is farther from the truth. Don't believe everything you read in blogs. They are frequently written by people who have an agenda. The agenda could very well be important and useful one, but not every argument in its favor is necessarily true, especially if interpreted too literally.

Nothing? While it's not emacs's fault that it started as terminal program, its keyboard eval loop continues to explicitly call redisplay like a curses application, whereas every other gui out there repaints off X events, usually in a separate UI thread. It's ironic that you of all people should warn against those with an agenda.

In principle that is correct, but in practice a modern computer can redraw the whole screen thousands of times per second if you let it. It’s just not all that important any more.

> Moreover, as displays become more and more high-definition, you need to move more and more pixels on the screen for the same stuff. This only matters if the pixels are being drawn in main memory by CPU. Modern applications that leverage GPU and modern graphics APIs for rendering content don't really care how pixel-dense the screen they're being displayed on is. A modern application running on both HiDPI screen and HD screen takes equal CPU time to render each frame.

The way modern computers are capable of redrawing at high frequency is by doing exactly what Emacs is doing: by minimizing the amount of pixels that need to be redrawn.

That Emacs is single-threaded is one thing, and there's no argument about that. It has a single main loop that handles both input (not just keyboard input, btw) and redisplay. But that's because it's single-threaded, not because it's "terminal", whatever that means. (I leave the irony considerations to the eyes of the beholder.)

I don't see how what you say is relevant. The issue was whether it makes sense nowadays to redraw as little as possible. And that is true no matter how you redraw. GPUs are not there to let us waste resources; the code which runs in the GPU does the same optimizations. Why? because it simply makes sense not to redraw stuff that didn't change.

Your fixating on my ancillary remark about a separate thread doesn't absolve you of your earlier hyperbole.

Sufficient yes. "Highly refined" no. At some point I'd like to run the experiment of just how much the xdisp.c "try_" optimizations help. Regardless, they could all be rewritten to a fraction of their current length.

No, I mean you can easily write a program that updates a screen full of text at 10,000 fps. Use as many fonts to show as many scripts as you want. Emoji is no problem, stack up as much Zalgo are you care to write, and update every single character cell on every single one of those frames. You do not need to minimize the number of pixels that are drawn each frame.

No, GPUs do not try to keep track of which pixels stayed the same between frames, because they have to work for games where every pixel changes every frame.

The GPU stores data in buffers and process those buffers the same way on every frame. The cost of doing this is so insignificant that it's barely worth considering. The expensive bit is altering those buffers, since the CPU/GPU bus is quite slow. This is certainly worth optimizing for, although a UI only needs to move a fraction of the data that your average game loop does. Considering what needs to be redrawn is just not a thing though. I suspect you would only lower performance if you tried. Those things are literally made to slap pixels on a screen at a steady rate. Best you can do is to not get in their way.

This post was wonderful. Its exactly what programming is like. Anyone who thinks the OP of the redisplay stuff was being mean about emacs or the design choices is crazy. He's amazed at the mess still running after 30 years and liked it so much he contributed to maybe improving it.

I thought it was version 8 and vimscript 9 was when vim broke compatibility