40 ms·

Buttery Smooth Emacs

651 points by cheiVia0 10y ago

cm3 10y ago
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).
- quotemstr 10y ago
  M-x report-emacs-bug. We can talk about it there. Doubtful, though, since this work is both 1) brand new, and 2) not a regression fix. "But I wants it!" is not a reason to backport fixes or issue new releases. You can always run from master for now.
  - cm3 10y ago
    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.
jefurii 10y ago
Emacs flickers? I've never noticed this, but I've only ever used it on Linux. Maybe it flickers in OSX?
- melling 10y ago
  The article is a discussion about X11.
- dom0 10y ago
  Perhaps using a compositing desktop manager mitigates it, since those are almost always vsync'd and double buffered. Edit: Hm, no there is no synchronization between the WM and emacs in any way. So this can't be it.
  - deleted 10y ago
    [deleted]
  - to3m 10y ago
    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. )
    - quotemstr 10y ago
      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: (modify-frame-parameters nil '((inhibit-double-buffering . t)))
      - rurban 10y ago
        But why inhibit-double-buffering and not just the simple no-double-buffering?
        to3m 10y ago
        There are only 3 variables with a "no-" prefix, but 30+ starting with "inhibit-"...
  - digi_owl 10y ago
    Would not surprise me one bit if the compositing is the cause rather than the "solution".
- NoGravitas 10y ago
  You may just be pure of soul. I don't see a lot of flickering on X either, but I don't get too use emacs there as much as I'd like, either.
- fit2rule 10y ago
  I've noticed it, since like, forever. Its why I'm a vi guy. But I must admit, this butter-smooth version of emacs sounds intriguing .. off to give it a try.
- hollerith 10y ago
  Are you using Emacs inside a terminal? The flicker happens only with graphical Emacs (and then only on Linux IIUC).
- pmontra 10y ago
  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.
  - hga 10y ago
    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.
- p4bl0 10y ago
  Same here, I've been using Emacs daily (and a lot) in X11 for almost 10 years now, and I've never experienced flickering.
- quotemstr 10y ago
  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.
  - dman 10y ago
    Are your fixes available in trunk?
    - quotemstr 10y ago
      Yep.
      - dman 10y ago
        Thanks!!!
  - edem 10y ago
    How do you describe this flicker effect? I've never seen it.
    - startling 10y ago
      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.
- hellofunk 10y ago
  Me too, I've used emacs on several different OSX computers in recent years and never seen any flicker.
- qwertyuiop924 10y ago
  Nothing, on i3, and graphical. So it seems near-random.
- base698 10y ago
  I notice it using cider.
- eeks 10y ago
  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.
pjmlp 10y ago
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. Last time I have used it was around 10 years ago.
- jabl 10y ago
  IIRC a couple of decades ago XEmacs used the new and fancy Athena widget set (Xt), whereas Gnu emacs used, uh(?), raw Xlib. Though I think XEmacs is mostly dead nowadays..
  - pjmlp 10y ago
    I would need to search for it. 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.
late2part 10y ago
Thank you for taking the time to make things better.
deleted 10y ago
[deleted]
NoGravitas 10y ago
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.
- jabl 10y ago
  So for those of us not in the inside loop, what does "pulling out into its own frontend" mean? Also, are the Xt and motif versions still maintained? Surely the user base of those must be pretty close to 0 these days?
  - quotemstr 10y ago
    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.
    - cm3 10y ago
      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.
      - audidude 10y ago
        It does X11 specific calls unconditionally, so it is not currently possible to run emacs as a native Wayland client.
smnscu 10y ago
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.
- catern 10y ago
  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.
- s_p_lee 10y ago
  Are you using OS X / mac OS? If so, have you tried Mitsuharu Yamamoto's Emacs Mac Port? Available as Homebrew tap: https://github.com/railwaycat/homebrew-emacsmacport https://github.com/railwaycat/homebrew-emacsmacport
harrygeez 10y ago
How much effort would it take to rewrite a modern GUI for Emacs?
- dom0 10y ago
  ∞
- kwhitefoot 10y ago
  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.
  - harrygeez 10y ago
    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.
    - kwhitefoot 10y ago
      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.
hobo_mark 10y ago
Sorry if it's off-topic, but since when can you publish formatted "blog posts" on facebook?
- shp0ngle 10y ago
  It's called Notes. For about 6 months.
  - erelde 10y ago
    Actually there was a similar feature almost since the beginning.
    - shp0ngle 10y ago
      Yes, but the Medium-inspired formatting is quite new.
  - ArneBab 10y ago
    And it for sure helps to have been a Facebook developer :)
