I'm currently using the Doom-Emacs distribution for Emacs and everything is working very well. I can use vim keybindings in addition to many other customizations and improvements with very little time invested in actually writing elisp. This is mostly because the developer of the distribution is passionate and optimizes his configuration for modern languages so there is very little needed to change.
If VSCode or any other text editor managed to provide a fast yet highly configurable editing experience without draining my laptop battery instantly, I would immediately switch. So far, none have been able to meet this specification even though I have tried almost all of the common text editors.
I'm hoping a project like the Xi text editor might one day actualize my desire.
I don't think these are trivial issues at all. I do the majority of my computing work in a text editor so it's important to me that it's as performant as possible. Imagine if, in real life, there was a slight lag every time you sent a "command" (e.g. pick up coffee). It would drive you crazy. And yet a lot of developers think that lag is acceptable in software. (I say "developers" because a lot of non-developers I meet complain about software being frustrating to use, even if they may not consciously notice it is laggy.)
People think I'm joking when I say this, but I'm so attuned to Emacs, especially when I'm in a flow state, that I can actually feel when the garbage collector kicks in. It totally throws me off. I have a bunch of optimizations set up, like running GC whenever I tab out of Emacs or am idle for 5 seconds, but sometimes I can still feel it. I hope Emacs makes some progress in this area -- I hear there's a Rust rewrite in the works :)
> If VSCode or any other text editor managed to provide a fast yet highly configurable editing experience without draining my laptop battery instantly
This is huge for me. I basically work by grabbing my laptop and sitting, standing, or laying wherever I feel like. I can't stand the idea of having an "office". So I'm acutely aware of when an application is running down my battery. Emacs is awesome in this regard because it has no noticeable energy usage, which boggles the mind when I think about how powerful it is as software. I honestly see no reason whatsoever to use anything else.
> I don't think these are trivial issues at all
I'm stunned that anyone would actually be OK with "a noticable latency between keypresses" in text-editors.
This might be still a thing if the whole desktop is streamed on a slow network but it shuld be completely unacceptable for normal text-editing.
(Unfortunatly I do have that problem sometimes with emacs (on cygwin) with c++-files that are too large. But I won't dismiss cygwin.)
"I’m a firm believer that we should understand how things work underneath the hood so that we can make the most effective use of at them. No program should rely on the particulars of the iterator object internals for correctness, but a well-written program should employ them in a way that best exploits their expected implementation."
I mean I could understand if this was an efficiency thing to do with scaling to large files due to a kind of a tiling memory model or something, but emacs doesn't even do that!
It's not a huge deal I've learned to get used to using Ctrl+U-Space to get back to where I was.
I read somewhere that somebody tried to implement what I'm talking about but never really got around to trying it cause it seems a little half-baked.
See this https://www.facebook.com/notes/daniel-colascione/buttery-smo...
“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.”
For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs.
Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs.
One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. The same could be said about Vim. In comparison to these two, newer editors sometimes appear too ephemeral and fragile to me. (Then again, I used to use BBedit on the Mac and just found out that it's still around! What a nice surprise!)
This latest emacs upgrade has been seamless and hasn't required any cognitive overhead to transition.
That said, I'll always be back to IntelliJ for heavy edits. There's nothing better for Java.
I find for less structured languages the less-structured approach engendered by emacs is an advantage.
The fact that TRAMP lets you open files on remote systems in and of itself is fairly mundane. What makes it really cool is that it works seamlessly also with dual-pane dired, and just about anything you do in Emacs. It turns remote filesystems into local ones.
Being able to, in my regular file manager (I like Sunrise Commander), treat any combination of remote and local filesystems as though they were local, is a huge productivity boost.
Not affiliated, just getting good use out of it.
BBEdit - launched in 1992 (26 years ago), still around.
Notepad++ - launched in 2003 (15 years ago), still around.
Textmate - launched in 2004 (14 years ago), still around.
Sublime - launched in 2008 (10 years ago), still around.
Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even more so Open Source ones have great survival characteristics.
That's why both Atom and VS Code seem like solid long term bets.
Clark Maurer still updates Slickedit at least annually though.
A bit of digging around:
Brief seems completely dead, was killed off by Borland.
Multiedit seems operational: http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product.
Semware is still technically "alive": http://www.semware.com/ It was last updated in 2005, so there's that :)
Slickedit: is definitely operational: https://www.slickedit.com/ I have no idea why you're counting it as dead?
Epsilon: seems operational http://www.lugaru.com/ They even had a release in 2018.
To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience.
Now, if a tool for developers reaches the mainstream, it super likely to stick.
I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...
>One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform.
You're ignoring the first half of the sentence:
BBEdit - not on Linux
Notepad++ - not cross platform
Textmate - not cross platform
Sublime - cross platform - but can I see the source? If not, I have little faith it will be around in 20 years.
My (heavily customized) Emacs environment on Windows gives me the same experience as in Linux. No warts at all.
There's even good native editors if you want that, Scite comes to mind.
Anyway, my point was just don't dismiss out of hand, don't belittle other people. Of course, if you're happy with Emacs, continue to be happy.
Oh, and the irony of this is me railing against Emacs/Vim when I'm also a Vim user and have been for at least 10 years. I say also because I've been using VS Code quite a bit lately.
Actually though pre-6.6 QNX had a great GUI and is capable of running on desktops and laptops just fine¹. I rather like it.
¹ Hardware support is not great but way better than you might be expecting. Either way, it runs fine in VMWare and VirtualBox. I'm currently trying to acquire some parts to build a PowerPC laptop for QNX.
I have not used one program til this day that is easier and more optimised for user customisation than Emacs. And if not much people will be using it in the future, be it so. But it will be around as long as computers with physical keyboards will be (and will probably adapt if they ever become obsolete).
Emacs allows you to look into and debug any function or variable, be it internal that shipped with its core, or one that you wrote.
The things you can customize in other editors and IDEs, you can customize through the M-x customize interface. The things you'd install as plugins, you can get from Emacs package manager. All other things that you can - with smaller or greater amount of work - alter in elisp, are more-less impossible in other editors.
Edit: Now I'm on the computer, I can link you to my init.el  so that you can skim and observe how much is configuration and how much is stuff that's possibly unique to my workflow. And how much is very useful stuff only possible in Emacs (one of my favourites is the URL routing stuff, at line 3674, something I inadvertently use tens of times a day).
The Leo editor comes close. Unfortunately, the documentation is a bit lacking. As is the UI - almost as bad as Emac's :-). The mailing list and developers are, in my experience, very helpful and in the short time I used it, they quickly created functions/commands for me when I asked "Hey, I can do it in Emacs - how can I do it in Leo?"
Moreover, you did not mention any of the things that make Emacs great. Its mode-based buffer-centric architecture comes from the Lisp Machines, maps well to countless disparate tasks and has certainly stood the test of time. Emacs is essentially the closest thing we have to a Lisp Machine.
Atom and VS Code on the other hand are ad-hoc editors on top of environments that can only be said to re-implement old, dead-end ideas and do so badly.
I'm not sure why you mentioned Gosling, if not to mislead, since he's never as far as I know been a Lisper (Mocklisp is a mockery of Lisp) and his contributions to GNU Emacs -- besides inspiring Stallman to come up with something better -- were minimal and very quickly rewritten or removed. Gosling's influence to the architecture (Lisp Machines, Symbolics) and evolution of GNU Emacs has been NIL.
Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs.
Emacs runs in a GUI. Emacs runs in a terminal. Emacs runs on a machine halfway across the world on the other side of an SSH session. The point goes to emacs.
Emacs is far from perfect, but it's far ahead of its competition.
Philosophically Lisp may be superior, but I'm not sure it's so clear cut in real life.
Regarding most of the features you present, a good chunk of them aren't editing features and another chunk are related to running in a limited environment (the terminal). So a big part of them aren't as strong selling points as you seem to think they are, since many people don't care about them.
There is also a huge difference between "building an extension" and "extending the actual code that is the running process." In Emacs, one can redefine one of its core functions at the push of a button, and suddenly all new calls will call your version of the function. If your redefined function has a breakpoint in it, you'll be able to debug-step into the core of the editor as it is running.
Not sure how well TypeScript in VS Code works in that regard.
IMO that's the best design: a solid, coherent design with clear extension points.
Of course, I'm the Anti-Emacs by saying this :)
VSCode has much better integration with the languages and toolchains that people are actually using in 2018 -- Node, Go, Rust. The point goes to VSCode.
VSCode has a modern UI that looks and works like the other applications people use every day. The point goes to VSCode.
With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too. So that one's a tie, I guess. Nobody except retrocomputing enthusiasts cares about terminals anymore; when kids today hear "terminal" they think of gnome-terminal (and some of them agitate to have it replaced with something that can present a richer experience than ANSI/VT100 can).
The sun has largely set on Emacs's relevance. Objectively better tools have come along.
The last time I checked on this very forum, Lisp people don't even consider scheme as a lisp. Only CL and Elisp came into their category of Lisp.
>>modern UI that looks and works like the other applications people use every day
The point about vi and emacs is not have that UI for the exact opposite reasons you state. Developer tools are not every day things like scissors or door handles. These are more like specialized tools, designed for one special purpose(Text editing).
Also this whole idea of putting beginner friendliness ahead of all design goals leads to tools that are very easy for beginners to work with but do nothing more than that.
The whole point about programming is to automate complex non trivial tasks.
>>Nobody except retrocomputing enthusiasts cares about terminals anymore
Wow! Just wow! Curious to know what you work on daily.
I thought even in this era front end programmers had a fair bit of exposure to the command line.
But if you are telling me only 'retrocomputing enthusiasts' care about the terminal, I have to wonder where these sort of programmers come from.
>>With a halfway decent GUI remoting protocol (e.g., RDP, PCoIP), you can run VSCode on machines halfway across the world too.
Actually no. But based on your thoughts about the terminal, I can see why you wrote that.
>>The sun has largely set on Emacs's relevance.
Emacs will never have the user share of something like Eclipse. But then eclipse won't have the life of Emacs either. These are tools aimed at different category of people.
Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things.
From : https://www.gnu.org/gnu/rms-lisp.en.html
I'm not saying vscode is less extensible or customizable though, I'm saying there's a barrier to ad-hoc personalization that's will keep it from ever being more easily customized (unless you and I have different definitions of what is "easily customized").
Script Commands is an interesting plugin that attempts to address this shortcoming, but I'd like to see something official at some point.
In atom, you can find packages on the website or in the dedicated search in the editor. Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.
Emacs is awesome, and currently more customizable than anything else. Tramp and Magit and Evil are best in class. But it's super difficult for a newbie to get started, and the windows compatibility is only so-so.
If you really want to just use code snippets to customize atom, you can! They have an init file for code changes, and a css file for style changes. There's even a website where you can find some of these little scripts: https://www.atom-tweaks.com/
In emacs though, I don't even need the internet to figure out how to customize things. C-h is all you need. There's a book bundled in, all functions and variables have amazing built in documentation. You can search for any binding, function or var by regex, go to their code, read their doc, redefine them at runtime.
The only place where Atom wins for me is in theming.
At the end of the day though, I had to go back to Emacs for performance and memory footprint reasons. Atom was just too slow, and used up too much memory.
Sure, and Emacs has this with MELPA (And Atom with... whatever they have). It's great paradigm and all editors should have it.
But I'm not talking about thousands of lines of copied elisp. I'm thinking about molding your editor to fit your needs. Here's an example:
We use hosted Gitlab at work. I like to highlight a line in my editor, call a command in the editor and get a URL for that line in that file in that branch on our internally hosted Gitlab server (with a custom path segment prefix). This is literally maybe ~40 lines lines of very compact elisp in a global configuration file. It would probably be less in JS because I'm better at JS than elisp. It's very specific to my circumstances and doesn't really need to be generalized to anyone else.
There are ~5 different plugins in the marketplace that purport to do this, but none of them fit my use case. Which is fine, I can do this myself...
However to do this vscode I have to create an extension, edit the package.json to register the command and few other things (this is tedious, believe me), re-read/remember the plugin API, re-read/remember how to build vsix files for production, install that plugin with the command line tools, reload vscode.
If I need to make a change, do it all again. But there is no reason that the Emacs behavior couldn't be included in vscode. And maybe some day it will. But the idea that not having it and claiming that is a _feature_ or (as others have done) claim that emacs is losing to vscode in configurability misses the multitude of use cases that emacs users have benefited from for decades.
As far as testing and code quality goes, I can't really argue with that but neither can vscode users? Do you know what all your plugins are doing in the background? All of these centralized plugin repositories are significant attack vectors. Which language do you think the first big own will be written in?
It's not my idea, it's the premise from
(I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)
The extensions I've generally used were quite solid, haven't had many problems with them.
I use Emacs as my daily driver. Your comment feels very much like from someone who hasn't realized the true powers of Emacs-Lisp. Even if someone doesn't hack in Elisp, once they discover power packages like Org mode or Magit, they will know right away that there's no competition for those out there (vim, Atom, VS Code, etc).
> For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs.
Even if that's the case, what's the point he's trying to make? Why? How does that matter to folks who are using Emacs today, and know it first hand that it's the best hackable text buffer engine out there?
You will end up stitching highly verbose pieces of code. Which is why Java IDEs have specific features to emit get/set functions etc.
Plus you will have to access a method hiding 5 class layers below. You will need IDEs designed to do this sort of work really well.
Emacs and Vi have been designed to largely play with Text, plus I think with Java's verbosity you are just better off with a specialized IDE.
> In computer programming, boilerplate code or boilerplate refers to sections of code that have to be included in many places with little or no alteration.
However, this graphics stuff is still bolted onto a core engine that treats everything as a text terminal.
If I remember, I'll send an email to the address on your resumue.
It's the best thing I've found for managing large numbers of buffers at once, though, and with things like acmego (go fmt + add missing imports on save) and Go guru integration (jump straight to function definition) it suits my needs pretty well.
Emacs has this too. You can look at a buffer from different windows, or clone-indirect-buffer in order to edit multiple parts of it simultaneously.
(clone-indirect-buffer-other-window) comes in handy
Notably C-s and C-r (incremental search forward/backward).
That in combination with C-space is the way to navigate in emacs like a pro :-)
(btw: its C-u C-space. C-u space inserts 4 whitespace)
Then again, Emacs is closer to a LISP toolkit for building text editors than it is a text editor, so I guess it's not so strange after all.
I wish we had a popular OS where the main UI toolkit was similar, i.e. it provided many hooks, a universal REPL and a nice interactive debugger.
I oscillate between them and vscode. I don’t use vim bindings in vscode though.
Plus, I like to have separate instances of emacs with different groups of files from separate but related projects. I end up with a zoo of buffers commingled in daemon mode. It just doesn't fit how I work.
I wish it had an image based startup scheme... freeze an image of emacs after init is done.
The net result for common iteration ops is quite nice, and has options for reasonable optimizations in the world of lisp where macros are real.
But certainly iteratees as an independent went out of fashion when conduit and pipes came on scene.
It works flawlessly. I just dropped it (26.1) in on top of my existing setup and had to do nothing else and I'm working away on it right now.
When I was downloading at least, I had to download it and the dependencies separately. The README says there should be a unified zip-file but it wasn't there at the time.
Had some issues with Windows 10 refusing to merge the directories from the deps package so had to drop to a cygwin shell but it actually worked quite well even without the deps.
"Error enabling Flyspell mode:
(aspell release 0.60 or greater is required)"
For the same reason, it's the usual thing in Lisps to break on a sentinel value (defaulting to EOF or similar) when reading sexprs from a file. In cases where nil isn't a valid element, you can always specify nil as the sentinel.
I have occasionally had to take over the controls for new emacs users while pair programming because the undo, while logical and consistent, doesn’t work as it does in other software. Each consecutive sequence of undo commands, once interrupted by any command that is not an undo is considered itself to be an atomic undoable change. This means that there is no need for a redo command, just stop undoing and the last undo sequence can be undone. Because emacs has a large undo limit you can keep undoing even past sequences of undos back to the original edit points of the file’s history.
That probably made no sense if you haven’t already mastered it, but another way to think of it is that edits and undos produce a branching tree of all the history of changes being made to the file. The entire tree of changes can be navigated with one command (undo) because that command makes a traversal of the tree, kind of like a post-order tree traversal. This is sufficiently confusing in practice that seeing the nanigation through the tree via the popular undo-tree emacs package helps a lot. I use the undo-tree command when I want to get to a version of the file not on the current main line of edits.
Not that Vim is any paragon of UX design. The point is that you can have a powerful undo system without breaking user expectations.
There is an undo-tree implementation for Emacs (based off of Vim), but the default undo described above isn't an undo-tree.
I'll try binding the undo keystroke to "undo-only", and a redo to normal undo definition, to see if I can get something approximating undo/redo semantics.
"The only downside to this more advanced yet simpler undo system is that it was inspired by Vim."
As typical in emacs, this is not the only undo behavior you can have. undo-tree behaves very similarly to vim by default, but still preserves the entire editing history (with branching), which is visible graphically with "C-x u".
A big advantage of emacs' tree-like undo is that you never lose any part of your history unlike a naive linear undo sequence. Like in this Firefox edit box for instance, if I type a word, undo it then type an other word I can't go back to the state I was in before I undid the first word. With Emacs I can usually restore any previous state my buffer was in (within the limits of the size of the undo buffer that is).
- Paste 5 time the same line
- Press undo 3 times: removes 3 lines
- Move the cursor by one character
- Press undo 2 times: instead of removing 2 lines it adds back 2
It would be better if the two operations (undo/redo) would be distinct.
E.g. SQL dumps and such.
Emacs' redisplay algorithm is not very efficient if you have very long lines. On the other had on old emacs versions (before 23 IIRC) this was significantly worse as it also had weird UX implications (C-p/C-n working in terms of logical, as opposed to displayed, lines and unability to sanely display lines that are longer than width*height of window).
Other problem is that the gap-buffer data structure is very suboptimal when you start to move the point by multi-MB offsets (which in emacs' case imcludes operations like scrolling to the other end of buffer using scrollbar) as it involves doing memmove() of this multi-MB block of memory.
I might use it more if we weren’t stuck in an old version of rhel at work.
For me, the only thing emacs has going for it are the plugins. If I could get the plugins I use in VSCode I'd never look back. Mainly this comes down to CIDER. But a lot of people have put person-years of work into cider. And it's hard to imagine them embracing vscode.
Rather than porting plugins or making an elisp interpreter, if I were passionate enough about it, I would look for a path to being able to run a bridge (as a vscode plugin) to a headless emacs.
I have no clue how that would be done, but If I chose to believe it was possible, I would try to write an network based API to emacs as an elisp plugin to start, enabling other front ends as neovim does.