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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
"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.
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.
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?
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.
> 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.
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.
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.
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!
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.
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 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.
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.
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.
> 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.
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?
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.
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?
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
235 comments
[ 4.4 ms ] story [ 277 ms ] threadEdit: Hm, no there is no synchronization between the WM and emacs in any way. So this can't be it.
(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. )
If it is slow for you, you can turn off the new stuff:
But I must admit, this butter-smooth version of emacs sounds intriguing .. off to give it a try.
The flicker happens only with graphical Emacs (and then only on Linux IIUC).
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.
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.
Though I think XEmacs is mostly dead nowadays..
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.
I wonder if something analogous this hack would be required in the new GTK front-end.
Also, are the Xt and motif versions still maintained? Surely the user base of those must be pretty close to 0 these days?
"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.
But SHTDI. Volunteering?
[1] https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00...
However, I am responsive on #gtk+ answering questions to people working on this.
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.
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.
For about 6 months.
If you run `vim -u NONE` and then open a file, is it still slow when you hold j?
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
I think the new iTerm2(3?) is quite a bit faster, but you probably use that already. Try Terminal.app and see if you notice a difference.
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.
Out of the box, Konsole+Emacs do this with super.
Edit: Found it out myself. Install docker-tramp.el [1], `C-x C-f` to `/user@myserver|docker:mycontainer:/`
[1]: https://github.com/emacs-pe/docker-tramp.el
Can anyone explain?
Reuse over SSH is a compelling reason. Do you still have low resource requirements if using things like linting, hinting, and full graphical debugging?
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.
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.
-C-f
-C-b
-C-n
-C-p
-C-v
-M-v
-C-s
-C-r
-And finally, whatever key you bound ace-jump-mode to. Seriously, if you are on Emacs, you really need acejump. It's just that good.
Edit: Oh you meant "why would you use evil mode". Disregard.
I tried ace-jump and have it configured for months, I never use it. neither do I use swiper, because it is too slow to start.
Also, don't forget C-M-{left, right, up, down} commands :)
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!
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.
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.
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.
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.
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?
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.
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.)
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.
It manages to be fairly lighthearted and fun, while still teaching me something about Emacs. All in all, I really liked it.
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.
This kind of pissing contest does nobody any good, while we're on the topic of adding value to HN
"But I wants it!" is not a reason to backport fixes or issue new releases. You can always run from master for now.
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).
Granted, that's a VIM example, but I can't imagine Emacs being much better in terms of code.
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.
Intergenerational software development will someday be its own sub-discipline, with professors and specialized techniques and everything.
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.
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.
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
There are more things in Heaven and Earth, Horatio, than are dreamed of in your iPhilosophy. ;-)
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.