rwmj 10y ago
Surely with modern compositing window systems, the Emacs approach of "I'll draw whenever I like" is actually the right one?
- ianlevesque 10y ago
  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.
- msbarnett 10y ago
  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.
Xcelerate 10y ago
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.
- godd2 10y ago
  What plugins do you have installed? If you run `vim -u NONE` and then open a file, is it still slow when you hold j?
  - Xcelerate 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - palunon 10y ago
      Did you try using `:set ttyfast` ?
    - godd2 10y ago
      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?
- maxtudof 10y ago
  Try running this and restart your mac: defaults write NSGlobalDomain KeyRepeat -int 1 defaults write NSGlobalDomain InitialKeyRepeat -int 10 It will setup blazing fast keyboard repeat rate. I also use this in my .vimrc for even smoother ride: set scrolloff=999 set scrolljump=-100
twsted 10y ago
"One day, a fool wanted to run Emacs in a GUI as a native GUI program. The rest is ChangeLog."
- marai2 10y ago
  "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."
  - qwertyuiop924 10y ago
    ...Well then how do fonts, images, and embedded X widgets work? Are they elisp hooks into the lie?
    - swhipple 10y ago
      They're propertized text. For example, on the splash screen, you can move the point on the logo and M-x describe-char to see that it has: display (image :type svg :file "splash.svg") https://www.gnu.org/software/emacs/manual/html_node/elisp/Display-Property.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Di...
      - qwertyuiop924 10y ago
        That makes sense. 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.
rayiner 10y ago
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.
- dman 10y ago
  The only thing I miss in terminal are Hyper and Super. Is there some way to get them to work in terminal?
  - ubolonton_ 10y ago
    You can configure the terminal emulator to emit a specific sequence for hyper/super, then configure Emacs to convert it back using local-function-key-map: http://unix.stackexchange.com/questions/79374/are-there-any-linux-terminals-which-can-handle-all-key-combinations http://unix.stackexchange.com/questions/79374/are-there-any-.... Out of the box, Konsole+Emacs do this with super.
- gkya 10y ago
  I use tramp for all things ssh these days. Becomes very practical w/ ssh-agent and Emacs bookmarks.
  - wcummings 10y ago
    You can even use eshell w/ tramp... sorta
    - taeric 10y ago
      What do you mean sorta? The eshell integration is amazing in later versions. Can cd into docker instances. Is glorious.
      - wcummings 10y ago
        Just quirks, like if you cd to an absolute path 'cd /' it will cd to the local path not the remote one.
smt88 10y ago
I've never understood why anyone uses Emacs over purpose-built IDEs. This article made me even more confused. Can anyone explain?
- __s 10y ago
  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
  - smt88 10y ago
    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?
    - db48x 10y ago
      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.
    - wtbob 10y ago
      > 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.
gkya 10y ago
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.
- Koshkin 10y ago
  > style of writing 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.)
  - gkya 10y ago
    Yes that's what I eventually did, just skipped forward to the end. But still the general dismissiveness of the article is off putting.
- FullyFunctional 10y ago
  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.
  - 59nadir 10y ago
    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.
plg 10y ago
How do I install this version? (On a mac, preferably using homebrew)
db48x 10y ago
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.
- quotemstr 10y ago
  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.
  - db48x 10y ago
    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).
  - xenobioticants 10y ago
    I think he meant bad as in this: http://geoff.greer.fm/vim/ http://geoff.greer.fm/vim/. 400 lines of code to wait for keyboard input.. sweet Jesus. Thankfully Neovim exists now. Granted, that's a VIM example, but I can't imagine Emacs being much better in terms of code.
    - quotemstr 10y ago
      FWIW, I've hacked a little bit on bash, and IMHO, Emacs internals are _much_ cleaner than bash's.
    - pdkl95 10y ago
      > 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. [1] "It's old" doesn't count.
