Related to the topic of "Emacs is a terminal program with lots of clever hacks to run in a GUI", I recently encountered a big problem on macOS 10.12 "Sierra", which I found reported at [1]
The crux of it is that macOS became more strict about what you were doing in GUI- vs non-GUI-threads, and now asserts if you fetch GUI events (I think?) in not the main thread, because of the risk of memory corruption. Ostensibly.
This bug only manifests if you compile Emacs on 10.12 (so if you install the "emacs-app" in MacPorts, for example), because then it'll link against the asserting framework. If you use Emacs from another source that compiles it on 10.11 (such as from https://emacsformacosx.com/), then it links against an older framework that doesn't have the assert, and it'll work "fine".
Considering the fractal accumulation of "clever hacks" that make Emacs work on modern GUI systems, I'm curious to see how this issue will be resolved, because I doubt it's something so simple where Emacs has proper separation of GUI vs non-GUI threads, as QED by the article ;)
This issue is aleady solved in Yamamoto Mitsuharu's Emacs OSX port (https://bitbucket.org/mituharu/emacs-mac) which if you use Emacs on OSX is what you should be running (rather than the "official" OSX branch).
The OSX support in the mainline Emacs repo (which emacsformacosx.com and aquamacs use) is a third class citizen, since very few people work on it and Stallman is always quick to remind the rest that Linux (sorry GNU/Linux) remains the priority rather than those pesky non-free OSes.
The end result is that the official OSX Emacs is perpetually buggy (check emacs-devel, it breaks all the time) and lacks a lot of useful features that are available through new OSX APIs. To make matters worse, Stallman has demanded that _useful features be removed_ from the OSX branch, because _Linux doesn't have equivalent APIs_. It was disappointing to see them following through with these removals.
On the other hand, the Yamamoto Mitsuharu port is rock-solid, functionality is not removed cause Stallman said so, is actively worked on (Yamamoto was the old Carbon Emacs maintainer and knows what he's doing) and uses the latest OSX APIs. It has had flicker-free double-buffering for years, smooth (pixel-based) scrolling with inertia, integrated AppleScript bridge, integrated Apple event support, HiDPI, ligatures, graphics/SVG/animations through ImageKit, proper C-g handling, dictionary service support, proper fullscreen, and I could go on and on and on [1] ..
TL;DR
If you're using Emacs on OSX, you should be running Yamamoto's port.
That's a good bug report. I haven't run Emacs on OS X (err, macOS) in ages, but I may have to start doing that once in a while soon. It's important to fix bugs like this. It's always possible to launder events between threads internally --- the w32 port of Emacs does something similar internally.
What are some good resources to learn more about the inner workings of text editors or building one from scratch? So far I've found and enjoyed reading/watching the resources below and would love to learn more.
One of the best docs describing how to write an editor I've ever read was the old documentation for the lcc-win32 compiler. It touches on the practical aspects of developing an editor (and the pipelining compiler as well.) Some understanding on how the Windows API works might be of value for the editor part, but the compiler part should be understandable to anyone:
(I won't go into jus how hard it was to find this version of the docs and extract the file on a non-Windows computer. Luckily I just did that a few months ago for unrelated reasons!)
I've found that reading the source code (or at least the general structure) of kakoune[1] really helped me understand editors. I think it's a very high quality c++ codebase for a relatively complex editor.
James Gosling published "A Redisplay Algorithm" [1] in Proceedings of the 1981 ACM SIGPLAN SIGOA symposium on Text manipulation, describing the Emacs redisplay algorithm (the code with the skull and crossbones [2] that Stallman rewrote [3]).
I really enjoyed typing along with this 3-part series: https://www.youtube.com/watch?v=oDv6DfQxhtQ
Per writes the beginnings of an emacs-inspired Windows (directwrite) text editor.
I want to continue developing it, but have no idea what to do regarding design... I'm considering using Sublime's themes.
Windowing systems and GUI modules and so on and so on, all give us powerful capabilities but also come with their own conceptual frameworks that need to be understood and plugged into each other. If both the module designers and the engineer of the larger system are working from roughly the same mindset, this is routine work. But if the former and the latter worked on entirely different machines, trained by computer science in wildly different stages of its development, I'm sure things can get much more "fun."
Intergenerational software development will someday be its own sub-discipline, with professors and specialized techniques and everything.
On the flip side, it's pretty cool what Emacs can still do on a text terminal. Multiple windows, mouse, auto completion pop-ups--all work comfortably over an SSH session.
"Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit.
It’s a fractal of delusion."
There a discussion on the mailing list about pulling GTK support out into its own front end (like mswin or ns) that never uses X directly. This would allow simplifying the X front-end, and also running graphical emacs on a pure Wayland system.
I wonder if something analogous this hack would be required in the new GTK front-end.
Article author here. Check the emacs-devel thread: some people were able to repro the flickering and some couldn't. It appears to depend heavily on details of your machine.
I have two X1 Carbon 4th Gen machines, one running Goobuntu (basically Ubuntu 14.04 with a new kernel) and one running Ubuntu 16.10. They both flicker, but differently.
Same question I was about to ask. I use emacs on Ubuntu every day and I don't remember it flickering. I wouldn't use it if it were. Well, maybe I'll look for another OS.
I do experience flickering, on both a desktop Fedora 22 system and a X1 carbon 4th gen system running OpenBSD 6.0. It is usually mostly noticeable in the fringe area as well as along the divider when splitting windows. Kuddos for OP, the patch does not seem trivial and it is a most welcome change.
I'm back on emacs after a couple of (fun) months with vim, and one of the things I miss is smooth scrolling in terminal. Enabling mouse in vim is enough for the scrolling to work pretty great in iterm2, while in emacs (also in iterm2) even after numerous hacks and trial and error I'm still not happy with the result.
If I remember correctly this was actually one of the main differences with the XEmacs fork.
Some of the features are already fuzzy on my mind, but I think one reason I used to use it instead of the original Emacs was the improved GUI experience.
Can we get this in 25.1.2 or in a branch/commit on top of 25.1 for those of use who don't want to track trunk's development, given how long the reschedule schedule is? The patch from the list didn't the apply cleanly, but I haven't tried to merge it in a git repo (yet).
The C side of Emacs is pretty bad, and his description makes it sound worse, but honestly I've never seen Emacs flicker or draw white boxes at any time in my life.
I always wondered why Emacs struggled to render certain visual elements as quickly as other editors (e.g. Sublime). For example, load in a relatively long line (not even ridiculously long), and it comes grinding to a halt, can't even edit text _near_ the long lines, if its in view! Same goes for linum mode being resource heavy. Why is this? I would have expected that a text editor built in the 70s should excel at rendering text quickly and efficiently?
Is the reason related to this blog post? Every time I tried to profile emacs it led me to the redisplay function, and from there i was lost..
Is there any hope that emacs will ever render code as quickly as modern 'native' apps (e.g sublime)??
[+] [-] AceJohnny2|9 years ago|reply
The crux of it is that macOS became more strict about what you were doing in GUI- vs non-GUI-threads, and now asserts if you fetch GUI events (I think?) in not the main thread, because of the risk of memory corruption. Ostensibly.
This bug only manifests if you compile Emacs on 10.12 (so if you install the "emacs-app" in MacPorts, for example), because then it'll link against the asserting framework. If you use Emacs from another source that compiles it on 10.11 (such as from https://emacsformacosx.com/), then it links against an older framework that doesn't have the assert, and it'll work "fine".
Considering the fractal accumulation of "clever hacks" that make Emacs work on modern GUI systems, I'm curious to see how this issue will be resolved, because I doubt it's something so simple where Emacs has proper separation of GUI vs non-GUI threads, as QED by the article ;)
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24678
[+] [-] armitron|9 years ago|reply
The OSX support in the mainline Emacs repo (which emacsformacosx.com and aquamacs use) is a third class citizen, since very few people work on it and Stallman is always quick to remind the rest that Linux (sorry GNU/Linux) remains the priority rather than those pesky non-free OSes. The end result is that the official OSX Emacs is perpetually buggy (check emacs-devel, it breaks all the time) and lacks a lot of useful features that are available through new OSX APIs. To make matters worse, Stallman has demanded that _useful features be removed_ from the OSX branch, because _Linux doesn't have equivalent APIs_. It was disappointing to see them following through with these removals.
On the other hand, the Yamamoto Mitsuharu port is rock-solid, functionality is not removed cause Stallman said so, is actively worked on (Yamamoto was the old Carbon Emacs maintainer and knows what he's doing) and uses the latest OSX APIs. It has had flicker-free double-buffering for years, smooth (pixel-based) scrolling with inertia, integrated AppleScript bridge, integrated Apple event support, HiDPI, ligatures, graphics/SVG/animations through ImageKit, proper C-g handling, dictionary service support, proper fullscreen, and I could go on and on and on [1] ..
TL;DR
If you're using Emacs on OSX, you should be running Yamamoto's port.
[1] https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403...
[+] [-] quotemstr|9 years ago|reply
[+] [-] bonquesha99|9 years ago|reply
* The Craft of Text Editing: https://www.finseth.com/craft/
* Writing a Text Editor From Scratch: https://www.twitch.tv/gary_bernhardt/v/90796516
* A Modern Text Editor Built in Rust: https://www.youtube.com/watch?v=SKtQgFBRUvQ
[+] [-] dguaraglia|9 years ago|reply
https://docs.google.com/document/d/1_S7gv6UGLAKuo9g1tNoNbU2O...
(I won't go into jus how hard it was to find this version of the docs and extract the file on a non-Windows computer. Luckily I just did that a few months ago for unrelated reasons!)
[+] [-] omtose|9 years ago|reply
[1] https://github.com/mawww/kakoune
[+] [-] DonHopkins|9 years ago|reply
[1] http://dl.acm.org/citation.cfm?id=806463
[2] http://donhopkins.com/home/archive/emacs/skull-and-crossbone...
[3] https://news.ycombinator.com/item?id=3427495
[+] [-] bluefox|9 years ago|reply
[+] [-] bootload|9 years ago|reply
always been partial to "A Tale Of Five Editors" ~ http://www.catb.org/esr/writings/taoup/html/ch13s02.html
[+] [-] swah|9 years ago|reply
I want to continue developing it, but have no idea what to do regarding design... I'm considering using Sublime's themes.
Another interesting tutorial: http://www.catch22.net/tuts/neatpad
[+] [-] maxander|9 years ago|reply
Intergenerational software development will someday be its own sub-discipline, with professors and specialized techniques and everything.
[+] [-] aboodman|9 years ago|reply
[+] [-] rayiner|9 years ago|reply
[+] [-] _pfxa|9 years ago|reply
[+] [-] dman|9 years ago|reply
[+] [-] ekr|9 years ago|reply
[+] [-] twsted|9 years ago|reply
[+] [-] marai2|9 years ago|reply
[+] [-] NoGravitas|9 years ago|reply
I wonder if something analogous this hack would be required in the new GTK front-end.
[+] [-] jabl|9 years ago|reply
Also, are the Xt and motif versions still maintained? Surely the user base of those must be pretty close to 0 these days?
[+] [-] jefurii|9 years ago|reply
[+] [-] quotemstr|9 years ago|reply
I have two X1 Carbon 4th Gen machines, one running Goobuntu (basically Ubuntu 14.04 with a new kernel) and one running Ubuntu 16.10. They both flicker, but differently.
[+] [-] dom0|9 years ago|reply
Edit: Hm, no there is no synchronization between the WM and emacs in any way. So this can't be it.
[+] [-] NoGravitas|9 years ago|reply
[+] [-] hollerith|9 years ago|reply
The flicker happens only with graphical Emacs (and then only on Linux IIUC).
[+] [-] p4bl0|9 years ago|reply
[+] [-] pmontra|9 years ago|reply
[+] [-] eeks|9 years ago|reply
[+] [-] hellofunk|9 years ago|reply
[+] [-] fit2rule|9 years ago|reply
But I must admit, this butter-smooth version of emacs sounds intriguing .. off to give it a try.
[+] [-] qwertyuiop924|9 years ago|reply
[+] [-] melling|9 years ago|reply
[+] [-] base698|9 years ago|reply
[+] [-] raindev|9 years ago|reply
[+] [-] smnscu|9 years ago|reply
[+] [-] hobo_mark|9 years ago|reply
[+] [-] shp0ngle|9 years ago|reply
For about 6 months.
[+] [-] ddp|9 years ago|reply
Here's the .configure you'll need: ./configure LDFLAGS=-L/usr/local/opt/libxml2/lib CPPFLAGS=-I/usr/local/opt/libxml2/include PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig
[+] [-] pjmlp|9 years ago|reply
Some of the features are already fuzzy on my mind, but I think one reason I used to use it instead of the original Emacs was the improved GUI experience.
Last time I have used it was around 10 years ago.
[+] [-] late2part|9 years ago|reply
[+] [-] rwmj|9 years ago|reply
[+] [-] cm3|9 years ago|reply
[+] [-] quotemstr|9 years ago|reply
"But I wants it!" is not a reason to backport fixes or issue new releases. You can always run from master for now.
[+] [-] harrygeez|9 years ago|reply
[+] [-] db48x|9 years ago|reply
[+] [-] kickingvegas|9 years ago|reply
[+] [-] kanbannoman|9 years ago|reply
Is the reason related to this blog post? Every time I tried to profile emacs it led me to the redisplay function, and from there i was lost..
Is there any hope that emacs will ever render code as quickly as modern 'native' apps (e.g sublime)??