Live data from Hacker News

Making Emacs Popular Again

lwn.net

221–230 of 782 posts

Re: Making Emacs Popular Again

#221
post #205
post #182

Earlier quoted context omitted.

You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! The initial experience of vi is that you learn six keys to press to make it do things, and go from there. Emacs is significantly more complex than that, starting out. It's definitely not intuitive, but it's an order of magnitude of difference from Emacs, which could be…

Vi has text input modality, unlike essentially, well, anything. It's an entirely different model of operation which it shares with no current software and hasn't for a quarter century. It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains ema…

'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you?

The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all that much dysfunction, in my opinion.

Re: Making Emacs Popular Again

#222
post #18

Earlier quoted context omitted.

> And the old "I have suffered therefore the others have to suffer". Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding experti…

This is absolutely true. However, if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should. One way to do that is to not gratuitously invent new terms, and to use terms people are familiar with. Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is nee…

I think maybe you're over-emphasizing the problem with this terminology. When I first started learning Emacs it took me all of 5 minutes to get used to the new terms, it isn't that hard. Maybe there's an argument for the lack of value of using older terminology, but again, I think this problem is overblown.

Re: Making Emacs Popular Again

#223
post #200

Earlier quoted context omitted.

Re copyright, what would you prefer? Alternatively, what would you even do with the copyright to your fixes and additions to GNU emacs?

a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all. it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL. at the end of the day a lot of…

Yeah I completely agree. It's like, I agree with GNU and the FSF, but that doesn't mean I'm as strict as they are. I want to contribute to MIT, Apache, and BSD licensed projects as well, or I want to just not think about it and work on some project that has no licensing info whatsoever.

But (some definitely not all) folks are pretty all or nothing. There's a lot of jerk developers on the net though, maybe it's better to just ignore them?

Re: Making Emacs Popular Again

#224
post #93

I wish Vim users and Emacs users would unite to improve Spacemacs. It's really a great idea IMO, have the editing power of Vim with the flexibility and elegance of the Emacs environment. Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was rig…

As a vim user, I use Spacemacs for Lisp. Otherwise, I don't like mode inconsistencies (e.g. vim keys don't work inside SLIME debugger), the lack of tabs and the startup/running footprint. It doesn't feel right or convenient to have many Emacs instances scattered throughout tmux or terminal windows, created and killed as needed. Now that I'm thinking about it, this and tabs help me map my work space mentally in a way that hidden buffers (or directory trees) don't.

Re: Making Emacs Popular Again

#225
post #191
post #170

Earlier quoted context omitted.

I'm genuinely curious: do you not read through code from top to bottom? That's a very common thing that I do, and using the mouse is a comfortable way of accomplishing it.

If you want to go to the next page (screen) of code, isn’t the keyboard just as comfortable? If you want to go down until you find the thing you’re looking for, wouldn’t a search using the keyboard be potentially more comfortable?

I like how I can control the rate at which I scroll with the mouse more easily than with the keyboard. It's a more intuitive movement that I can adjust to match the speed of my reading.

Re: Making Emacs Popular Again

#226
post #198

Earlier quoted context omitted.

> The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project. I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributi…

Consider me very regretful indeed. Most people who moan seem to have nothing to contribute, well I got it very wrong this time. Apologies to @JoshTriplett if you're reading this, and Ill check out your stuff tomorrow. Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.

I appreciate the sentiment. I would gently suggest focusing the regret on the message rather than the recipient; it wouldn't have been better if written to a novice user.

Re: Making Emacs Popular Again

#227
It really depends on your needs. For modern development of projects with bloated file structures, having a hand-holding GUI like VSC that tames the file structure of the project really is nice.

If you're just occassionally dropping into headless filesystems to do some text editing, you're not going to invest in learning a new paradigm and you will likely use whatever default editor is presented to you. That is typically vim. For those who mindfully choose to set out and learn a new paradigm because they've decided to invest in a long-term time-saving skill, I doubt the vim/emacs divide is quite as stark as the numbers mentioned in the article.

Re: Making Emacs Popular Again

#228

Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim. I think it comes down to performance, especially startup time. Emacs developers have never cared much about i…

[deleted]

Re: Making Emacs Popular Again

#229
post #93

I wish Vim users and Emacs users would unite to improve Spacemacs. It's really a great idea IMO, have the editing power of Vim with the flexibility and elegance of the Emacs environment. Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was rig…

Vim and Emacs have too many philosophical differences for this to work. For example, emacs doesn't have a fixed concept of what a paragraph should be. Instead, it leaves that up to the major mode. This is fundamentally incompatible with vim's paragraph motions which are determined by empty lines and remain the same regardless of file type. As a very long-time Vim user, I prefer that my editing commands be predictable…

Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly?

Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.

>Vim feels like a complete set of high quality, manual woodworking tools.

They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").

They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?

You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.

The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.

Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.

I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.

Re: Making Emacs Popular Again

#230
post #200

Earlier quoted context omitted.

Re copyright, what would you prefer? Alternatively, what would you even do with the copyright to your fixes and additions to GNU emacs?

a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all. it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL. at the end of the day a lot of…

I can relate. Used to be a hardcore GNU fan, but these days I'm probably closer to sqlite thinking (public domain, but work hard to avoid contamination).

As for contributions, presumably GNU wants ownership, but do they have a problem with assigning back what amounts to public domain rights to the author?

And I suppose, for most contributions, does it really matter? The awful truth is that I can't think of anything I've ever written that had freestanding value, as opposed to value as an enhancement to something else.

Post reply on HN