maxander 10y ago
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.
- aboodman 10y ago
  See also "software archeology" in the sci fi book _A Fire Upon the Deep_. God I love that book.
  - mrob 10y ago
    Software archaeology is from the prequel, "A Deepness in the Sky".
    - aboodman 10y ago
      Ah. Well, I love them both.
      - TheEzEzz 10y ago
        Software archaeology is in both =D
      - kctess5 10y ago
        I love them both as well. Edit: read the prequel first, imo.
  - maxander 10y ago
    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.
honkhonkpants 10y ago
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.
mrcactu5 10y ago
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?
- lisper 10y ago
  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.
ekr 10y ago
This is the commit in question: https://github.com/emacs-mirror/emacs/commit/c29071587c64efb30792bd72248d3c791abd9337 https://github.com/emacs-mirror/emacs/commit/c29071587c64efb... for those interested.
- anarazel 10y ago
  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.
Jasper_ 10y ago
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.
ddp 10y ago
Prerequisites: XCode 8.1, brew, autoconf, automake, libxml2 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
- jordigh 10y ago
  > Prerequisites: XCode 8.1 There are more things in Heaven and Earth, Horatio, than are dreamed of in your iPhilosophy. ;-)
Scarbutt 10y ago
Now we need true color terminal support.
zython 10y ago
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.
- Waterluvian 10y ago
  You can see the domain name before clicking the link. Just don't click them. Leave it up to others to make that decision for themselves, as well.
- smonff 10y ago
  Talking about Emacs on Facebook is awful. As if the thing was "only a text editor" and not a symbol of freedom...
  - iLemming 10y ago
    Author also worked at Facebook. According to your logic it would be awful if North Korean journalists would talk about freedom of speech.
    - smonff 10y ago
      For a Facebook employee, there is many other ways to speak about Emacs than on a closed platform. In North Korea, I am not sure they have many alternative if they want to chat about freedom of speech. Though, I appreciate that you compare Facebook to North Korea.
  - jakebasile 10y ago
    Freedom also means using whatever method you choose to talk about what you choose.
    - smonff 10y ago
      Sure, but Emacs didn't became Emacs without it's specific freedom ideology. Sorry, but I find it weird to forget about it.
AceJohnny2 10y ago
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/ 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 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24678
- quotemstr 10y ago
  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.
- armitron 10y ago
  This issue is aleady solved in Yamamoto Mitsuharu's Emacs OSX port (https://bitbucket.org/mituharu/emacs-mac 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. [1] https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403b4f0aea8152df9d60d63f391a/README-mac https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403...
fiatjaf 10y ago
Now people are publishing on Facebook pages that look like modern blogs?
- bandrami 10y ago
  Facebook employees are
  - chris_wot 10y ago
    I'd be tempted to do this. Not work for Facebook, but blog using Facebook.
    - fiatjaf 10y ago
      Because you're insane?
      - chris_wot 10y ago
        It's quite possible.
- criddell 10y ago
  I think you can also use Instant Articles. Basically, publish on your blog and point Facebook to your blog's RSS feed.
smonff 10y ago
I am chocked that somebody that can be so involved in Emacs can share it's ideas on Facebook. It would be a big failure for Emacs.
- United857 10y ago
  Dan is an ex-Facebook engineer.
bonquesha99 10y ago
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. * The Craft of Text Editing: https://www.finseth.com/craft/ https://www.finseth.com/craft/ * Writing a Text Editor From Scratch: https://www.twitch.tv/gary_bernhardt/v/90796516 https://www.twitch.tv/gary_bernhardt/v/90796516 * A Modern Text Editor Built in Rust: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ
- omtose 10y ago
  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. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune
- dguaraglia 10y ago
  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: https://docs.google.com/document/d/1_S7gv6UGLAKuo9g1tNoNbU2OR_5DBYEdquvYeqgkPMk/edit?usp=sharing 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!)
  - voltagex_ 10y ago
    >(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!) Sounds like a good topic for a small blog post.
  - Lx1oG-AWb6h_ZG0 10y ago
    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).
