Making Emacs popular again
The Emacs editor predates Linux, and was once far more popular, but it has fallen into relative obscurity over the years. In a mega-thread on the emacs-devel mailing list, participants discussed various ideas for making Emacs more "attractive", in both aesthetic and in "appealing to more users" senses of that term. Any improvements to Emacs in that regard have numerous hurdles to overcome, however. There are technical questions and, naturally, licensing considerations, but there is also the philosophical question of what it is, exactly, that stops the venerable text editor from being more popular.
So square
The discussion started with post
from "ndame" asking why Emacs is "so square
"; the appearance
of things like buttons could be improved with rounded corners, they said.
Richard Stallman, one of the original authors of Emacs, seemed somewhat
dismissive in his reply:
"Perhaps we should implement a mode that puts cosmetics on Emacs
so it will appeal to those who judge by the surface of things.
"
But Stefan Kangas thought
there was more to it than that:
I also don't know that it's helpful to assume that the rest of the world will take the enlightened stance. For example, I've always assumed that many people use Sublime Text not due to any serious feature comparison with Emacs, but because they like its "sleek look".
He wondered if there was "any reason not to improve the default
look
". Stallman said that
there are some technical barriers in finding someone interested in and capable
of doing the work needed, but there is an overarching problem that
needs to be addressed first:
Stallman did agree that the graphical design could improve usability,
"but I have a feeling that the changes
that would help are deeper issues than the shape of corners
". The
GUI interface only matters if Emacs users are leaving those features
(e.g. the menu bar and tool bar) enabled, Eli Zaretskii said, but much of the
advice out there on configuring Emacs suggests disabling those things.
Beyond that, though, there are bigger problems with Emacs as a whole,
Joseph Garvin said.
The Emacs user interface "doesn't look or behave like any other
application
", the keyboard shortcuts are different than other
programs, and the terminology used in the Emacs world does not match with
what users expect:
You are basically making a commitment to being or becoming a power user. I certainly would not have put up with it if I didn't think it was going to save me a lot of time as a software developer (and it does, everyday). I doubt anyone invests the mental effort to deal with learning emacs nowadays unless this is their goal. If you just want to do "casual" text editing emacs is a very weird choice in 2020.
But "modernizing" Emacs (however defined) is likely to be a waste of the
project's time, since its look is not what's holding it back, Ahmed
Khanzada said. For
example:
"Terminal-based Vim is not like a modern application, yet is more
popular than Emacs.
" The appeal of an editor that can be extended
using the Lisp language is somewhat limited, he said. Spending a bunch of
time and energy to give it a modern look would not change that and, by the
time the work was done, the definition of "modern" will have changed again.
Popularity
Kangas wondered about the assertion of Vim's popularity; Khanzada pointed to a 2019 survey that showed Vim with a substantial lead over Emacs (20% to 3% is what he reported, though it shows 25% to 4% as of this writing). That survey showed that Visual Studio Code (VSC) is the clear winner, however, with 50+% of respondents using that tool. You could perhaps quibble with the survey's methodology, but the broad-brush numbers do not seem wildly out of line.
That set off some discussion of why users prefer the experience with
VSC. "We need to figure out why VSC is so popular, and then
fill in the areas that Emacs is missing
", Po Lu said. Bob Newell
thought
that "the goal
of making Emacs more accessible and more appealing is laudable and
ambitious
"; it is something that the project could accomplish, he
said. He is worried, though, that today's software is aimed at "instant
gratification" rather than long-term usability—and power.
Stallman agreed with that sentiment. But he would also like to see Emacs return to popularity as an editor of text for publication. Several noted that Org mode is already being used successfully for text-publication purposes. That mode is not familiar to Stallman and he was unable to learn much about using it for word processing by reading the documentation. Zaretskii pointed out that there is a high barrier to learning Org mode from its documentation, at least for the word-processing use case.
Once again, though, it seems quite unlikely
that some putative, well-documented word-processing Emacs mode is likely to have users
flocking to the editor. But Stallman said that
the user profile for Emacs was much broader 30 years ago; he would like to
see it be that way again. He personally does not see rounded corners as part
of that, though he is not opposed to efforts in that direction; "[...] if you want
to attract more users to Emacs, I think there are more important
areas for improvement.
" Lu had some ideas along
those lines, for example using starter kits (or
packs) to help make the editor "more friendly to newcomers
".
There was a difference of opinion about making changes to the defaults,
though, in order to help newcomers. If changes need to be made for the sake
of newcomers, ndame said,
established users can just turn them off. For example, Cua Mode, which adds the
"standard" keybindings for things like cut and paste (i.e. ctrl-c, ctrl-x,
ctrl-v) to Emacs, should be on by default; "it could
make the life of new users easier if they didn't have to turn it on explicitly
and they could use their copy/paste keys from the start like they are used it to
in other tools
".
But Lu suggested adding a button for newcomers to turn on those features from the splash screen instead. Better still might be for Emacs to recognize a possible newcomer, ndame suggested:
And if the user says no then everything is as usual.
There was some discussion of gathering feedback before deciding to change defaults and such, but Dmitry Gutov wondered if existing users are even relevant. If expanding the reach of Emacs is the goal, it may make sense to look at the problem differently:
And it's not like existing, long-time users can't grow to like the new defaults (even after a certain amount of grumbling).
Lu disagreed;
"We should prioritize existing users over hypothetical users that
don't
even exist yet.
" But Gutov said
that might be shortsighted; "I don't want Emacs to die out, and it will if we don't do the work of
attracting new users.
" No real conclusion was reached; everyone
would like to see the number of Emacs users (developers, testers,
documentation writers, ...) grow, but how to do so is unclear at best.
Licensing
Back to rounded corners, Zaretskii said that the only thing
standing in the way of that was code to implement it; "[...] patches to add
such capabilities to Emacs are most welcome
". But Emacs is
multi-platform, Gutov said,
which means that buttons look different on each. Even on the same
platform, different graphics toolkits give different looks—and the looks
change between toolkit releases.
Alex Bennée suggested that
"unifying under a single cross-platform toolkit like GTK+
"
would avoid some parts of the problem, but he also noted that a longstanding
bug in GTK+
had caused him to use Emacs with the Lucid toolkit instead. He also
worried about the next generation: "I've been thinking about text editors for my
children to use as they graduate from point and click programming to
proper text and even I'm not sure I want their first experience to be
Emacs.
"
Zaretskii pointed out
that GTK+ is not really cross-platform. In addition, the bug in question is
not considered to be one by the GNOME developers, which led Ulrich Mueller
to muse about a
switch to Qt. But Stallman was quick to put the kibosh on that; Qt is only
available for GPL 2 and 3, using it would mean that if there is a
GPL 4 someday, Emacs could not switch to it. "So we must avoid
using Qt.
"
Electron was also raised
as a possibility, but it turns out to have "freedom issues
",
Lu said. It is not
clear how serious any of these ideas were; switching graphics toolkits is
a decidedly non-trivial undertaking. It does seem like an indication that
some in the Emacs development community are getting frustrated with the
GUI version(s) of the editor. Beyond that, many of the Emacs developers do
not even use the GTK+ version because of the bug, which leads to less
interest in improving that version of Emacs; it all seems to be something of a mess.
The icons used by Emacs were also questioned in the thread, with licensing
rearing its head there as well. The Emacs subreddit is apparently
fertile ground for thoughts and suggestions as it came up a few times in
the thread. For example, ndame reported
"that a user posted a screenshot of an emacs
toolbar with really sad looking icons at the end
". There are icon
sets available under the GPL that could be used instead, they asserted.
But Zaretskii cautioned that things
may not be that clear-cut:
Several icon sets were suggested, including GNOME icons, some from Wikimedia, and those from KDE, all of which are available under various free licenses (GPL, Creative Commons, LGPL). But there is more work to do than just identifying candidates, Zaretskii said:
Alternatively, someone could create our own icons, in which case they could be even prettier than the ones pointed out here.
In any case, this is a non-trivial job, and volunteers are most welcome to do it. I don't think anyone is happy about the icons shown on the tool bar by Message mode; the only reason we use them is that we couldn't find better ones that are free and suitable for inclusion in Emacs.
But, ndame asked,
shouldn't
icons that come from GNOME, a longstanding free-software project, be
perfectly acceptable to use in Emacs? Sadly, it is not so easy as that,
Zaretskii said:
"IANAL, but I think it has to be GPL v2+ at least. And perhaps we
would also need the copyright assigned to the FSF.
" For example,
the Wikimedia icons are available under the the LGPLv3 and Creative Commons
Attribution-ShareAlike (CC BY-SA) 3.0 licenses, but neither of those would work for
pieces that are part of the Emacs program, Stallman said.
Without the "or later" on the LGPL grant, the Qt problem would exist; CC
BY-SA 3.0 "is incompatible with every version of the
GPL
". But that may not matter in the end:
The Emacs distribution contains many works, including textual, art, and small programs, which are distinct from the program, Emacs.
Zaretskii and Stallman were able to determine that icons for Emacs fall into that category, so they simply need to be available under any free license, which should simplify things—if someone gets the time and energy to work on the problem. Like most projects, Emacs suffers from a shortage of human power; a project to improve the GUI that may not be widely used by those developers could go wanting. And that, in a lot of ways, sums up the situation with the editor project.
Moving forward
Emacs is quite useful for its adherents; many of them see it is their main interface to their computers. Others use it regularly but less universally. There are even longtime Vim users (who may have started on vi, in truth) that need Emacs for certain tasks—me for example. It serves all of these users well, but does it really still have a role in ten, twenty, or forty years? It is not an easy question to answer, of course; certainly it will still be with us in both ten and twenty years, but how many users will it have in forty?
Part of the problem is that the dedicated following for Emacs is also pretty resistant to change to any major degree. That's not meant as a knock of any sort, simply an observation. There are plenty of examples in that huge thread of ideas that were seemingly shot down because they represent change that might upset existing users. But it would seem that some changes of some sort are needed to bring in new blood. If few or no new users are coming in and nothing is done to attract more, it can only lead to eventual extinction.
Hopefully that is not the path that Emacs is on—or if it is, that it changes direction before (too) long. It is one of the earliest free-software programs in existence; pre-dating the term "free software" by nearly a decade, in fact. Of course, the code itself need never disappear entirely, but a vibrant—growing—Emacs community would be wonderful to see.
In truth, we have barely scratched the surface of that mega-thread. There are plenty of sub-threads that went completely unmentioned here; those interested in Emacs development—warts and all—will find plenty to read and digest there. Whether Emacs ends up with rounded corners or not seems like simply the tip of the iceberg of things that might need to be addressed to make Emacs more newcomer-friendly. How that can happen within that community remains to be seen.
Posted May 6, 2020 22:39 UTC (Wed)
by jgg (subscriber, #55211)
[Link] (7 responses)
The C mode in VS Code is ridiculously better than emacs. Emacs shot itself in the foot by both not allowing GCC's font end to be useful and refusing to use clang's useful front end, both for philosophical reasons. Without this part it is just hopeless.
My biggest sadness with VS Code is that the key language server part of the C mode is not open source, and has many annoying defects :( Also other things like bad interaction with X11, lack of customizability of the mouse bindings, and remarkably, failure to support multi-monitor, make it pretty hard to like. But the language server is fantastic..
Add in the VSC Remote extension (tramp is total garbage in comparison) plus VSC Live Share and you really have something quite unique and useful.
Suggesting fiddling with the emacs GUI really misses the whole point of why VS Code is so popular right now.. I think if you wrote Emacs in HTML/CSS/JavaScript you'd probably end up quite close to VS Code. ie it is the original dream of emacs pulled out of the 1980's and recast in a Web 2.0 world that is familiar to a huge developer base.
Frankly I find it complete nonsense to be using an editor in a web browser on an interpreted language, but you know what? People said the same of emacs in the '80s and '90s...
Posted May 7, 2020 4:41 UTC (Thu)
by kastauyra (subscriber, #110760)
[Link] (2 responses)
For me, LSP is what makes Emacs viable in 2020. The C++ tooling state before LSP was pretty sad - cc-mode using regexps to "parse" C++ can get you only so far, and I was never able to get CEDET to work.
Posted May 7, 2020 23:48 UTC (Thu)
by jgg (subscriber, #55211)
[Link]
But this is kind of my point - *emacs* is not relevant any more because major stuff like really good LSP support is just not part of the main project's concern.
Now I want to find time to try vsc-clangd..
Posted May 14, 2020 13:01 UTC (Thu)
by dfszb (guest, #138896)
[Link]
Posted May 7, 2020 7:42 UTC (Thu)
by wIvE4lF2GnJ1BFb (guest, #131745)
[Link]
I use it on any project that has a proper build system like Meson or CMake, that write a compile_commands.json in their build directory, which you can tell clangd to read so it knows exactly how each file is compiled and has all of the insights that the compiler also has.
clangd is packaged in most distros by now, since clang 7 or 8 it has gotten very good.
Posted May 7, 2020 10:28 UTC (Thu)
by ber (subscriber, #2142)
[Link] (1 responses)
To me if something is completely available as Free Software, is an important indicator and both a safeguard to make a software future proof. Thus https://github.com/VSCodium/vscodium (an initiative to rebuild VSCode) is very interesting and what we recommend at the workplace to people that like this editor.
(Thanks LWN for the article and you all for the nice discussion (except the two comments born out of frustration from my point of view).)
Posted May 7, 2020 18:09 UTC (Thu)
by jsmith45 (guest, #125263)
[Link]
Of course, one could use a different C LSP implementation, but that extension would not be designed for configuring and launching some other LSP server, so ideally you would want to use some other extension designed around the other LSP.
Posted May 9, 2020 19:46 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Can VS do something like magit over tramp? That's the killer Emacs feature for me. Like most things Emacs it isn't "good looking" but I have seen nothing ever come close functionally.
Posted May 6, 2020 22:49 UTC (Wed)
by tchernobog (guest, #73595)
[Link] (13 responses)
Many developers are already familiar with those in their daily projects. eLisp is not something you want to get your hands dirty in 2020 as a fresh college graduate / young professional.
Not to mention all the long-standing issues (e.g. lack of multithreading which makes the UI block). There was at least an attempt to move to GNU Guile, but I am unsure it went anywhere.
But the amount and quality of extensions (especially language server integration) available with one click in VSCode are the clear winner for me, rather than the keymaps, icons, or rounded corners.
Posted May 6, 2020 23:23 UTC (Wed)
by wblew (subscriber, #39088)
[Link]
With emacs, I just never got into all those control key combos. Maybe it was a learning curve thing.
Posted May 7, 2020 1:15 UTC (Thu)
by dvdeug (guest, #10998)
[Link] (9 responses)
Posted May 7, 2020 11:58 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (5 responses)
All in all, if someone is going to do it, they need an ego of a superhuman to power through the giant valley of despair... and usually those people find other things to work on.
Posted May 8, 2020 2:56 UTC (Fri)
by tome (subscriber, #3171)
[Link]
A couple years ago I think Andy Wingo had gotten guile to the point where it could interpret emacs lisp. So the great mass of emacs functionality, including extensions, implemented in elisp, would run with guile swapped in as the implementation. There was no longer a need for a complete rewrite of all that elisp code. People who prefer to do so could write new packages in scheme and take advantage of guile's greater speed and capabilities. It came down to some remaining issues in the C code of emacs. I thought it sounded feasible, but I could be wrong. Can someone tell me what's untrue about that scenario?
Posted May 8, 2020 4:18 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
Readable Lisp S-expressions seem like they would be much easier to implement and maintain, wouldn't they? https://readable.sourceforge.io/
Posted May 10, 2020 5:14 UTC (Sun)
by milesrout (subscriber, #126894)
[Link] (1 responses)
Posted May 10, 2020 15:18 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Thanks for your personal impression but please have a look at the reference.
Posted May 10, 2020 19:03 UTC (Sun)
by jem (subscriber, #24231)
[Link]
The specification also adds "meaningful indentation" à la Python (and Haskell), with all the cumbersome interaction between tabs and spaces, and problems with copy-pasting code.
My fix to the readability problem is to indent the code properly, and split the code into separate functions as appropriate. Use an editor which does the indentation automatically, shows matching parentheses, and warns about the "silly extraneous" parentheses. It doesn't really matter if a Lisp function ends with 13 closing parentheses, as long as they are all there. You don't have to count them.
Now, if I could only think of an editor that is up to the task...
Posted May 7, 2020 12:17 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (1 responses)
Honestly, Emacs would probably be in a better place if RMS didn't have any say.
Posted May 11, 2020 19:47 UTC (Mon)
by tnoo (subscriber, #20427)
[Link]
Emacs is his baby, and he cared for it his whole life. And he still does: I had a reproducible crash a few years ago. It took one hour for him to send me a first patch that fixed the bug. And after one day of discussion on the mailing list the root cause was found and fixed. No vendor does that.
For me, the amazing thing is that emacs got a lot more momentum thanks to great tools like org-mode, magit, ivy/avy/helm, pdftools, org-ref that were not around ten years ago.
Posted May 25, 2020 17:00 UTC (Mon)
by moltonel (guest, #45207)
[Link]
Posted May 12, 2020 1:15 UTC (Tue)
by briangordon (guest, #135428)
[Link] (1 responses)
Posted May 12, 2020 2:53 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
(I prefer IntelliJ editors, they are unmatched in their semantic editing support)
Posted May 6, 2020 23:18 UTC (Wed)
by jkowing (subscriber, #5172)
[Link] (1 responses)
* My Second Comment
Posted May 7, 2020 0:23 UTC (Thu)
by felixfix (subscriber, #242)
[Link]
Posted May 6, 2020 23:40 UTC (Wed)
by JohnVonNeumann (guest, #131609)
[Link] (9 responses)
"That set off some discussion of why users prefer the experience with VSC. "We need to figure out why VSC is so popular, and then fill in the areas that Emacs is missing", Po Lu said. Bob Newell thought that "the goal of making Emacs more accessible and more appealing is laudable and ambitious"; it is something that the project could accomplish, he said. He is worried, though, that today's software is aimed at "instant gratification" rather than long-term usability—and power."
I read "The Pragmatic Programmer" before I got into technology, so I came in with a fairly "craft" view of tooling, and for my age and time in industry, my opinion is not a common one that a programmer is a craftsperson that should choose their tools wisely and work with them to learn them and get better. I regularly have to fend off my choice in the workplace to use Vim. For the most part I've stopped having the discussion though.
Even then, I'm a pretty massive vim fanboy and even I have found myself moving away from it for certain things just due to the head aches it can provide doing development in modern programming environments with Python and the like, having to manage combination of LSP servers with python versions and it's own environment, then a version for vim to support python code completion is an absolute pain.
I appreciate that I've talked mostly about Vim, but for the most part I think emacs and vim are in the same boat.
Posted May 7, 2020 10:38 UTC (Thu)
by daniels (subscriber, #16193)
[Link] (8 responses)
Where on earth did this meme come from? Modern web and networked-service development relies on a huge constellation of tools - much more so than 'traditional' C development. Those tools do change and evolve rapidly, yes, but that happens in response to different needs and uses. If you're making the argument that they're wrong, well, they're not the ones having an existential 'is our project still viable?' debate.
Posted May 7, 2020 17:17 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
It's just sour grapes. People have been denigrating the popular for as long as "the popular" has been a thing.
Posted May 7, 2020 17:48 UTC (Thu)
by hkario (subscriber, #94864)
[Link] (4 responses)
Posted May 7, 2020 18:04 UTC (Thu)
by daniels (subscriber, #16193)
[Link]
Perhaps the number of frameworks/libraries and the velocity of their development within the web world is reflective of the vibrancy of their ecosystem, and the willingness to try out new strategies rather than open-coding string-handling routines. But I don't see a correlation between framework popularity ebbing and flowing, and the care and investment put into them during their development.
I don't think 'literally everything gets thrown away every week' is even accurate, if you actually look at the shelf life of frameworks like Rails (est. 2005), Django (also 2005), jQuery (2006), Dojo (2004), etc. The editor that arguably did the most to displace Emacs - Sublime Text - dates back to 2008.
Maybe that kind of careless 'these fools don't even know what they want' stereotyping doesn't mean that Emacs developers 'care more' about their tools, but are instead endangering the project, because its continued relevance and practical usefulness to developers is less important than projecting feelings of superiority over the internet.
Posted May 7, 2020 19:01 UTC (Thu)
by beagnach (guest, #32987)
[Link] (1 responses)
I see this kind of snarky comment from people who regard themselves as "real" programmers but who haven't actually bothered to try work with a real JS project of any size.
The problem JS frameworks are addressing is a very hard one - much harder than something like Django or Symphony has to solve. Progress has been, and continues to be, incremental, but rapid. Each new generation has learned from the previous and brought very real improvements in usability and expressiveness.
If you haven't attempted to work with front-end web application at scale it's easy to vastly underestimate the difficulty of creating a well-structured system with good separation of concerns, reusable components and so forth.
Posted May 12, 2020 18:32 UTC (Tue)
by sjatkins (guest, #138806)
[Link]
Posted May 8, 2020 14:58 UTC (Fri)
by thoughtpolice (subscriber, #87455)
[Link]
Posted Jul 14, 2020 22:25 UTC (Tue)
by ceplm (subscriber, #41334)
[Link] (1 responses)
And yet, vim is still the most popular editor for programmers, isn’t it?
Posted Nov 7, 2021 11:07 UTC (Sun)
by CRConrad (guest, #11471)
[Link]
I think that strongly depends upon whether you define "most popular" as "most beloved" or "most used".
My guess Vim is "the most popular editor for programmers" in the latter sense, because vim is installed as default on pretty much every single Linux system where developers have to occasionally edit git messages, config files, or shell scripts; but that doesn't necessarily imply the former.
Posted May 6, 2020 23:56 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (14 responses)
Can anyone clarify if this is accurate?
Posted May 7, 2020 1:45 UTC (Thu)
by mohg (guest, #114025)
[Link] (11 responses)
I think that, although this abort was originally added to Emacs because of a GTK+ issue, in recent years other issues have been triggering the same abort. For example, the comments about Emacs aborting when certain unicode characters are inserted relate to a different problem. I can sympathize with GTK developers getting frustrated when people add unrelated Emacs crashes to their bug reports.
I can also sympathize with them wanting a minimal test case. Looks like someone provided one at
I'm not sure it's helpful for Emacs to print another project's bug URL in its abort message. Perhaps the comment should be removed, especially since other things can trigger it.
Posted May 7, 2020 2:12 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (10 responses)
Posted May 7, 2020 7:54 UTC (Thu)
by mina86 (guest, #68442)
[Link] (9 responses)
Posted May 7, 2020 8:21 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (8 responses)
I've had that happen to me on Fedora by downloading a .iso in /tmp. Fedora mounts /tmp on tmpfs, so the RAM got filled, so the OOMKiller triggered and killed gnome and everything I had open along with it.
Posted May 7, 2020 12:40 UTC (Thu)
by ebassi (subscriber, #54855)
[Link] (7 responses)
When it crashes it kills the entire session. Just like when the X server crashes, as the compositor in Wayland is also the display server. Ideally, we GTK developers would like to allow clients to survive a display connection closure—and Wayland makes it easier than X11, given that all objects are client side and do not asynchronously disappear when the display connection is closed. Sadly, it's still not entirely trivial to achieve; there are more pressing things to do than addressing niche use cases; and this still does not address the issue of Emacs closing display connections at random and expecting things to survive.
Posted May 7, 2020 12:49 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
https://arcan-fe.com/2017/12/24/crash-resilient-wayland-c...
Posted May 7, 2020 13:20 UTC (Thu)
by Baughn (subscriber, #124425)
[Link] (5 responses)
Posted May 7, 2020 14:30 UTC (Thu)
by ebassi (subscriber, #54855)
[Link] (4 responses)
Compositor crashes are not niche Compositor crashes are bugs, not a feature. Bugs ought to be fixed, and compositors should not crash, considering that they are privileged components. Additionally, terminating the connection should not crash a toolkit, but you should not expect that your application wait for a display reconnection and restart as if nothing happened either. The only safe thing to do is to save local state and terminate.
Posted May 8, 2020 2:15 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted May 8, 2020 22:48 UTC (Fri)
by roc (subscriber, #30627)
[Link] (2 responses)
Therefore your software should not lose data during those events either, and if that's true then a compositor crash likewise doesn't matter.
Posted May 10, 2020 8:14 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted May 13, 2020 8:53 UTC (Wed)
by roc (subscriber, #30627)
[Link]
Posted May 7, 2020 8:43 UTC (Thu)
by vejeta (subscriber, #138096)
[Link]
I searched the list, and found a mention here:
It seems there is a warning that mentions it when compiling emacs, however I don't see a reference to it where this discussion took place.
Posted May 7, 2020 12:52 UTC (Thu)
by ebassi (subscriber, #54855)
[Link]
Can anyone clarify if this is accurate? As the person who wrote the comment you're linking: yes, this is still accurate to the best of my knowledge. Emacs is specifically calling
Posted May 6, 2020 23:59 UTC (Wed)
by noahm (subscriber, #40155)
[Link] (3 responses)
I'm one of those weirdos who's just about equally happy in emacs and vim. I also spent some time trying to switch to vscode for Go development in the past year. I switched back from VSC to emacs, though, and I'm happier for it. The multi-language support in emacs is better than VSC, so although it doesn't have quite as many UI features, it is more consistent across languages. I suspect that this is simply a matter of maturity, though, and I think VSC will catch up very soon, if it hasn't already.
My concern with efforts like this is that they'll add a lot of complexity, change a lot of things that annoy (even just a little bit) existing users, and still fail to attract new people. It's hard to overcome perceptions, and Emacs has developed a reputation as being weird and old, and it doesn't have any attractive enough features to overcome that for a lot of new users.
I think these days a lot of "new" users aren't even expecting to use a native application for general text editing. The browser has become the default interface to general purpose computing, much the way emacs was the default interface for a lot of people 30 years ago. So even if emacs does attract a larger share of the subset of people who want to edit text in an application running on their computer, even that group is shrinking.
Posted May 7, 2020 1:03 UTC (Thu)
by nkiesel (guest, #11748)
[Link]
I used to recommend Emacs to every junior developer, but lately shifted saying “I personally use Emacs for everything but Java/Kotlin and its great, but you might instead consider using VSCode these days because most language support is much better”.
Posted May 8, 2020 0:32 UTC (Fri)
by smitty_one_each (subscriber, #28989)
[Link]
I'm one who physically cannot take the left-hand abuse of emacs key chords. Just rips my left arm off. On the other hand, https://www.spacemacs.org/ is just awesome, locally or in the cloud over SSH.
Taking the time to convert to modal editing via https://vimvalley.com/ was worth the cost. When you can log in and get the work done with bare vi, you have instant cred on the job.
Magit and org-mode seal the deal, whereas all this icon talk is of no real importance to me, sorry.
Posted May 12, 2020 4:21 UTC (Tue)
by filbranden (guest, #87848)
[Link]
Haha, my thoughts exactly. And I'm happy to see how you also caught the "subtle" reference in the adjective on the thread.
That, together with one of the main characters in the story last having made the news under the #MeToo hashtag, and the introduction of that character being followed by a discussion on license pedantry made for an article I could almost have expected to find on a tabloid rather than LWN :-)
Surely a fun read though... And the comments too!
Posted May 7, 2020 1:03 UTC (Thu)
by josh (subscriber, #17465)
[Link] (3 responses)
> Richard Stallman, one of the original authors of Emacs, seemed somewhat dismissive
One wonders just what could possibly be holding the editor back.
I used to follow the Emacs development list, back when I used Emacs as my primary editor. (I still use Emacs for TeX, using AuCTeX, but for everything else I now use vim. One of these days I need to learn vim-latexsuite.)
Any attempt to do anything outside the norm, especially improvements focused on new users, usability, or more integration of powerful features, was met with derision, contempt, and elitism that has no place in any modern project, most of it from the same few people.
(To clarify something: I'm not talking about changes that would break things for experienced Emacs users. I'm talking about changes that would leave experienced Emacs users unaffected, and improve usability for new users.)
That's leaving aside the copyright assignment problem; I've seen perfectly reasonable GPL-licensed code, code that many developers wanted to include, rejected out of hand because the FSF didn't own the copyright. I've even seen demands to refuse to *mention* such code, lest people be able to find it. (One excellent example: Magit, a popular interface to git.)
Emacs is an incredible tool, and its extensibility and programmability are incredible. In my opinion, the biggest thing holding it back is a small handful of unwelcoming elitist developers in its community, and the second biggest thing is the FSF's copyright assignment policy.
Posted May 7, 2020 1:52 UTC (Thu)
by mohg (guest, #114025)
[Link] (2 responses)
I don't think the copyright assignment issue is something that needs to be reported anecdotally. It is the stated policy for GNU Emacs. There is some rationale for it at
https://www.gnu.org/licenses/why-assign.en.html
which of course not everyone agrees with. Many GNU projects don't have this requirement. I suspect many Emacs developers would be happy without this policy, but don't feel strongly enough to make a serious challenge to the status quo (or fork).
> I've even seen demands to refuse to *mention* such code
I've only ever seen Richard Stallman say this. I find it a strange position for him to take, and have never seen anyone agree with it.
I'm not sure these are the issues "holding Emacs back" (if anything is). XEmacs had no copyright assignment requirement, and it died.
Posted May 7, 2020 2:36 UTC (Thu)
by cmonsanto (subscriber, #96651)
[Link]
The copyright assignment policy contributes to the pointless ELPA vs MELPA schism. For those unfamiliar with Emacs, MELPA is where the majority of Emacs packages live. It should be usable by default.
You couldn't pay companies to incorporate Emacs' source in their non-free products. Nobody cares. This is a complete own goal.
Posted May 8, 2020 3:11 UTC (Fri)
by val314159 (guest, #138703)
[Link]
Seems history is on the side of the users if someone supports them.
as a case in point in modernity, ELisp used dynamic bindings until very recently and I have never seen another lisp system that does that since the 1980s.
another side note, explaining why "frames" are "windows" and "buffers" and "files" makes EVERYONE'S eyes glaze over.
Posted May 7, 2020 2:05 UTC (Thu)
by ttuttle (subscriber, #51118)
[Link] (5 responses)
Posted May 7, 2020 2:30 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted May 7, 2020 23:28 UTC (Thu)
by flussence (guest, #85566)
[Link] (2 responses)
The resulting project will obviously have to be named something else to avoid RMS's signature tantrums, but that's a baggage a lot of people would probably be glad to be rid of. Posted May 8, 2020 16:09 UTC (Fri)
by Nelson (subscriber, #21712)
[Link]
There was some very interesting progress on remacs for a while there. I know you can't just add these efforts together but there is clearly some energy to take emacs in to new directions.
To the original point, I think if there were some forks and some of the passions were followed with some of these other things it seems possible that some new things would be builtin on an 'emacs' that could breath new life in to emacs.
Posted May 7, 2020 2:35 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (6 responses)
https://thenextweb.com/dd/2020/05/06/github-codespace-let...
It seems pointless to try to make Emacs popular in a world where proprietary software running in web browsers has replaced locally installed software. Even if Emacs were ported to WebAssembly or asm.js, who is going to run it in their browser instead of the default GitHub IDE and how are they going to convince GitHub host Emacs on their servers?
Posted May 7, 2020 4:56 UTC (Thu)
by thumperward (guest, #34368)
[Link] (4 responses)
It's absolutely natural that the most popular IDE is essentially a reimagination of Emacs for the 21st century. It's ironic of course that it's a Microsoft product, but it demonstrates that Microsoft are far bolder and more willing to experiment (by creating, and giving away, a free competitor to their own IDE, which was a former market leader) than the infamously hidebound Emacs development community.
The comments here are little better than in the mailing list thread, and for the same reason. I'm pushing 40 (and yet I'm a "millenial" as much as the term ever had a specific meaning) and I've been happily using Atom (another Electron-based, Javascript-extensible free software IDE) for years. VSCode appears to have all the momentum, so I'm preparing to switch to it. That's going to require a bit of retraining, but nothing that goes beyond the inevitable requirement to continually learn and re-learn technology that comes with working in this industry. And I am _well_ below the median age for an LWN commenter, let alone an Emacs user. It's gotten to the point where the proud greybeards are literally all reaching retirement age, and most of them have stubbornly resisted making any alterations to their lifestyle or world view since the dotcom boom. Hell, the infamous Lucid Emacs schism was nearly thirty years ago now, and on the Emacs side it's still _exactly the same people_ acting in exactly the same manner. There will only be another couple of rounds of this masturbation disguised as retrospection before there is nobody left in this group to carry the fight forward.
As a final footnote, it's remarkable that seemingly nobody has pointed out that it is far easier to add Emacs-like features to a modern editor than it is to drag Emacs out of the 70s. This is practically the first thing that gets written for any new editor. And yet the other camp has been bloviating for decades about the philosophical utility of having working scrollbars.
Posted May 7, 2020 9:51 UTC (Thu)
by burki99 (subscriber, #17149)
[Link]
IT shows similar patterns: COBOL, Fortran and Emacs don't get replaced once something better appears, but when an older generation retires and the infrastructure and tools they built up get (very slowly) replaced with the stuff the next generation grew up with. Usually, the time to learn and the mental change needed to move from what we got comfortable with to something different is just too high unless a new project or position forces us to into such a change. This resistance to change is also one of the main reasons for the never ending language wars and debates about init systems.
Posted May 7, 2020 11:35 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
You entirely missed one crucial difference:
Microsoft has a legion of programmers they can (and do) order to work on things, and the budget to make that happen, as well as an enormous captive developer audience due to platform lock-in. Not to mention a couple of decades of questionably-legal shenanigans.
Emacs has never had any of that.
Posted May 7, 2020 12:30 UTC (Thu)
by burki99 (subscriber, #17149)
[Link] (1 responses)
Microsoft has a legion of programmers they can (and do) order to work on things, and the budget to make that happen, as well as an enormous captive developer audience due to platform lock-in. Not to mention a couple of decades of questionably-legal shenanigans.
while completely true could be stated exactly the same for the comparison for Linux and Windows. But there the outcome is rather different than what we observe in Emacs vs. VSC. So you can't only focus on Microsoft, you also have to take a look at the development community of Emacs.
Posted May 7, 2020 13:06 UTC (Thu)
by pizza (subscriber, #46)
[Link]
So, how has "Linux" used its desktop-monopoly-funded profits to enter new markets with loss-leaders, many times over?
Microsoft has probably spent more money on payroll for VS Code in the past year alone than emacs has seen in the form of paid contributions over its entire lifespan, and the pocket change of VS Code's marketing budget likely exceeds the FSF's annual operating costs.
> So you can't only focus on Microsoft, you also have to take a look at the development community of Emacs.
Of course! But let's not pretend that the structure of a well-funded top-down commercial project's community (or the goals that foster that community) will be similar to the community that comes out of a volunteer-driven charity.
Posted May 7, 2020 14:33 UTC (Thu)
by pizza (subscriber, #46)
[Link]
(What's the quip? Freedom of the press only applies to those who own presses?)
Posted May 7, 2020 2:44 UTC (Thu)
by samroberts (subscriber, #46749)
[Link] (5 responses)
I think the improved quality of operating systems, Linux getting better and more common, mac coming out on top of a unixish userland environment, the withering away of AIX and HPUX and etc., might have hastened the loss of popularity of Emacs.
vi(m) on the other hand, is mostly used just as a text editor, so as better mail clients, shells, news readers (is usenet still a thing?), etc, etc, appear, it doesn't diminish in value as much. If you are already happy at the shell, its not much of a leap to using it for just editing code, and if you are sshed into a remove Linux system or docker image, you almost certainly have vim, not so certainly have emacs, so some basic familiarity with it necessary.
Posted May 7, 2020 8:01 UTC (Thu)
by hthoma (subscriber, #4743)
[Link]
Posted May 7, 2020 10:28 UTC (Thu)
by amacater (subscriber, #790)
[Link] (3 responses)
Text editing- maybe everything does markdown now?
IDEs are the curse/blessing of the age. They're a curse because they encourage lazy learning or will point out all the errors in your copy pasted code for you: they're a blessing because they are quick to use if you have access to the extensions. VSC is nice, if you like that sort of thing, because it has a terminal and SSH readily available from two extensions.
If you're really stuck using a Windows OS, then WSL allows you to drop a real Linux in and just work in Linux.
Emacs - works for that community of folk who want an extensible tool on their own machine, are happy to debug and write their own code in LISP. That's a larger community than the Linux distro Emacs packagers but maybe not by an order of magnitude. If distros can't package Emacs, it will die out in all likelihood.
Posted May 7, 2020 14:09 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (2 responses)
I once saw a router which didn't even have
Posted May 10, 2020 13:39 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 8, 2020 8:03 UTC (Wed)
by debacle (subscriber, #7114)
[Link]
Posted May 7, 2020 5:51 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (2 responses)
That reminds me of what Neal Stephenson, himself no slouch in the text production department, said of Emacs:
> If you are a professional writer - i.e., if someone else is getting paid to worry about how your words are formatted and printed - emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish.
Posted May 7, 2020 10:32 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted May 7, 2020 11:31 UTC (Thu)
by Baughn (subscriber, #124425)
[Link]
Posted May 7, 2020 6:55 UTC (Thu)
by rakoenig (subscriber, #29855)
[Link] (1 responses)
Agreed. Org mode documentation is more a reference material where you can lookup the details, but its not a guide to learn. Around 4 years ago I was trying to show members of the "Getting Things Done" group in LinkedIn how I manage my life inside a text editor. So I recorded a video. Looked at the video, thought it was lousy and I can do better. Some months later a long playlist was done with a step-by-step tutorial to approach Org mode. My YouTube channel grew from a few family subscribers to more than 3000 subscribers wordlwide. In my daily work I'm using lots of text editors, Vim, Emacs or whatever I need. Programming is done in an IDE, wether its Eclipse, IntelliJ or even VSC. But one Emacs window with my daily plan is always open and helps me to focus on the small goals that I want to achieve today.
Posted May 7, 2020 14:14 UTC (Thu)
by azz (subscriber, #371)
[Link]
Posted May 7, 2020 7:28 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (7 responses)
This is what turned me off from Emacs 20+ years ago. The documentation kept mentioning a "Meta" key that I didn't have on my keyboard. So I use vim, but for Java code I use Eclipse, Android Studio for Android development, Google Documents for human readable documentation, ...
Posted May 7, 2020 7:56 UTC (Thu)
by epa (subscriber, #39769)
[Link] (6 responses)
Posted May 7, 2020 11:17 UTC (Thu)
by vadim (subscriber, #35271)
[Link] (5 responses)
An actual terminal might have a bell inside it: https://en.wikipedia.org/wiki/VT100
This is different from how say, a DOS text editor would actually drive the PC speaker, and so be in full control of exactly what happened and what sound it would make.
Posted May 7, 2020 19:35 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (3 responses)
Posted May 8, 2020 17:43 UTC (Fri)
by epa (subscriber, #39769)
[Link] (2 responses)
We do accept this kind of antique language; most understand that when a program like Emacs "prints" something it's not going to put ink on paper. But it can be carried too far. "Ringing the bell" just raises a chuckle, but calling the Alt key "Meta" (however sound the historical reasons) gets in the way of good documentation.
Posted May 11, 2020 8:34 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted May 12, 2020 9:50 UTC (Tue)
by epa (subscriber, #39769)
[Link]
Posted May 8, 2020 3:01 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
vt100 didn't have a bell. It had a speaker.
I have used printing terminals, though, which had bells. ISTR TeleType 43, contemporary with VT100, did.
Posted May 7, 2020 10:20 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link] (5 responses)
But I am rather unsure that it was due to Emacs not following platform conventions. Various IDE from Borland for DOS were much better than Microsoft offerings and popular. Then Borland released IDE for Windows that did followed platform conventions and that was still better than MS. But it still lost to MS.
Posted May 7, 2020 12:29 UTC (Thu)
by jmclnx (guest, #72456)
[Link] (4 responses)
I have been using emacs a lot more over the last few years and this is what keeps me coming back. Remote editing using ssh is awesome. Editing encrypted text files via emacs so easy I use emacs for a password manager (via ccrypt). And source control (rcs/cvs), to me works better then what I have in vim (my own tool). I assume the same for git and will give that a try soon.
But the things that keep me from using emacs 100% are: Tag files, I tried many 'emacs plugins' for that and no matter what I try, i cannot get tags work exactly like vi, I am close though. Another 'killer' vi[m] function is how easy it is to pipe selected text into an external tool, which I use quite a bit. To be fair, I have not looked to see how to do that in emacs since vi[m] method is so easy.
Anyway will be interesting in seeing what happens in the near future with emacs.
Posted May 7, 2020 13:46 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
Select text, M-x shell-command-on-region (which is fittingly bound to M-| by default).
Posted May 7, 2020 22:17 UTC (Thu)
by jmclnx (guest, #72456)
[Link] (1 responses)
Posted May 7, 2020 22:42 UTC (Thu)
by asjo (guest, #56570)
[Link]
If you want the selected text to be replaced, press C-u M-| instead of just M-| before entering the command.
Posted May 8, 2020 13:50 UTC (Fri)
by ibukanov (subscriber, #3942)
[Link]
Posted May 7, 2020 12:53 UTC (Thu)
by Conan_Kudo (subscriber, #103240)
[Link] (1 responses)
Most of the Qt libraries are under the Lesser GPL, and KDE, e.V. can negotiate for newer versions if they ever showed up. In practice, I don't think it's as much of a problem. There's no version 4 of the GNU licenses in sight. But if it was a significant issue, perhaps this could be adjusted to the general variant of LGPL which allows upgrades.
Posted May 12, 2020 4:44 UTC (Tue)
by filbranden (guest, #87848)
[Link]
This doesn't make any sense whatsoever.
If that was the case, then you wouldn't be able to port Emacs to FreeBSD and run on a libc licensed under BSD.
Or maybe run on top of a Linux kernel which is licensed under GPL 2 exclusively. (Ok maybe I'm stretching, but is that really too much?)
Lucid toolkit is LGPL 2.1 or MPL 1.1, not "or later", should those bindings in Emacs be removed then?
I can only take it that this argument against Qt due to licensing was:
* Made by people who don't really know how licenses work, possibly not having a clear understanding of open source, perhaps because they haven't been in close contact with open source and are not keen on it; or was
* Made with malicious intentions, political in nature, perhaps trying to imply that if the Qt project was desperate and naive enough to hand these people a blank cheque in form of allowing them to relicense their code however they wished, they would be given the blessing to allow their toolkit to run the one true and pure editor, which is used by, checks notes, 3% of developers.
Sometimes I really do understand people who dismiss the GPL, especially when seeing this kind of zealotry, particularly by people who *should know better.*
Posted May 7, 2020 13:41 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (2 responses)
I don't think tweaking GUI elements or changing terminology will make much difference. Emacs appeals to a certain mindset; I think there will always be enough users to keep it a viable project, but never enough to make it a mass-market contender. I love Emacs and use it every day. I also use a lot of software that's much less popular than Emacs (such as my own Remind calendar tool.) Popularity, IMO, should be a secondary goal for software projects; once there's a critical mass of users and developers to keep the project viable, the main goal should be high quality.
Posted May 8, 2020 3:12 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (1 responses)
I am going to use Emacs until the bitter end, but it gets harder every year because there just aren't enough user/developers. I'm kind of on my own to figure out how to fix or add things in elisp.
Really popular open source tools just don't have quirks and missing pieces because there will always be someone capable of fixing them getting irritated enough to do it.
Posted May 8, 2020 20:10 UTC (Fri)
by dskoll (subscriber, #1630)
[Link]
Yes, you do need a critical mass. I think emacs still has that critical mass.
Also, really popular open-source projects can have plenty of quirks and missing pieces, depending on the governance of the project. Both Gnome and KDE are extremely popular, and yet from my viewpoint, they are unusable because of quirks... the direction of those projects just doesn't suit the way I work. I guess the quirks are in the eye of the beholder in this case.
Posted May 7, 2020 16:31 UTC (Thu)
by hifi (guest, #109741)
[Link] (3 responses)
I'd rather take a modern IDE that has good language support built in with decent vim emulation over spending hours on trying to get some weird hack working in vim that desperately tries to make it feel more like an IDE. That said I should try that again.
I don't think vim or emacs have much to offer these days for programmers who just want things to work and they can do very little about it.
The problem for me with VSC is that it's not properly packaged as free software with free software plugins from distro repos. VSCodium only fixes one part of the equation. The convenience of VSC is currently more valuable than the missing free-software-only-from-distro-repos bit.
Posted May 8, 2020 12:54 UTC (Fri)
by jerojasro (guest, #98169)
[Link] (2 responses)
I had an opinion similar to yours, and was feeling really tired of fiddling with (in my case too) vim to get something a modern IDE gives you out of the box.
But then two things happened:
1. Vim got support for running commands asynchronously, and now things like linters could do their thing without blocking the user interface
2. The concept of Language Servers and the associated Protocol (LSP) took off; that allows ANY editor to implement IDE-like features (code navigation, autocompletion) once, in a language-agnostic fashion, and it will work for any language (that has a decent LSP implementation out there).
Those IDE-like features work well enough in Vim nowadays. And have the same UI/semantics, for any language. There might be differences in functionality, but due only to the maturity of the lang. server you use.
And when you add to those capabilities the wealth of things vim brings to the table by itself... I think it's still a very compelling package.
I do think we need more work in making that "get IDE-like features running for language X in my editor" experience smoother, but nowadays it's not the humongous amount of work it was before, thanks to LSP.
Posted May 9, 2020 18:26 UTC (Sat)
by hifi (guest, #109741)
[Link] (1 responses)
I used clangd as the LSP as it looks to be quite mature. Still, I had to install multiple "plugins" by cloning git repositories just to get the LSP functionality going - even after that I had trouble understanding how you configure the keybindings properly and even then it didn't work "just like in VSC" that it would automatically show me signatures and suggestions of everything I'm currently typing without needing a manual command every time.
Then I saw that NeoVim has nightly support for LSP built-in which seemed nice. Again, had to install a plugin for it even though it's built-in for some reason (nvim-lsp) and again it worked pretty well when I manually asked it to do something but it didn't really help me on-the-fly like I would prefer.
It just isn't there yet. Requires too much obscure configuration and even then it didn't seem easy to get it to work automatically. It is still much easier to just pick up VCS, install the Vim emulation plugin + language plugin and after that it just pretty much works like I'd expect it to.
I assume if I spent more time on it I would get it to close to my liking but this excercise was to see how good the OOTB experience is.
Posted May 10, 2020 13:36 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
I mostly use it as a notifier of issues rather than dealing with any keybindings specific to the plugin.
Posted May 7, 2020 17:27 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
Speaking as a vim user who wouldn't touch Emacs with a ten-foot pole: Honestly, I think it has more to do with system defaults and convenience than anything else. I taught myself vim because the system kept dumping me into vim (and also because the documentation told me it would make me more efficient, but IMHO that was a lie; text manipulation is not the bottleneck of programming). Nowadays, Debian and Ubuntu have switched to nano, so I imagine that in another few years, that will experience a resurgence in popularity.
Posted May 7, 2020 18:40 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link] (4 responses)
I respect Emacs a lot -- it seems like a more capable engine, it just has poor usability. Vim, while it feels like a pile of hacks, tends to work well. Compare the keyboard commands to split the editor window vertically or horizontally so you could see two files at once: in vim it's Ctrl-w v or Ctrl-w h, while in Emacs is Ctrl-x 5 2 and Ctrl-x 5 4 or some such nonsense with absolutely zero mnemonic value.
I've heard claims that the default Emacs keybindings are terrible on purpose, to force users to create custom mappings they would personally prefer. I'm not sure I believe that, but it's plausible and exactly the kind of abdication of responsibility towards user experience that hinders Emacs's acceptance.
Posted May 8, 2020 6:57 UTC (Fri)
by idrys (subscriber, #4347)
[Link] (3 responses)
That probably just shows how different people are: I've been using Emacs since the late 90s, and its choice of commands made more sense to me than those in vim (the first editor I used on Linux was joe, maybe that says something as well.) Even with a German keyboard layout.
Maybe Emacs vs vi(m) is like cat people vs dog people :)
> I've heard claims that the default Emacs keybindings are terrible on purpose, to force users to create custom mappings they would personally prefer.
Is changing the keybindings really that common? As said above, I'm happy with them (maybe I'm just used to them :); I also used firemacs in Firefox back when it still worked.
Posted May 8, 2020 9:23 UTC (Fri)
by mgedmin (subscriber, #34497)
[Link] (2 responses)
Can you explain this to me?
I understand and remember things like Ctrl+F/B (forward/back), Meta+f/b (same, but for word motions). I'm baffled by the Ctrl+X 5 2 sequences.
(I can remember Ctrl+X 5 1 for "leave only one window" and Ctrl+X 5 0 for "close the window", because 1 and 0 are mnemonic, although the Ctrl+X 5 part is still weird and unintuitive. In vim this would be Ctrl-W o for "window, only" and Ctrl+W q for "window, quit". Ok, there's also Ctrl+W c for "window, close", which differs from Ctrl+W q in that it won't quit vim if you have only one window open.)
Posted May 8, 2020 12:27 UTC (Fri)
by neilbrown (subscriber, #359)
[Link] (1 responses)
I think it must be like an in-joke.
It starts out fairly mnemonic:
but then new features were added incrementally:
C-x 3 - split side-by-side, because megapixel displays makes this useful
Posted May 8, 2020 14:52 UTC (Fri)
by idrys (subscriber, #4347)
[Link]
> I think it must be like an in-joke.
> It starts out fairly mnemonic:
Keep in mind that I started using it in the 90s.
> but then new features were added incrementally:
> C-x 3 - split side-by-side, because megapixel displays makes this useful
I rarely (if ever) use more than a horizontal split, as this is most useful to me, and I usually just switch between them ('o' is easy to remember for that.)
> C-x 5 - do something in another frame (X11 window) because a real window system makes that meaningful.
Ok, I always run it -nw (started doing so because I did not always have X available anyway, and stuck with it because I really prefer the look.)
> C-x 6 - does something with text columns in a buffer ... OK, you have to squint a bit to see the connection now
These are indeed odd, but I've never used them :)
Regarding the vi(m) interface: Maybe I might find it easier now, but I was probably mostly confused by the interface back then.
(And I really like M-x <whatever> telling you if there's a shortcut available.)
Posted May 7, 2020 17:37 UTC (Thu)
by yingw787 (guest, #138082)
[Link]
I'm also looking to use the tabler dashboard and may have a specific UI/UX taste, but having open-source licenses is really important to me for the project I'm working on.
Posted May 7, 2020 18:57 UTC (Thu)
by magnusmorton (guest, #131590)
[Link]
Posted May 7, 2020 22:15 UTC (Thu)
by curtis3389 (guest, #127185)
[Link] (2 responses)
There are probably 2 major problems with it:
I fell in love with Emacs because it's key combinations were based of the command you want to execute instead of where you're hands are on the keyboard like Vim. I just can't memorize the key shortcuts for Vim because I use Dvorak.
That being said, the mouse needs to be equal to keyboard shortcuts to lower the barrier for entry for new users. I know there's a GUI version and the mouse support isn't bad, but it's not equal.
Once you get comfortable with basic editing in Emacs, you quickly run into the issue of learning Emacs Lisp. I've started learning Lisp so that I can have a language with the features I want, but I gave up on Emacs Lisp a long time ago. It's clearly not a very good Lisp, and the beginner manual could be a lot better.
As others in the comments have mentioned, Emacs needs to use JavaScript if it wants today's developers. Everyone already knows it, whether they're a CS major or not. It's similar enough to other languages you know that even if you don't know it, you can figure it out pretty quickly. I know it's objectively an absolutely terrible programming language, and NPM is a blackhole that destroys all hopes of security, but that's where today's developers are.
Like trying to switch Emacs from Emacs Lisp to Scheme, Common Lisp, or Guile, you'll need to rewrite practically everything. Thus, Emacs must die so that Emacs may live.
Posted May 8, 2020 13:21 UTC (Fri)
by jerojasro (guest, #98169)
[Link]
Posted May 10, 2020 13:38 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
hjkl are the only location-based keybindings in Vim. Everything else is mnemonics (or, rarely, forced elsewhere due to availability like <C-e> and <C-y>). I was able to be decently effective when I was using Colemak because the keys were bound to letters, not location (hjkl were in a nice inverted diamond so at least they were proximal).
Posted May 8, 2020 4:15 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (19 responses)
The GNUstep/macOS interface needs a rewrite too, apparently: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24472
> the keyboard shortcuts are different than other programs,
Readline is everywhere and it uses the (basic) Emacs shortcuts.
BTW "jed" is a my favorite, "low-end" editor wit Emacs shortcuts. There are many others. Using one of them can help with this transition _if_ you're interested in a "text-editing Operating System":
> but I am saying that it's for those who are willing to learn, seeing some extra work as the aforementioned long-term investment, and who have the patience reach a worthy goal a little later rather than right this very minute.
> "Terminal-based Vim is not like a modern application, yet is more popular than Emacs."
What fascinates me is: vim is apparently the last _modal_ editor left. I don't think I could ever get used to "modal editing", because I _always_ forget which mode I am in. Anyone knows what's wrong with me?
PS: once again, an LWN article that saves hours and hours of reading mailing-lists. Thanks!
Posted May 8, 2020 9:34 UTC (Fri)
by mgedmin (subscriber, #34497)
[Link]
Nothing!
I've been using Vim for 20 years. I still get mixed up in the modes.
What I think happens is that us Vim users get reflexes. When we see the text in the buffer doing something nonsensical, reflexes kick in and the fingers automatically do <Esc> <Esc> u (for undo), maybe repeat the u until the text in the buffer starts making sense, and then repeat the editing action.
When undo doesn't work right, or repeating the action doesn't do what I want again, there's the second level of recovery: turn CapsLock off, then try the <Esc> <Esc> u ... procedure.
TBH I'm skeptical about the claims that vim makes editing more efficient than other editors, especially modern IDEs. But it certainly makes editing more _fun_. I'm sure the time I spent tweaking my .vimrc or writing custom Vim plugins, or debugging a macro to do repetitive changes to multiple files takes longer than just doing the editing manually the boring way, but that would be _boring_.
Posted May 8, 2020 11:55 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (6 responses)
vim recognizes this, and unlike some implementations of vi, it actually indicates at the bottom of the screen which mode you're in if you aren't in the default mode.
Posted May 8, 2020 12:22 UTC (Fri)
by pebolle (guest, #35204)
[Link] (5 responses)
Both terminal emulators now recognize the escape codes (or is it ascii codes, I forgot) to change the cursor. So in these emulators programs can switch the cursor to "|", "_", and to a solid block.
This allows vim to emit these escapes code before changing modes (there are special hooks for that in .vimrc, whose names I also forgot). And so one can make vim use eg. "|" for INSERT, "_" for NORMAL, and solid block for REPLACE.
(But do note that I stopped using a .vimrc altogether. My .vimrc grew so unwieldy that I decided I would be happier without one. It turns out that this is the case. So I'm not at all sold on the configurability of vim. Neither would that feature endear me to emacs, if I would use that editor, which I don't.)
Posted May 8, 2020 12:34 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
automatically switching formatoptions from tcqn (the intuitive-for-me behaviour for "plain text") to crqnj (the intuitive-for-me behaviour for "code")
setting cinoptions to conform to my personal coding style
setting expandtab when editing non-Makefile code
clearing expandtab when editing Makefiles
setting expandtab, sts=4, and sw=4 when I am editing documentation written in Markdown
Posted May 8, 2020 12:44 UTC (Fri)
by pebolle (guest, #35204)
[Link] (1 responses)
Yes, that's quite a chore, but I personally couldn't summon the strength to start a new .vimrc from scratch. Yes, I know, I'm weak.
Posted May 8, 2020 13:52 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
That file might as well be called $HOME/.vimrc :)
Posted May 8, 2020 13:30 UTC (Fri)
by jerojasro (guest, #98169)
[Link] (1 responses)
Posted May 8, 2020 19:02 UTC (Fri)
by pebolle (guest, #35204)
[Link]
No, that wasn't me. But thanks anyway!
Posted May 8, 2020 16:22 UTC (Fri)
by jem (subscriber, #24231)
[Link] (8 responses)
My biggest problem with vi is not that it is modal, I can get used to that. I think the strangest thing about vi is how it handles the cursor. "Normal" editors use the cursor to specify a point between two characters, or before the first character on the line, or after the last character on the line. If there are N characters on the line, the cursor can have N+1 positions.
Vi, on the other hand, uses the cursor to mark the character it is on. The exception is of course if the line is empty, in which case the cursor has nowhere to go, so it is displayed in the first column. This also means we need both an "insert" and an "append" command to enter insert mode, to add text either to the left or the right side of the cursor. Once in insert mode, vi starts treating the cursor exactly like all other editors do: text is inserted at the left edge of the cursor and the cursor is moved forward past the inserted character. When insert mode is exited, vi goes back to its normal behavior and realizes the cursor can't be left hanging mid-air, so it moves the cursor back one step, which is really confusing.
If somebody has a good explanation why vi is implemented like this, I'd like to hear it.
Posted May 8, 2020 17:21 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted May 10, 2020 14:42 UTC (Sun)
by jem (subscriber, #24231)
[Link]
Posted May 8, 2020 17:46 UTC (Fri)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted May 12, 2020 4:04 UTC (Tue)
by filbranden (guest, #87848)
[Link] (3 responses)
It's just one setting away on Vim:
set virtualedit=onemore
You might still find some of the behavior a bit unexpected. For example, $ moves to the last character of the line, rather than one past.
Also, you might just break so many plug-ins this way :-)
But yeah, it's available as a configuration option.
Posted May 13, 2020 11:07 UTC (Wed)
by jem (subscriber, #24231)
[Link] (2 responses)
Ok, thanks. But this is only a partial solution. As you said, $ does not work, and pressing <esc> in insert mode still moves the cursor one position left. You would think i<esc> (entering insert mode and immediately exiting) would be a no-op, but no. My biggest problem with this setting, though, is that it is not supported in VS Code's vim emulator, which is my main use case for vim: to replace VS Code's Notepad-like default editor with a real editor.
Posted May 13, 2020 12:10 UTC (Wed)
by karkhaz (subscriber, #99844)
[Link] (1 responses)
Posted May 13, 2020 17:43 UTC (Wed)
by jem (subscriber, #24231)
[Link]
There's a lot to like about vi, too, for example how you are able to combine editing commands with movement commands. At least you don't have to reach for the arrow keys all the time.
Posted May 9, 2020 0:17 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link]
In normal mode, you sometimes want to operate on characters. Commands like replace ('r'), substitute ('s'), delete ('x') work on the character that the cursor is on, unless of course you prefix the command with a number (in which case the command operates across a span of text, but still starting on the character that the cursor is on). It would not make sense for the cursor to be at the beginning of the line, before any characters, because what character are you operating on?
In insert mode, as you say, the cursor acts like in other editors, because insert mode is the mode that is akin to other editors.
Somebody else made a comment about the cursor changing its shape based on the mode---that seems like a very helpful way to understand this difference, what an excellent feature! In insert mode, you can have the pipe-cursor before the first character on the line, because you can start inserting text before the first character. In normal mode, the cursor is an underline, and the action operates on the character that is underlined. The underline cannot move before the first character or after the last, since there's no character for it to operate on.
Posted May 14, 2020 13:01 UTC (Thu)
by bmorel (guest, #138892)
[Link]
There is also kakoune (https://kakoune.org/).
> I _always_ forget which mode I am in. Anyone knows what's wrong with me?
Dunno. I don't think I have issue with that.
I think why I don't have problems reminding the mode I am in is because I only go into editing for actual writing. When I'm done, I just escape to normal mode to do whatever I want to do.
To the topic... I don't see emac's point, exactly because of how I setup my environment: it does too much stuff, so having it in my environment would mean redundant tools, which I try to avoid (well, vim have window manager integrated, too, I never use it and would be happy if it was not here).
Maybe provide some packages that does IDE by default? Some easy way to summon it with different setups depending on the task people want to do? I think Visual Studio did that last time I had to use it: depending on the language, it had a different look, a different way to do things.
Posted Dec 3, 2021 19:46 UTC (Fri)
by innocentoldguy (guest, #155556)
[Link]
I've recently been learning Emacs because I like Org Mode. My only issue with Emacs is that the plugins seem to range from unpolished to non-functional (adoc-mode). Plugins for both Vim and Kakoune feel more polished and well-thought-out to me.
Posted May 8, 2020 7:01 UTC (Fri)
by Jookia (guest, #128586)
[Link]
Posted May 8, 2020 18:21 UTC (Fri)
by hughlt (guest, #103920)
[Link] (1 responses)
I have used emacs all day for more years than I would care to admit, using org-mode, tramp, tags lists, and a few simple elisp commands of my own, but I work in a large codebase (~ 6Mlines) that includes C++, java, python, and bash (with new javascript components on the way). So, of course, I spend much more time reading code that writing it. I also get rusty on syntax on languages that I use infrequently.
That said, even when I occasionally use an IDE, I still use emacs for the actual editing. And writing org-mode markup for conversion to Beamer slides or Confluence markup are both indispensable.
Posted May 8, 2020 18:38 UTC (Fri)
by hughlt (guest, #103920)
[Link]
Posted May 10, 2020 4:50 UTC (Sun)
by mtaht (subscriber, #11087)
[Link]
Posted May 10, 2020 5:24 UTC (Sun)
by gdt (subscriber, #6284)
[Link] (2 responses)
To put that another way, my ~/.emacs, which does nothing extraordinary, is over 500 lines. Most of which is activating packages or making settings which should be on out-of-the-box. The amount of boilerplate programming needed to get liftoff is only exceeded by Cisco IOS router configurations.
The basic keycodes not matching common practice is an issue, and one which needs resolving out-of-the-box, not with some magic setting. There's nothing wrong with the current Emacs keycodes, they just lost mindshare. Many user's can't even press all the Emacs key-codes, as their operating system has other ideas about those modifier keys.
There's nothing wrong with Emacs LISP *except for* when ~/.emacs starts to be a LISP program rather than simple statements which can be set via the GUI.
The huge kludge to make Emacs work on GUIs needs careful surgery because its shortcomings hurt every time GUIs change to accommodate new hardware -- such as HiDPI. Libreoffice is a great model of how to do such surgery on a huge codebase. Part of the issue here is that package owners are seen as users who can't be disrupted, rather than as projects who can be asked to make changes.
Posted May 10, 2020 9:38 UTC (Sun)
by tpo (subscriber, #25713)
[Link]
Wow. Exactly this for me.
I've tried Spacemacs because I think their goal is to solve exactly that. But then I got completely lost in "stuff works differently in Spacemacs and some howtos don't seem to apply" and gave up once more.
Posted May 12, 2020 6:45 UTC (Tue)
by epa (subscriber, #39769)
[Link]
Posted May 10, 2020 8:42 UTC (Sun)
by llloic (guest, #5331)
[Link] (3 responses)
> There are even longtime Vim users (who may have started on vi, in truth) that need Emacs for certain tasks—me for example.
Just by curiosity, what are the tasks where you need emacs?
Thanks for the article
Posted May 10, 2020 19:38 UTC (Sun)
by jerojasro (guest, #98169)
[Link]
* editing Lisp code, expanding macros, stuff like that.
Posted May 10, 2020 22:06 UTC (Sun)
by jake (editor, #205)
[Link]
> Just by curiosity, what are the tasks where you need emacs?
The main way to edit articles here at LWN uses Emacs. I also use Gnus to read mailing lists. Once in a great while I will be doing something in Vim and switch over to Emacs for some useful feature. Though I am not expert with either editor, so Vim probably has the feature and I just don't know how to access it :)
jake
Posted May 12, 2020 18:32 UTC (Tue)
by sjatkins (guest, #138806)
[Link]
When I am working/debugging against an remote server emacs in a screen session is a godsend. No GUI based tool can do that.
Posted May 14, 2020 12:59 UTC (Thu)
by antismap (guest, #114361)
[Link]
IDEs suck at this, it starts with opening a file which is not part of a project. It's just a pain.
Posted May 14, 2020 13:06 UTC (Thu)
by N0NB (guest, #3407)
[Link]
As already mentioned, anachronisms abound and a new user needs a cross reference to make sense of it. Over time it becomes second nature as one moves between other applications and Emacs.
Some features show that the GUI is a bolted on afterthought rather than well
I use Emacs because it works very well with Autoconf, Automake, and shell files, Org-mode, GNUS, and because I have a highly customized chunk of my init.el devoted to tweaking the C-mode syntax highlighter exactly to my liking. ATM my init.el runs to 297 lines including comments and I still struggle with elisp. I've tried a multitude of GUI editors and none come close to being able to tweak the syntax highlighter to the detail I'd like. Most use Scintilla which offers a certain amount of control over the highlighter but is still lacking for my preference. Non-free editors such as VS Code need not apply here.
Posted May 26, 2020 18:21 UTC (Tue)
by jnorden (guest, #139127)
[Link] (2 responses)
To start with, the idea that emacs "needs" to have more users to prevent it from becoming "extinct" is basically absurd. Free software, by its very nature, *can't* become extinct. Even if current trends/fads mean that there is a lull in the number of people using Gnu emacs today, the source code will still be available for future generations to discover and use. It's about like saying that we must find a way to make the "Early New English" language of the 17th century more appealing and widely spoken in order to prevent the works of Shakespeare from becoming extinct. Even if, for some reason, people stopped reading and producing Shakespeare's plays for a number of years, they would undoubtedly be re-discovered and become popular again.
This all seems to be part of the current insane attitude that software, and technology in general, is some sort of perishable commodity with the shelf life of milk. Somehow, if it isn't updated every month or so, it just isn't any good any more, even though it still does what it used to and your needs for it haven't changed.
Emacs has never been an editor for "casual" user. It doesn't compete with notepad, any of the various "office" editors (open source or not), or even vi/vim. Gnu emacs is for people that want an extensible editor that gives them complete control over how it operates, and can be easily and freely customized to accomplish any sort of task that they want it to. This sort of freedom comes with a price - you need to invest some time and effort in order to learn how to use it effectively. But for many of us, it is an effort that has been more than worthwhile.
In my opinion, it would be incredibly counterproductive to try to attract people who don't need the functionality that emacs provides, or who aren't willing to put forth the effort required to learn how to effectively use that functionality. I believe this means that any person who's decision on whether or not to use an editor is swayed by the appearance of buttons or rounded corners is someone who should *not* be encouraged to start using emacs. If you are not attracted to emacs by the features it provides and the tasks it can accomplish, then please find an editor that will better suit your needs.
On the other hand, if someone wants to add such features for their own benefit, perhaps because they feel it will enhance their own aesthetic experience while using emacs, then by all means do so. That is the whole point of free software, after all. But adding these in an attempt to attract more users is a bad idea.
My *fear* is that a major effort to increase the "user base" will lead to the transformation of emacs into something that doesn't serve anybody's needs very well. This is happening in many open source projects, where all sorts of functionality has been deprecated and then removed because of the perception that it isn't needed or being used by a large enough fraction of users. The recent loss of malloc_get_state() and malloc_set_state() are examples that are particularly relevant to emacs.
Even in emacs, I personally found it a bit annoying to type "M-x count lines region" only to be told in the mini-buffer that:
‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
But this was easily fixed by adding a single line to my .emacs file. However, if large blocks of code start disappearing from the source, or changes are made that render existing elisp files unusable, then emacs really will run the risk of becoming extinct.
For example, a package of elisp functions that I wrote 30 years ago for emacs-18, which I use to record and average student grades, still works just fine with emacs-26. TeX is the only other software that I know of with this level of stability. It seems that there are very few people today who, like Knuth and Stallman, take a long-term view of what they are trying to accomplish. I could go on along these lines, but this is probably sufficient.
----
However, I feel that I must respond directly to some of the comments about RMS that have been made, along the lines of "emacs would be better without him" or his "signature tantrums." I'll respond in a way that RMS never would, because he is far too polite:
Do you have any idea who the f*** you are talking about!!?
When Richard founded the FSF, which basically started the free software movement, people tried to write him off as some sort of extremest nutcase. "Nobody will write software and just give it away" was a common criticism. Well, history has shown that Stallman was correct, and his critics were the nutcases. It's quite possible that there would be almost no free software, no linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his unfailing efforts and unwavering belief in free software though the years. My own opinion is that, if anything, Richard's opinions and views are a bit too mild and conservative.
The arrogance of youth is natural. I was certainly guilty of it when I was young. But there is no excuse for disrespecting the people who basically built the universe that you currently enjoy inhabiting.
-Jeff
Posted May 26, 2020 18:30 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Sure, even now there are people who now resurrect old IBM mainframes for fun, but this doesn't mean that the old mainframe programming is in any way alive.
Like it or not, tool development is a Red Queen's race - you have to run just to be able to keep up. Emacs code editing ability is already kinda borderline compared to more modern tools, and it's only going to get worse.
Posted May 27, 2020 3:41 UTC (Wed)
by flussence (guest, #85566)
[Link]
Snuffing out the GPL3 has become one of the foundational pillars of a trillion-dollar industry, so uh, congrats to him for his bit part in drafting a relatively short anti-shibboleth that works on both an economic and social level?
And I'm pretty sure the existence of Git was mostly Tridgell's fault. I've never seen a VCS commit with Stallman's name anywhere near it; in fact I don't think I've seen him write any software this century.
BSD says hi, by the way.
Posted May 30, 2020 17:24 UTC (Sat)
by jgfenix (guest, #113371)
[Link] (2 responses)
Posted May 30, 2020 18:34 UTC (Sat)
by jem (subscriber, #24231)
[Link] (1 responses)
If you are suggesting the GNU Emacs project should abandon their current code base and adopt Hemlock instead, what problem would that solve? Would it solve the usability or the not-so-sleek look of GNU Emacs mentioned in the article? What about the millions of lines of Elisp code? Would Elisp compatibility be possible to implement in Hemlock? Emacs Lisp is not going away ever.
The port of GNU Emacs to use Guile instead of the built-in Lisp implementation has failed so far, but not because Scheme is a weak language or Guile a bad implementation of Scheme. The problem with Guile Emacs has to do with the difficulty of integrating Guile with Emacs and getting the final bits of Elisp compatibility to work, getting the editor to start up fast enough, etc.
The idea with Guile Emacs is not to replace Emacs Lisp with Scheme (not initially, anyway), but to use a better (faster), and more decoupled implementation. Interest in Guile Emacs has slowed down because people are asking the rhetorical question "what problem does it solve?"
Posted May 31, 2020 2:12 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Dec 12, 2020 22:09 UTC (Sat)
by xiaoxing (guest, #143632)
[Link] (1 responses)
Posted Jan 23, 2021 18:10 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Also... if you live in Emacs, its' likely that learning it is useful for its own sake, even if it *is* useful nowhere else. It's like being able to reprogram your brain.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
RE: lsp, C++ (and rtags) (Making Emacs popular again)
Making Emacs popular again
VSCodium and C-language LSP server licensing
VSCodium and C-language LSP server licensing
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
It wouldn't change the language but merely add a clearer syntax. I naively think it would help.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Great support, and lots of cool new tools
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
I can't leave emacs because:
- 90% of my memory is written down in org notes using org-mode.
- M-x C-f combos keep my fingers limber.
- I feel too close a kinship with emacs given that my popularity peaked around 3rd grade. I have come to resigned acceptance that my glory days on top of the social pyramid are gone forever.
Now, excuse me, I have a M-x doctor psychotherapy session with my Emacs to attend to - it greatly helps me in these days of social distancing.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
how long do they remain popular?
Making Emacs popular again
Making Emacs popular again
> how long do they remain popular?
Having worked with both AngularJS (2010) and Vuejs 2 (2016) recently I can testify that there is a world of difference in the experience.
So let's have less condescending commentary please.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Vim's popularity
Making Emacs popular again
https://gitlab.gnome.org/GNOME/gtk/issues/221#note_577021
Making Emacs popular again
https://gitlab.gnome.org/GNOME/gtk/-/issues/2315
to which the response was "Surviving a display connection going away is basically uninteresting for anything but emacs, so the chances of this getting fixed and keeping working are somewhat low.". Fair enough.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
https://lwn.net/ml/emacs-devel/82460db0-1ecf-cf11-7dbf-d7...
Making Emacs popular again
abort(), and nobody from the Emacs camp has come up with a patch, or at least a description of the required Emacs behaviour that is supposedly not supported by GTK.Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
And once the firefights were over, RMS actually merged the changes back b/c so many users wanted them.
In fact, GNU emacs was a branch as well.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
I agree with this. Every time big elisp changes are brought up, the discussion makes me think that it will never happen as the benchmark is just impossibly high. The guile guys made a very compelling case last time around too. A fork with guile as the base, LSP as a first class citizen, some of the visual components from spacemacs and maybe an effort to clean up some of the cruftier parts of the base (we really don't need vax support anymore. stuff like that) would be interesting. I'd use it as a daily driver.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
If you're going to be in that environment, it's worth knowing vi keystrokes because that's what you'll get.
Making Emacs popular again
vi, only ed... The actual recommended method to change configuration was to download the configuration via FTP, edit locally, then upload via FTP.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
"there is a high barrier to learning Org mode from its documentation"
"there is a high barrier to learning Org mode from its documentation"
the terminology used in the Emacs world does not match with what users expect
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Beeping vs ringing the terminal bell
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
But Stallman was quick to put the kibosh on that; Qt is only available for GPL 2 and 3, using it would mean that if there is a GPL 4 someday, Emacs could not switch to it. "So we must avoid using Qt."
Making Emacs popular again
Making Emacs popular again
The concern about popularity for Emacs is that critical mass.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
The *requirement* to use any other editor for me is that it has decent vim emulation - VSC checks that box very well.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
> Compare the keyboard commands to split the editor window vertically or horizontally so you could see two files at once: in vim it's Ctrl-w v or Ctrl-w h,
> while in Emacs is Ctrl-x 5 2 and Ctrl-x 5 4 or some such nonsense with absolutely zero mnemonic value.
> I'm not sure I believe that, but it's plausible and exactly the kind of abdication of responsibility towards user experience that hinders Emacs's
> acceptance.
Making Emacs popular again
Making Emacs popular again
C-x 0 - close current window
C-x 1 - make this the only window
C-x 2 - split the window (top and bottom of course - terminal only have 80 columns, and 40 is really too narrow to be useful)
C-x 4 - do something in the "other" window - because now that we have more than 2 windows, there are more things we want to do.
C-x 5 - do something in another frame (X11 window) because a real window system makes that meaningful.
C-x 6 - does something with text columns in a buffer ... OK, you have to squint a bit to see the connection now
C-x 7 ... nothing
C-x 8 - insert unicode chars ... squinting isn't sufficient any more
Making Emacs popular again
> C-x 0 - close current window
> C-x 1 - make this the only window
> C-x 2 - split the window (top and bottom of course - terminal only have 80 columns, and 40 is really too narrow to be useful)
> C-x 4 - do something in the "other" window - because now that we have more than 2 windows, there are more things we want to do.
> C-x 7 ... nothing
> C-x 8 - insert unicode chars ... squinting isn't sufficient any more
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
1. Heavy use of key combinations
2. Emacs Lisp
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
>set virtualedit=onemore
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
I was willing to try to get used to it since ages, but debian's version didn't had syntax coloration embedded by default, which was a blocker. This thread (specifically your comment) reminded me of it, and nice surprise for me is that, by default on current debian, it *have* syntax coloration without having to mess with config. So I'm gonna give it a try. Maybe I'll just revert quickly to vim anyway, since my fingers have some muscle memory with it now.
Basically, I see 4 modes: visual, which is pretty... visual, for selections. Command, which put my cursor in the command area with the ':' prefix, 'normal' and 'editing' (this one have 2 variants, yes: replace and insert, and unfortunately, by default, the cursor keeps the same shape).
The only possibility of confusion I can see is between normal and edit modes.
I would not call me an advanced vi user, and I don't use it since that many years, less than 10.
Vi-like editors... well, that and bash/zsh... are really usable to me *because* I discovered tiling window managers. They are all powerful tools by themselves, but require time to learn. Their main selling point is that they allow to kill the rat, but that's useless if you need that beast to control and place your windows.
And that makes the reason for which I can avoid using an IDE: my desktop environment have mutated to a development environment, still lacks some features compared to actual IDEs, but have mails, calculator, music player, image viewer, crash-resilience and speed. Can also run most of it's parts without X11, useful for sshing, and it's shortcuts, icons, toolbars and popups really rarely change with new versions.
What I know is that, on the 6 dev colleagues I had on my last job, 2 moved to vim+bash+i3, and I didn't said them to do so, they did it because they wanted to. So, learning vi/emacs is *not* related to age and modern techs.
If emacs wants to rise anew, then they should not aim at competing with text/code editors, but with IDEs, because the integration of many features seems to be it's selling point, but it is by far harder to use and setup than the average IDE.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
Perhaps I just need to keep up with developments better!
terminal mode
Making Emacs popular again
Making Emacs popular again
> [...]
> The basic keycodes not matching common practice is an issue
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
* using large plugins, like org-mode.
Making Emacs popular again
Making Emacs popular again
Making Emacs popular again
For all the rest I use emacs.
vscode or other solutions may be nice in code completion and being "smart" but for those tasks, Emacs will always be more practical:
- open a file while browsing directly in the editor
- copy / paste files around, create folders, directly from the editor
- file operations such as grep, filter lines and so on
- git operations such as log, commit, push... (using magit)
- generally doing something in small window divisions, being able to copy/paste part of each division to other ones
Making Emacs popular again
As already mentioned, anachronisms abound and a new user needs a cross reference to make sense of it. Over time it becomes second nature as one moves between other applications and Emacs.integrated into Emacs. One of the excellent features of Emacs is the kill ring, however, I don't recall it being exposed through the GUI so that text in the kill ring could be selected rather than have the chunk of text be dumped into the buffer at point (another anachronism) each time a new chuck is recalled. This behavior has allowed me to make some rather spectacular editing errors. Fortunately, as I recall, the kill ring is copied to the clipboard and I use Gnome's clipboard extension to recall a text chunk. No, I am not the most efficient at using an editor and I accept that.
Making Emacs popular again
Making Emacs popular again
Why would future generations use it?
Making Emacs popular again
What about adopting Hemlock?
What about adopting Hemlock?
What about adopting Hemlock?
Making Emacs popular again
Making Emacs popular again