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.
Edit: my comment below was uninformed, I see that Mituharu's port is up-do-date with Emacs 25, which is close enough to upstream for me.
Original:
Interesting! However, how closely does it follow upstream for... every other feature?
I'm using GNU Emacs because I've basically standardized my use of it across platforms. Gone are the days of XEmacs vs Emacs and all the small differences between them, and GNU Emacs' development pace has nicely picked up over the past 2-3 years since Stallman stepped down as maintainer.
I think johnw tried at some point but Yamamoto isn't very excited at the prospect, and who would really blame him?
Keeping his work out of the main branch gives him the freedom he needs to focus on technical matters and introduce support for new features as they're being exposed by OSX APIs.
As long as Stallman holds sway over Emacs and can demand that one cripple his own work for _political reasons_ , I don't see this situation changing. I'm just glad that Yamamoto did not fall for the "lowest common denominator" approach and has enough pride in his own work to do things as he sees fit.
GNU Emacs is a political project, rooted in the free software movement. Too often people like you insult Stallman and ask for an Emacs that is a bit better technically in exchange for removing the goals of the GNU proejct. There's plenty of other software to use that cares about technical matters only.
Even so, it would help if Homebrew reassigned the "emacs" package name to the Emacs fork by Yamamoto Mitsuharu.
(The way it is now, when you install with `brew install emacs`, you get FSF emacs; to get Mitsuharu Emacs, you have to know to say `brew install emacs-mac` instead.)
I saw later in the thread that you're Daniel. I enjoy your emacs-devel posts and your back&forths with Eli/Stefan. I liked (and was in full agreement with) your commentary during Emacs dynamic modules dev, and I also enjoyed your recent demand paging post.
It's just too bad that you seldom get things to go your way.
Mitsuharu is amazing and have to agree that if you’re on macOS you should definitely be using his port. He’s actually already added some support for the new MacBook Pro touch bar. I've been using his port directly off his "work" branch for a good 2 years or so now and it’s always been rock solid.
No. You should be using the official emacs-x, not emacs-app, not Aquamacs, not Carbon or emacs-mac.
I tried to work with them, but after a week I'll get terrible hand aches for their problematic keybindings.
The traditional x port flickers a bit, (dan just fixed it via xdbe, great!) but proper Ctrl-x, Command-x and just works as everywhere else. RMS politics are stupid, yes, but overall the official port is still the best.
Just to make sure everyone reading this can follow along: you are probably suggesting using Emacs on the X windowing system on OS X (which would of course require XQuartz to be running).
And by "problematic keybindings" you probably mean how most graphical Emacs packages on OS X use the Command modifier key to set the meta bit.
But Mitsuhara Emacs (or emacs-mac as you refer to it) lets you assign any "Emacs modifier bit" (control, meta, alt, hyper or super) to any of OS X's modifier keys (namely, control, option, command or fn) except for the shift key.
So for example if you're on a Macbook, but you are used to the key on the bottom left's being a control key, you would add (setq mac-function-modifier 'control) to your .emacs.
To use the option key as your meta key, (setq mac-option-modifier 'meta).
>The traditional x port flickers a bit
None of the other ports you mention have ever flickered in my experience. And running Emacs under X has the disadvantage that Emacs ends up looking quite different typographically than native OS X apps do.
I'm using an rMBP and the XQuartz treatment of text on there is literally painful -- simultaneously blurred and pixellated if that makes any sense. This isn't the hedonic treadmill effect with regards to the retina display as I have no problems using other systems with "standard" displays.
I agree that the latest XQuartz update forced me to try out the native emacs-app which had nicely looking fonts. But I couldn't store my selection of a good font, and the overall experience was awful. My hand still hurts.
With the latest XQuartz and emacs 25 only "Use System Font" looks good, before we had much more good fonts. Wonder what caused this regression.
This contradicts many years of my personal experience, and that of everyone I know. Yamamoto Mitsuharu's Emacs OSX port is by far better than mainline. And seriously, X on OSX? That's just insane.
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 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!)
Thanks, this is fascinating! This is the sort of thing that makes me think Vernor Vinge wasn't so far off when he described the concept of programmer archaeologists.
BTW, can you upload the original doc file somewhere? Google Docs appears to be mangling the formatting in a few places (page 28, for example).
For archaeology's sake (and to contrast with X-Windows), here are a couple design [1] and protocol [2] documents RMS wrote about window system design, circa 1985, before X10R2 was released in 1986, but after all his work on the CADR Lisp Machine window system. (Not to be confused with Genera!!! [3])
> CADR Lisp Machine window system. (Not to be confused with Genera!!!
Early Genera was based on the Lisp Machine window system. Later Symbolics introduced a new window system (Dynamic Windows), but the old one (TV, ...) was still provided.
I hadn't heard of Vernon Vinge before, but the concept resonates. There's so much lore and knowledge to be found in old software packages. When I was learning how to program, I randomly found this pseudo-BASIC compiler called ASIC, which was amazing for what it could do. It provided low-level functionality that normal QBASIC wouldn't give you. I remember spending a whole summer playing with that and a free tutorial on 3D programming called "3DICA" written by some Finish students. Good times.
Well, if you like science fiction, you should read some of his works. He is a mathematician and computer scientist who has written some fascinating science fiction. "A Fire Upon the Deep" is probably his best and most famous work. Imagine that in different parts of the universe people can have different intellectual abilities because of different physical laws. And we are living in the slow zone.
Thanks for the book recommendation! I'll add it to my queue, for when I finish Abaddon's Gate (The Expanse, BTW, is a pretty solid sci-fi series, although I think I'm ready to take a little break after three books in a row.)
Should have saved your allowance and bought the QuickBASIC compiler! I did and when I discovered that the textfile-reading program I wrote to handle huge files (at the time) would buffer keystrokes, fill the buffer, and beep annoyingly if I held down the 'Down' arrow or 'Page Down' keys, I was led into learning x86 assembler. Well, enough that I could use BIOS routines for displaying text and scrolling the screen. Also got to learn what a 'linker' did and how QB did argument passing on the stack. I still wonder if I was the only person in the world linking my assembly code into a QB app I also wrote. But hey, it worked!
Haha, your story about hitting a wall with BASIC only to go somewhere else reminds me of how I decided to learn C: I had "mastered" QBASIC and was learning Visual Basic, so my dad bought me a book called "Hardcore Visual Basic". That book discussed extensively how to get Visual Basic to interact with the native Windows API for fun and profit. Pretty much every chapter began with "this is so much easier in C, but here's how we do it in VB", so wee me decided to hunt for a C compiler in the pile of Shareware CDs I had laying around. Finally found a really old version of Visual C++ (I think it was 2.1, so it was old even by the time) and then spend the next year of my life writing toolbar and common control libraries for lack of anything better to do :)
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.
To be honest, that's precisely what had been on my mind.
Did you know Vinge is himself a computer scientist? IIRC, there's a point in A Deepness In The Sky where its implied that the protagonists' interstellar ramscoop ships run a descendant of Unix.
Yeah, I did read that about Vinge somewhere. And I loved that little callout to the unix epoch.
And you know, Git would be the perfect source control system for an interstellar species who various settled systems are separated from each other by light years.
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.
There are quirks, I'm sure. But that is one that actually makes sense. I do sometimes wish it were easier to cd to the root of the remote, but not often.
I usually prefer having the main remote directory open in dired and a shell session in another buffer. I prefer to work in a Posix shell as AFAIK eshell does not do at least one of: IO redirection, piping.
I really hate that commit message style. Lots of content that can be auto generated, little explanation :(. Not the authored fault, but I really don't understand why so many gnu projects still do this.
"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."
Frankly, Emacs is a fractal of hacks, but it's incredibly powerful, consistent enough from a user perspective, and usually works, so we tend to ignore it.
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.
You'd be surprised how many people use non-GTK X11 Emacs. The reasons they give include being able to connect and disconnect from multiple X servers (GTK has longstanding unfixed bugs here) and being generally lighter on the system than GTK is.
"Pulling [GTK] out into its own frontend" means taking GTK support out of where it is now, Emacs' general-purpose X11 code (where GTK is one of many supported X11 toolkits) and putting it in a new top-level window-system that's a peer of NS (for OS X) and Windows support. The new GTK window system wouldn't be allowed to use X11 functions directly. Under this architecture, Emacs would be much closer to a well-behaved GTK program and could take advantage of cool GTK tricks like Broadway support.
I am one of those X11-only, no-toolkit Emacs users. The only times I need gtk support is when I run a variant build with gtk3 support in order to have a native Wayland window which doesn't require Xwayland. But I primarily use X11 so the no-toolkit, X11-only build.
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.
Black and white horizontal lines or misrendered text for a split second until a white blink rerenders the whole page. Happens somewhat frequently when I have heavy CPU load on a Linux laptop.
It definitely flickers a bit when running in XQuartz.
(I hope this change doesn't make it run crappily in XQuartz! X-Windows programs that do double buffering draw to an offscreen buffer often perform really poorly, poorly enough that I'd definitely rather have the flicker, not least because I don't mind the flicker too much anyway.
(I assume a lot of them have a client-side pixmap that's written to manually, and then has to be sent over the network link. )
One of the advantages of using the X double buffer extension or XRender or something like that is you don't need to send raster image data over the network. You're still sending ordinary drawing commands, and it's the server that accumulates the results into a pixmap somewhere.
If it is slow for you, you can turn off the new stuff:
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.
Ditto, stock 14.04 Trusty running Unity, and this was also true for Debian releases lenny through wheezy, and at least two very different hardware systems.
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.
You should be able to just (setq scroll-conservatively 1000). As you no doubt have guessed, the page-by-page scrolling default in Emacs is to reduce the amount of redrawing necessary.
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.
Around 10 years ago is when I moved back into Windows on my main computer, so eventually I settled on using whatever Emacs version is installed, if any, when accessing GNU/Linux environments.
Another aspect was I think only XEmacs had nice menus and toolbar, until eventually Emacs added them.
He was modernizing it on top of X11, which is still pretty far from a modern compositing window system. Also it looks like much of the challenge was even just identifying when drawing was truly complete. That problem doesn't go away by just putting a compositor in front.
You still need to tell the compositor when you're done with the back buffer, which emacs has no concept of, because there's no defined lifecycle for its draw calls.
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).
Sure, that's why I asked if there's topic branch, even if now obsolete, which I could merge into the 25.1 branch. I'll do some digging, since this seems to be a single commit from what I can tell.
What would a modern GUI look like for Emacs? And how would it be an improvement?
Every time someone releases a new IDE or text editor or word processor I take a look and then return to Emacs. I don't mean that it is perfect, just, for me, better than the rest.
Currently per the article states, the Emacs GUI uses a lot of hacks to display like a terminal. Because of this a lot of things like real smooth scrolling doesn't work like most text editors. Highlighting text with a mouse for example just doesn't feel right. I know people will say who uses a mouse to operate Emacs anyway but there are plenty of other scenarios that makes Emacs feel somewhat ancient, which it doesn't have to be. I don't use Linux DE a lot to know all of the quirks but on OS X when Emacs go full screen there are still black borders, etc. Imagine the possibilities of having a non-text only modeline for example, the ability to render pdf and modern JS/CSS websites, etc.
In what way does highlighting with the mouse not feel right?
Seems to work pretty much the same as in Visual Studio to me. Mind you I hardly ever use it, I prefer to mark the region instead.
If you can add what you want to Emacs without making the new features compulsory and without removing the existing ones then by all means go for it. But I suspect that the lack of some features is simply down to no one with enough enthusiasm and expertise to build them actually wanting them. Most of Emacs' features were built by people who wanted to use them so a lot of stuff ends up being worked on just until it is good enough for the creator's own purposes.
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 wouldn't call it "bad". Is it different from most modern programs? Certainly. But it does a lot of clever things well. A program that I use every day can't be all bad.
Bad as in hard to read, update, and maintain. It certainly achieves useful results! Congratulations on managing such a large change.
BTW, I just double-checked, and I can indeed make it flicker when resizing the window as you mention in emacs-devel. I guess I've just never noticed since I never resize anything (maximized windows or nothing).
> 400 lines of code to wait for keyboard input.. sweet Jesus.
That function isn't particularly bad. It's a little messy, but it's reasonable for legacy portable code.
>> This function is over 400 lines and contains over 40 #ifdefs.
This is a low-level function that is supposed to handle different platforms, so this is the function where platform-specific #ifdefs should be collected. It's mostly a giant case/switch style #ifdef wrapper around a list of platforms and features.
>> Vim tries to be compatible with every OS, including dead ones such as BeOS, VMS, and Amiga.
That isn't a bad thing. Unless there is an actual[1] problem with the legacy platform support, then it should be left in for the people that do use the "dead" OS.
> Features that drastically change behavior are enabled/disabled with preprocessor flags.
Yes, that's the point of those flags. This is to enable/disable major features like XCLIPBOARD support which isn't going to compile on non-X11 platforms, or for debug and other unusual features that shouldn't be included in standard builds.
> Cross-platform libraries like libuv didn’t exist when Vim was created.
Sure. Which is why this function exists. Also, libuv is nice, but it isn't a replacement for all of the features (like XCLIPBOARD) this function provides. Even if most of the function was replaced with a libuv port, some of the #ifdefs would still be necessary.
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)??
Every time I'm reading about emacs I'm thinking if it might be worth porting my vimrc to emacs+evil. What do you think? Anyone done the switch? Are there any significant benefits I get from doing it?
I made the vim -> emacs+evil switch a few months ago, no spacemacs.
What drew me to it at the time was emacs --daemon and emacsclient, which lets you have the same view of the same files open in different terminals or GUI windows ("frames") and saves you from the "file already open" warnings you would get from vim when e.g. editing a file and browsing ctags in different terminals.
Things I found annoying after the switch:
* lack of tabs (situation may have changed since I switched; there's an evil-tabs package but I haven't used it. By now I just got used to emacs' way of doing buffers and frames)
* I feel like I'm fighting the built-in bindings a lot in cases like e.g. dired-mode (directory browser) and Ibuffer-mode (buffer listing)
Notes which you may find useful if you decide to try it out:
* While emacs will work in a terminal, I've found it more comfortable to use the GUI, because it saves me having to think about why e.g. trying to look up help triggers a backspace (C-h).
* my evil config, for an example of some settings and how to tame bindings: http://pastebin.com/TxxuSU8u. Not just mine, a lot of people post their init.el online, and they're often a good reference.
I switched from emacs to vim a few years ago. I'm happy I did it. I think you need a concrete reason to switch. I also switched to the emacs key bindings. I figure if you are going to use an editor you should use it as intended, but that's personal preference. Plenty of people are happy with evil.
My specific reason was I wanted to be able to run commands asynchronously in a separate buffer, rather than switching back and forth between the editor and a terminal. The other reason is I think vimscript is terrible, and I didn't want to learn it to customize the editor. Elisp is much nicer, and the documentation is fantastic.
I've heard VIM has since gained async buffers, but not lisp.
As for knock on benefits, there is really a fantastic ecosystem of applications built for emacs that I can't imagine are possible for most other editors. This is because emacs is a lisp runtime that happens to include an editor. So it has a built in terminal, email client, irc client, Tramp mode, Org mode, etc.
Diehard Vim user here. I use Vim-motions everywhere, system-wide.
You should at least try Spacemacs, learn the layers system and then based on that build your on configuration. Trust me - it just makes things a lot easier. Spacemacs comes in different "flawors" you can choose bare-bones, instead of default and then add anything you want on top of that.
I switched from Vim to Spacemacs (sorry...). I am considering setting up a vanilla emacs w/ Evil soon but I feel like I need to set aside a day or so to do it. Spacemacs does do a lot for you, and the layers system is not without its benefits.
Sorry, this turned into a bit of a thought splurge, but serves as a good overview of why I'm sticking with Emacs for now (after using Vim exclusively/obsessively for years).
Number one benefit of Emacs is Lisp. Hacking on plugins is a lot more pleasant because of it. I don't think I'm alone in my dislike for Vimscript and love of Lisp.
There are many other factors that make it more pleasant than Vim. I like that `M-X` just shows a fuzzy-matched list of elisp functions, I like that I can do (eg):
M-X, find-function, ENTER, [function-name]
and jump to the on-disk definition of that function.
The packaging system (with MELPA) is far more satisfying and modern than my old pathogen + git repo setup for vim. I think this is getting better in vimland too, though.
As far as specifics go:
The best thing for me is autocompletion, I used YouCompleteMe in Vim which (don't know if this is still the case) used to block UI rendering all the time. I remember it being particularly irritating for JS development using Tern, which works great with the relevant Emacs plugins.
CIDER[1] is amazing for Clojure development (this is actually why I switched).
Magit[2] is much more pleasant than Fugitive IMO, though they accomplish much the same thing. For what it's worth I was never really sold on Fugitive (I just use the console...), but I tried briefly. I find myself using Magit more and more (in particular for inline diffing, "Oh what changed here since commit X" sort of stuff).
The old joke that Emacs is 'basically an OS unto itself'. I actually appreciate this. There seems to be more of a culture of developing "apps" for Emacs, things like helm-spotify[3], which are actually pretty fun/useful. I know there are mail clients too, for instance. Being able to open a console in the project dir with `SPC-'` is something I enjoy vs using TMUX.
I think, in general, I prefer Emacs' more ambitious approach when it comes to windows/buffers within the app itself. This is a difference in philosophy.
Projectile[4] is another plugin I very much enjoy using. Don't know if this is personal preference/maybe I never put in the required effort in vim-land, but I never came across anything as satisfying, simple, functional to use.
I have heard nothing but great things about Org mode[5], though I have yet to jump in there. Again I feel like I need to invest a little time into it before it becomes useful. I have appreciated (certainly in the GTK version) that Emacs supports a slightly more rich display than Vim did (Images, bullet points etc). This is just eye candy, though. Also comes with the caveat I never tried GVim, maybe it is also capable of these things somehow.
The single most frustrating thing is my current inability to tame the auto-indent algorithm, as well as TAB's behavior. I don't know if this is Spacemacs specific.
Now we just need something like this for Vim. I don't know why, but iTerm 2 + Vim is very slow for me. Holding "j" or "Ctrl + Y" for instance is jerky and slow. Maybe it's just my computer and no one else has this problem, but it's a relatively recent MacBook Pro. I've checked all my settings in .vimrc and Googled the problem, but I can't seem to figure out what is making it so slow.
Spacemacs is not just a mode or a bunch of modes. Building decent evil-based config is not easy and may take years. Every Vimmer I believe should at least try Spacemacs.
Yep, it's still slow/jerky (although it does seem that disabling relativenumber helps a little bit). I have no idea what the problem is. It could be that I expect perfectly smooth cursor movement, and I'm just not getting that for some reason.
You say "smooth cursor movement". Can you elaborate? What exactly is "slow"? When the screen is scrolling? When the cursor is moving? Spacebar will move the cursor one character forward in normal mode, and follow newlines. If it is the cursor, is it just as choppy if you hold the spacebar?
"My diff turns scrollbars and other widgets that share screen space with the double-buffered region into independent X windows. Overall, it’s a giant hack."
Ain't that how X11 was originally envisioned? You'd create a bunch of windows made of many smaller windows. At least, that's the impression I got when I started playing around in X11 (mostly for StumpWM hacking).
It's great to see improvements in Emacs. Are there any developments on getting a decent terminal emulator? I use term but occasionally have to open GNOME terminal when Emacs' term can't display something properly (like ncurses-based programs).
I wrote term mode but long ago stopped maintaining it. So other people have made hacks on top of my hacks ...
One of my goals was to unify shell-mode (and related "comint" modes) with a proper terminal emulator, but had a hard time getting traction for this. So people added horrible hacks like color support to shell-mode, instead of improving term-mode. I mentioned this unification goal recently (see bug#22785 "comint/shell modes should be merged with term mode"), but people still don't get it.
These days I'm back to working on terminal emulators, but using Web technologies (DOM, JavaScript, CSS). It's pretty cool, IMNSHO. Please check out DomTerm (http://domterm.org).
I tried writing one in pure Elisp some time ago, but it was too slow. Maybe I'll give it another shot in C this time, on top of the new dynamic module support.
The built-in terminal emulator is atrocious, both code-quality and feature-wise.
I agree with you as an end user that the features of all terminal emulators available in emacs are atrocious. Have my up vote, and silent support should you decide to really put some time into a better terminal for emacs.
Any reason you chose to use DBE instead of just creating two drawables and swapping with Present / CopyArea? DBE is considered deprecated over the newer techniques since it's not accelerated.
A famous aphorism of David Wheeler goes: "All problems in computer science can be solved by another level of indirection" (the "fundamental theorem of software engineering"). This is often deliberately mis-quoted with "abstraction layer" substituted for "level of indirection". Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection."
Emacs' redisplay architecture is an adaptation for ancient serial terminals with very low rates. On those terminals emacs has always been "buttery smooth" compared to other editors! Of course very few people have any reason to use those terminals these days.
I have heard that double-buffering is an excellent solution to a number of data-stream problems. Are there any resources on StackOverflow explaining such things?
What's to explain? You allocate two image buffers. At any particular time, one is displayed and the other is hidden. You draw to the hidden buffer. When you're done drawing, you swap the buffers. Lather, rinse, repeat.
One editor to rule them all, then you don't have to individually configure every IDE with various idiosyncratic preferences. & learn new sets of commands which you can't take with you elsewhere. Reuse muscle memory between all situations. Reuse over SSH. Low resource requirements. Infinite scriptability
Multiple editors would have been an issue for me a few years ago, but JetBrains has changed that (for the set of languages I use, anyway). I can use the same IDE for a bunch of different ecosystems.
Reuse over SSH is a compelling reason. Do you still have low resource requirements if using things like linting, hinting, and full graphical debugging?
> Multiple editors would have been an issue for me a few years ago, but JetBrains has changed that (for the set of languages I use, anyway). I can use the same IDE for a bunch of different ecosystems.
Exactly. Now, imagine being able to use that same IDE for everything JetBrains supports, and to read man pages, and to read info pages, and to read & compose email, and to list the processes running on your computer, and to manage files in directories, and to emulate a terminal, and to browse the web, and to play NetHack, and to use IRC, and to manage git repos, and to do every other thing you want. And all the keybindings remain consistent throughout all of those modes. And you can easily schlep data back & forth between them. And it's extensible in a relatively sane language (sane compared to Java, JavaScript, C, C++ and Python, anyway).
That's why we use emacs. That's why it's very difficult to understand why anyone else doesn't use emacs.
> Do you still have low resource requirements if using things like linting, hinting, and full graphical debugging?
Emacs can be pretty amazingly fast even with all of that running. There are advantages to having first been written back when computers were small.
On my MBP, I can get about 6-7 hours of low-intensity use out of VS Code or Clion, which is pretty unconscionable because I think slowly and most of that time is just waiting for keystrokes. I get about 8-9 with graphical Emacs (with autocomplete, etc). I get about 11 using Emacs on a remote server over ssh. Auto complete, etc, works fine on the terminal.
Yes, Emacs is very light-weight no matter what you're doing. Although I must admit that my copy is using 3.45GB of memory at the moment; I opened a 1.8GB tar file... that was on a remote machine.
Emacs is pretty lightweight (sic!) compared to IDEs. I use it as a general-purpose editor (text, C, Python, shell, configuration files, HTML [web-mode is pretty good]). It's "snappy" even on very slow machines. Add-on modes are often pretty good. Has interesting shortcuts (C-x h M-q).
FTR I've been using Emacs for over two years and didn't bother yet to learn "real" navigation commands. I use arrow keys + Shift/C and/or mouse/trackpoint.
For most bigger projects I use the appropriate IDE (normally JetBrains or QtCreator) unless I'm on a laptop.
Movement keys in other IDEs like JetBrains is still lacking in my opinion. I haven't seen another IDE which lets you move between buffers(documents) as easily as Emacs. I've tried a bunch of IDEs and will support one style of movement like move split right / left but lack something like move other split etc...
Another thing is that Emacs movement is also very fast relative to some IDEs which sometimes pop up other windows which you have to interact with like in JetBrains Switcher.
That being said if you write IDEs just look at how fast, easy to configure, and complete buffer movement is in Emacs. We want these features!
Exactly, if you want efficient jumping around, ace mode is amazing. Basic flow is: look where you want to place the cursor, press jj, then the character you are looking at. Doesn't matter where the cursor was.
It lets you directly jump to a specific character without bothering with movement keys. Basically what happens is, suppose you have 5 x's on your screen. You'd bring up ace jump (or its replacement, avy), and then hit x. It'd convert the first x to a, second to b, ... fifth to e. Suppose you wanted to go to the fifth one, you'd then hit e, and your point would move there. It's kind of cool. I have it installed, but truthfully don't use it very often.
Edit: Oh you meant "why would you use evil mode". Disregard.
For certain languages, the IDE of choice is great. For what seems like the majority of languages, it isn't.
In the last week, I've edited javascript, html, python2, python3, sql, json, yaml, graphviz, markdown, and docker files. Looking back a little longer, throw in C, C++, bash, z-shell, R, lisp, LaTex, and perl5.
Having an appropriate and reasonably consistent editing experience works for me. For Java, the eclipse experience has grown on me, so I prefer editing Java outside of emacs for anything but quick edits. I pretty much just do quick edits in C or C++, but if I were to be doing it daily I would probably prefer a dedicated IDE like Visual Studio. I'd probably prefer Viz Studio for python, but that would require working in a windows VM and that's just not going to happen.
The utility of some basic functions like column editing, zap-to-char, hippie-completion, macros, yasnippet, etc. that I've grown used to over the years coupled with syntax highlighting and predictable indentation for pretty much anything I'm editing makes it hard to seriously consider another editor. I'm sure vi/vim users feel the same way about features that seem small but get used very frequently.
Regardless, it all boils down to productivity. I'm productive in emacs, so I like it. I wouldn't force somebody to use it - or even recommend it for someone who didn't have the time to build the muscle memory before needing to be productive.
I just don't think I write code in any languages where the IDE is not great, nor do I ever write code in constrained-resource environments (old machine, SSH, etc.) I'm on a desktop, laptop, or cloud desktop.
> I just don't think I write code in any languages where the IDE is not great
Well, neither do we emacs-users: every language we write in has an amazingly great IDE, because emacs is our IDE for every language. And, other than go-mode's wanton breakage of M-., there aren't generally gratuitous inconsistencies when switching between languages.
I don't really think of emacs as being a solution in resource-constrained environments (although it works well there too): it's excellent on its own, not just a way to eke out constrained resources a bit further.
I've used many proprietary IDEs and editors and at some point I realized - it's a myth and it's a lie. A golden cage. This argument is like iPhone vs Android. "But iPhone just works" they say, "and Android always, just always needs some chiseling". When it comes to the editor though, (the main instrument of my daily work) - I am ok with some chiseling and sandpapering. People often try to compare efficiency metrics, debate over features and smoothness of scrolling. Very often though they overlook one important factor - the joy of use. I find Emacs exceptionally satisfying. Because it gives you complete, almost total control of important aspects of editing and navigating through the code. Over the years I met many people who hated/disliked/misunderstood Visual Studio/Eclipse/IntelliJ/Sublime/Netbeans. I have never met a single person who really tried Emacs for a few months and either hated it or felt like it's limited or "stupid". The only real criticism Emacs gets - "Emacs is hard". "I want something simple". Well then. If you are so lazy to learn how to drive, how could you expect your bicycle to be as convenient as a luxury car and as powerful as a fighter-jet?
Take my use-case: I get random-ish formated data through email and need to often create semi one-time python scripts that do specific jobs with that data. That mean I need to clean the data and separate relevant from irrelevant, format it to be used with python, last take the output and format that as requested.
Macros are invaluable. Search and replace regexp is invaluable. Compare buffer, unique, sort and rectangular insert is invaluable.
There is no purpose-built python IDE that is tailored to my use case. The closest is ipython, and I already run that parallel with emacs when doing more complex python coding.
Many of the things a purpose built environment can do can be built into emacs. I used to go through the effort of setting them up. Like a sibling post, I typically do quick edits nowadays, and don't bother. (Worse, every big company I have ever worked for uses another bloody build system...)
That said, the things that keep me in emacs:. Magit, eshell, tramp, many toy enhancements I have written, I like the themes, erc, and org mode.
I wasn't implying that Emacs lacks features of other IDEs/editors. I only meant that Emacs requires a huge amount of configuration to reach the functionality of, say, PyCharm for Python.
> I only meant that Emacs requires a huge amount of configuration to reach the functionality of, say, PyCharm for Python.
Eh, out of the box you're right, but I'd advise most folks to just install prelude (or if they're coming from vi-land, spacemacs), which has already done all the configuration for one.
The flip side, is that I don't have an editor that has changed on me as much as pycharm and friends have. More, as I use new languages, I get to take advantage of configurations i already know really well.
Because IDEs are less efficient at many things. Simply writing code in a language I am familiar with using a familiar API is faster and more comfortable in Emacs. Also there are loads of useful tools like Org mode, tables, ediff, etc.
I regularly code over SSH, and the machine where I’m most productive at writing is a laptop clocked down to 100MHz with bare Emacs on X11. You simply cannot do that with a current-style IDE.
That isn't how I meant "purpose-built". I meant an IDE tailored to a particular language and ecosystem.
For example, there are IDEs that have excellent code generation for Java (not defending the practice of boilerplate getters/setters, just pointing out a feature that people use). There are IDEs with hinting, linting, and debugging built-in and requiring no configuration.
My question was: at what point is the ultra-flexibility of Emacs no longer worth it?
can we please refrain from posting facebook links unless the circumstances dont allow any other blog host ? call me a privacy fetishist but it is in the best interest of everyone to avoid this site like the plague.
I really dislike this style of writing. When I came to the actual important part I was exhausted already having read paragraphs of much-ado-about-nothing. GNU Emacs is older than me, and it's probably older than X Windows, certainly it'll have some weird things here and there. Why the shock?
I haven't ever experienced any flickering on emacs myself, but thanks to the author for the patch anyways. One thing I'm looking forward to is the concurrency patch.
Styles of reading also vary. You do not always have to struggle through "boring" parts to be able to understand the parts that you think are more important or interesting. (I, for one, thoroughly enjoyed the entire piece, having found all parts equally interesting and fun to read.)
Then don't read it. Surely there will be a summary blog post written for those that don't like long form. I personally enjoy the meandering sometimes. It's the difference between reading a book and reading the cliff notes, they each have their place.
As you see you better keep them comments to yourself. This guy wrote that I'm "shitting on" things and "nobody cares about [my] opinions", and no mod intervention. A couple months ago I told a guy he was being too pedantic and my thread was detached.
It's not of your business whether I read it or not. This is my opinion on the prose style, addressed to the author, and secondarily to other bloggers here.
As someone that been on HN for 9 years, pushing back on these kinds of comments is my business. This is my opinion on the value of you coming to Hacker News to complain about the author's writing style, and secondarily aimed at other commenters here. Your style of just summarily shitting on how the author wrote this piece adds no value to the discussion. Clearly lots of other people like it, this has been the #1 piece on HN for hours. If you don't like it, no one is forcing you to read it or asking for your opinion.
In the mean time comments like yours dissuade other people from putting themselves out there. I'll get 100 positive responses on something I write or say at a conference, but the 1 hater always sticks out more. If that means fewer people write publicly it makes us all worse off.
But there are real issues with the style of trashing on old tech for being old, which this post is full of. Emacs is being criticized for making what amount to practical technical decisions. This is a relevant point in the current tech climate of rewriting the last framework "because 2013 is so old".
Didn't sound like the author was trashing on emacs for being old, to me. It sounded loving, if anything. I was practically jealous of his intimate relationship with his editor by the end of it.
I really wish I could flag responses to my comments because what you do is a personal attack on me and this will go by because my top level comment is at the end of the thread.
It was an irresistible title for me. I think it had something to do with the fact that I was hungry when I read "Buttery Smooth Emacs" and before I knew it, I had read the article.
I have to agree. I tried hard to read it, but half way through I couldn't shake the "my 8-year old is more mature than this" and gave up.
The author doesn't appreciate the motivation and constraints that led to this. Obviously Emacs has been hugely successful despite these perceived "flaws". For me, it's a feature that it still supports old terminals and yes, I do use it. I haven't seen the patch, but it wouldn't surprise me if it breaks old functionality that some of us depends on.
I got the impression that the author really loves Emacs and has spent a huge portion of his life caring about it and I think there's a huge amount of enthusiasm in the post.
It manages to be fairly lighthearted and fun, while still teaching me something about Emacs. All in all, I really liked it.
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