raindev 10y ago
I cannot read a blog post without seeing who of my fiends is online. Now, this is progress!
- noobermin 10y ago
  I had the same feeling. I often want to keep facebook apart from my hacker reading, for some reason.
yellowapple 10y ago
"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).
kickingvegas 10y ago
Somehow I suspect this is a gambit to pull Jamie Zawinski out of coding retirement.
- bvttf 10y ago
  Don't believe Debian's lies, xscreensaver just got an update this month.
reedlaw 10y ago
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).
- armitron 10y ago
  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.
  - sooheon 10y ago
    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.
- Per_Bothner 10y ago
  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 http://domterm.org).
dvcrn 10y ago
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? (Please don't suggest spacemacs)
- jacobsenscott 10y ago
  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.
- iLemming 10y ago
  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.
  - aldanor 10y ago
    Ditto. Spacemacs is awesome and very configurable (but in a good way).
- bananaoomarang 10y ago
  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. 1. https://github.com/clojure-emacs/cider-nrepl https://github.com/clojure-emacs/cider-nrepl 2. https://github.com/magit/magit https://github.com/magit/magit 3. https://github.com/krisajenkins/helm-spotify https://github.com/krisajenkins/helm-spotify 4. https://github.com/bbatsov/projectile https://github.com/bbatsov/projectile 5. http://orgmode.org/ http://orgmode.org/
raldi 10y ago
I love how the solution was to add another layer of emulation.
- emmett 10y ago
  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." https://en.wikipedia.org/wiki/Indirection https://en.wikipedia.org/wiki/Indirection
unhammer 10y ago
There's a great blog at http://emacshorrors.com/ http://emacshorrors.com/ if you need to satisfy your roadkill-fascination with the layers of hacks we call Emacs. See https://hn.algolia.com/?query=emacshorrors&sort=byPopularity&prefix&page=0&dateRange=all&type=all https://hn.algolia.com/?query=emacshorrors&sort=byPopularity... for some highlights :-)
kanbannoman 10y ago
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)??
- hollerith 10y ago
  I'm pretty fussy, and I haven't noticed any slowness when editing long lines on Emacs on OS X or Windows. Might be specific to the GTK port.
mordymoop 10y ago
If you want a vision of the future, imagine people trying to make Emacs run on inappropriate hardware, forever

651 points by cheiVia0 10y ago

cm3 10y ago

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

quotemstr 10y ago
M-x report-emacs-bug. We can talk about it there. Doubtful, though, since this work is both 1) brand new, and 2) not a regression fix. "But I wants it!" is not a reason to backport fixes or issue new releases. You can always run from master for now.
- cm3 10y ago
  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.

jefurii 10y ago

Emacs flickers? I've never noticed this, but I've only ever used it on Linux. Maybe it flickers in OSX?

melling 10y ago
The article is a discussion about X11.
dom0 10y ago
Perhaps using a compositing desktop manager mitigates it, since those are almost always vsync'd and double buffered. Edit: Hm, no there is no synchronization between the WM and emacs in any way. So this can't be it.
- deleted 10y ago
  [deleted]
- to3m 10y ago
  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. )
  - quotemstr 10y ago
    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: (modify-frame-parameters nil '((inhibit-double-buffering . t)))
    - rurban 10y ago
      But why inhibit-double-buffering and not just the simple no-double-buffering?
      - to3m 10y ago
        There are only 3 variables with a "no-" prefix, but 30+ starting with "inhibit-"...
- digi_owl 10y ago
  Would not surprise me one bit if the compositing is the cause rather than the "solution".
NoGravitas 10y ago
You may just be pure of soul. I don't see a lot of flickering on X either, but I don't get too use emacs there as much as I'd like, either.
fit2rule 10y ago
I've noticed it, since like, forever. Its why I'm a vi guy. But I must admit, this butter-smooth version of emacs sounds intriguing .. off to give it a try.
hollerith 10y ago
Are you using Emacs inside a terminal? The flicker happens only with graphical Emacs (and then only on Linux IIUC).
pmontra 10y ago
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.
- hga 10y ago
  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.
p4bl0 10y ago
Same here, I've been using Emacs daily (and a lot) in X11 for almost 10 years now, and I've never experienced flickering.
quotemstr 10y ago
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.
- dman 10y ago
  Are your fixes available in trunk?
  - quotemstr 10y ago
    Yep.
    - dman 10y ago
      Thanks!!!
- edem 10y ago
  How do you describe this flicker effect? I've never seen it.
  - startling 10y ago
    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.
hellofunk 10y ago
Me too, I've used emacs on several different OSX computers in recent years and never seen any flicker.
qwertyuiop924 10y ago
Nothing, on i3, and graphical. So it seems near-random.
base698 10y ago
I notice it using cider.
eeks 10y ago
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.

pjmlp 10y ago

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. Last time I have used it was around 10 years ago.

jabl 10y ago
IIRC a couple of decades ago XEmacs used the new and fancy Athena widget set (Xt), whereas Gnu emacs used, uh(?), raw Xlib. Though I think XEmacs is mostly dead nowadays..
- pjmlp 10y ago
  I would need to search for it. 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.

late2part 10y ago

Thank you for taking the time to make things better.

deleted 10y ago

[deleted]

NoGravitas 10y ago

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.

jabl 10y ago
So for those of us not in the inside loop, what does "pulling out into its own frontend" mean? Also, are the Xt and motif versions still maintained? Surely the user base of those must be pretty close to 0 these days?
- quotemstr 10y ago
  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.
  - cm3 10y ago
    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.
    - audidude 10y ago
      It does X11 specific calls unconditionally, so it is not currently possible to run emacs as a native Wayland client.

smnscu 10y ago

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.

catern 10y ago
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.
s_p_lee 10y ago
Are you using OS X / mac OS? If so, have you tried Mitsuharu Yamamoto's Emacs Mac Port? Available as Homebrew tap: https://github.com/railwaycat/homebrew-emacsmacport https://github.com/railwaycat/homebrew-emacsmacport

harrygeez 10y ago

How much effort would it take to rewrite a modern GUI for Emacs?

dom0 10y ago
∞
kwhitefoot 10y ago
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.
- harrygeez 10y ago
  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.
  - kwhitefoot 10y ago
    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.

hobo_mark 10y ago

Sorry if it's off-topic, but since when can you publish formatted "blog posts" on facebook?

shp0ngle 10y ago
It's called Notes. For about 6 months.
- erelde 10y ago
  Actually there was a similar feature almost since the beginning.
  - shp0ngle 10y ago
    Yes, but the Medium-inspired formatting is quite new.
- ArneBab 10y ago
  And it for sure helps to have been a Facebook developer :)

rwmj 10y ago

Surely with modern compositing window systems, the Emacs approach of "I'll draw whenever I like" is actually the right one?

ianlevesque 10y ago
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.
msbarnett 10y ago
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.

Xcelerate 10y ago

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.

godd2 10y ago
What plugins do you have installed? If you run `vim -u NONE` and then open a file, is it still slow when you hold j?
- Xcelerate 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - palunon 10y ago
    Did you try using `:set ttyfast` ?
  - godd2 10y ago
    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?
maxtudof 10y ago
Try running this and restart your mac: defaults write NSGlobalDomain KeyRepeat -int 1 defaults write NSGlobalDomain InitialKeyRepeat -int 10 It will setup blazing fast keyboard repeat rate. I also use this in my .vimrc for even smoother ride: set scrolloff=999 set scrolljump=-100

twsted 10y ago

"One day, a fool wanted to run Emacs in a GUI as a native GUI program. The rest is ChangeLog."

marai2 10y ago
"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."
- qwertyuiop924 10y ago
  ...Well then how do fonts, images, and embedded X widgets work? Are they elisp hooks into the lie?
  - swhipple 10y ago
    They're propertized text. For example, on the splash screen, you can move the point on the logo and M-x describe-char to see that it has: display (image :type svg :file "splash.svg") https://www.gnu.org/software/emacs/manual/html_node/elisp/Display-Property.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Di...
    - qwertyuiop924 10y ago
      That makes sense. 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.

rayiner 10y ago

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.

dman 10y ago
The only thing I miss in terminal are Hyper and Super. Is there some way to get them to work in terminal?
- ubolonton_ 10y ago
  You can configure the terminal emulator to emit a specific sequence for hyper/super, then configure Emacs to convert it back using local-function-key-map: http://unix.stackexchange.com/questions/79374/are-there-any-linux-terminals-which-can-handle-all-key-combinations http://unix.stackexchange.com/questions/79374/are-there-any-.... Out of the box, Konsole+Emacs do this with super.
gkya 10y ago
I use tramp for all things ssh these days. Becomes very practical w/ ssh-agent and Emacs bookmarks.
- wcummings 10y ago
  You can even use eshell w/ tramp... sorta
  - taeric 10y ago
    What do you mean sorta? The eshell integration is amazing in later versions. Can cd into docker instances. Is glorious.
    - wcummings 10y ago
      Just quirks, like if you cd to an absolute path 'cd /' it will cd to the local path not the remote one.

smt88 10y ago

I've never understood why anyone uses Emacs over purpose-built IDEs. This article made me even more confused. Can anyone explain?

__s 10y ago
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
- smt88 10y ago
  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?
  - db48x 10y ago
    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.
  - wtbob 10y ago
    > 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.

gkya 10y ago

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.

Koshkin 10y ago
> style of writing 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.)
- gkya 10y ago
  Yes that's what I eventually did, just skipped forward to the end. But still the general dismissiveness of the article is off putting.
FullyFunctional 10y ago
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.
- 59nadir 10y ago
  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.

plg 10y ago

How do I install this version? (On a mac, preferably using homebrew)

db48x 10y ago

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.

quotemstr 10y ago
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.
- db48x 10y ago
  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).
- xenobioticants 10y ago
  I think he meant bad as in this: http://geoff.greer.fm/vim/ http://geoff.greer.fm/vim/. 400 lines of code to wait for keyboard input.. sweet Jesus. Thankfully Neovim exists now. Granted, that's a VIM example, but I can't imagine Emacs being much better in terms of code.
  - quotemstr 10y ago
    FWIW, I've hacked a little bit on bash, and IMHO, Emacs internals are _much_ cleaner than bash's.
  - pdkl95 10y ago
    > 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. [1] "It's old" doesn't count.

maxander 10y ago

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.

aboodman 10y ago
See also "software archeology" in the sci fi book _A Fire Upon the Deep_. God I love that book.
- mrob 10y ago
  Software archaeology is from the prequel, "A Deepness in the Sky".
  - aboodman 10y ago
    Ah. Well, I love them both.
    - TheEzEzz 10y ago
      Software archaeology is in both =D
    - kctess5 10y ago
      I love them both as well. Edit: read the prequel first, imo.
- maxander 10y ago
  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.

honkhonkpants 10y ago

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.

mrcactu5 10y ago

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?

lisper 10y ago
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.

ekr 10y ago

This is the commit in question: https://github.com/emacs-mirror/emacs/commit/c29071587c64efb30792bd72248d3c791abd9337 https://github.com/emacs-mirror/emacs/commit/c29071587c64efb... for those interested.

anarazel 10y ago
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.

Jasper_ 10y ago

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.

ddp 10y ago

Prerequisites: XCode 8.1, brew, autoconf, automake, libxml2 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

jordigh 10y ago
> Prerequisites: XCode 8.1 There are more things in Heaven and Earth, Horatio, than are dreamed of in your iPhilosophy. ;-)

Scarbutt 10y ago

Now we need true color terminal support.

zython 10y ago

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.

Waterluvian 10y ago
You can see the domain name before clicking the link. Just don't click them. Leave it up to others to make that decision for themselves, as well.
smonff 10y ago
Talking about Emacs on Facebook is awful. As if the thing was "only a text editor" and not a symbol of freedom...
- iLemming 10y ago
  Author also worked at Facebook. According to your logic it would be awful if North Korean journalists would talk about freedom of speech.
  - smonff 10y ago
    For a Facebook employee, there is many other ways to speak about Emacs than on a closed platform. In North Korea, I am not sure they have many alternative if they want to chat about freedom of speech. Though, I appreciate that you compare Facebook to North Korea.
- jakebasile 10y ago
  Freedom also means using whatever method you choose to talk about what you choose.
  - smonff 10y ago
    Sure, but Emacs didn't became Emacs without it's specific freedom ideology. Sorry, but I find it weird to forget about it.

AceJohnny2 10y ago

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/ 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 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24678

quotemstr 10y ago
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.
armitron 10y ago
This issue is aleady solved in Yamamoto Mitsuharu's Emacs OSX port (https://bitbucket.org/mituharu/emacs-mac 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. [1] https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403b4f0aea8152df9d60d63f391a/README-mac https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403...

fiatjaf 10y ago

Now people are publishing on Facebook pages that look like modern blogs?

bandrami 10y ago
Facebook employees are
- chris_wot 10y ago
  I'd be tempted to do this. Not work for Facebook, but blog using Facebook.
  - fiatjaf 10y ago
    Because you're insane?
    - chris_wot 10y ago
      It's quite possible.
criddell 10y ago
I think you can also use Instant Articles. Basically, publish on your blog and point Facebook to your blog's RSS feed.

smonff 10y ago

I am chocked that somebody that can be so involved in Emacs can share it's ideas on Facebook. It would be a big failure for Emacs.

United857 10y ago
Dan is an ex-Facebook engineer.

bonquesha99 10y ago

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. * The Craft of Text Editing: https://www.finseth.com/craft/ https://www.finseth.com/craft/ * Writing a Text Editor From Scratch: https://www.twitch.tv/gary_bernhardt/v/90796516 https://www.twitch.tv/gary_bernhardt/v/90796516 * A Modern Text Editor Built in Rust: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ

omtose 10y ago
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. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune
dguaraglia 10y ago
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: https://docs.google.com/document/d/1_S7gv6UGLAKuo9g1tNoNbU2OR_5DBYEdquvYeqgkPMk/edit?usp=sharing 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!)
- voltagex_ 10y ago
  >(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!) Sounds like a good topic for a small blog post.
- Lx1oG-AWb6h_ZG0 10y ago
  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).

raindev 10y ago

I cannot read a blog post without seeing who of my fiends is online. Now, this is progress!

noobermin 10y ago
I had the same feeling. I often want to keep facebook apart from my hacker reading, for some reason.

yellowapple 10y ago

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

kickingvegas 10y ago

Somehow I suspect this is a gambit to pull Jamie Zawinski out of coding retirement.

bvttf 10y ago
Don't believe Debian's lies, xscreensaver just got an update this month.

reedlaw 10y ago

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

armitron 10y ago
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.
- sooheon 10y ago
  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.
Per_Bothner 10y ago
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 http://domterm.org).

dvcrn 10y ago

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? (Please don't suggest spacemacs)

jacobsenscott 10y ago
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.
iLemming 10y ago
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.
- aldanor 10y ago
  Ditto. Spacemacs is awesome and very configurable (but in a good way).
bananaoomarang 10y ago
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. 1. https://github.com/clojure-emacs/cider-nrepl https://github.com/clojure-emacs/cider-nrepl 2. https://github.com/magit/magit https://github.com/magit/magit 3. https://github.com/krisajenkins/helm-spotify https://github.com/krisajenkins/helm-spotify 4. https://github.com/bbatsov/projectile https://github.com/bbatsov/projectile 5. http://orgmode.org/ http://orgmode.org/

raldi 10y ago

I love how the solution was to add another layer of emulation.

emmett 10y ago
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." https://en.wikipedia.org/wiki/Indirection https://en.wikipedia.org/wiki/Indirection

unhammer 10y ago

There's a great blog at http://emacshorrors.com/ http://emacshorrors.com/ if you need to satisfy your roadkill-fascination with the layers of hacks we call Emacs. See https://hn.algolia.com/?query=emacshorrors&sort=byPopularity&prefix&page=0&dateRange=all&type=all https://hn.algolia.com/?query=emacshorrors&sort=byPopularity... for some highlights :-)

kanbannoman 10y ago

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

hollerith 10y ago
I'm pretty fussy, and I haven't noticed any slowness when editing long lines on Emacs on OS X or Windows. Might be specific to the GTK port.

mordymoop 10y ago

If you want a vision of the future, imagine people trying to make Emacs run on inappropriate hardware, forever