Hacker News new | past | comments | ask | show | jobs | submit login

They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.



Emacs isn't really a terminal app, though. CLI is just one of several frontends.

And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835


Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.


> Platform conventions matter because uniformity matters.

There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.

> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.

I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.

I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.

Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.

I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.


This isn't even true on virtually any macOS terminal, which use Command-C (just like a web browser). The problem isn't the terminal, it is the operating system.


> Platform conventions matter because uniformity matters

Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.

If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).

If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.

That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.


You mean like yy versus ctrl+c? You can definitely use a Vim browser/OS extension but Vim does it that way because the creator, I suppose, perceived that his user interface is better than what's already there. And I tend to agree. I don't need uniformity if it'll be inefficient.


vi and emacs don’t follow desktop conventions because they predate desktop conventions (and vim of course follows vi)


I have C-f mapped to Find and C-v mapped to Paste on vim. It’s trivial to do (one line per mapping) but yes I would be considered an heretic by some vim purists. They tend to go the other way around, using plugins to make their browser behave like Vim. Which makes more sense than it might seem; if you spend a lot of time on the command line vim bindings are better supported than ctrl c ctrlv


I never really see the need to do that remapping. By default in a Linux terminal Ctrl-Shift-v is paste and Ctrl-Shift-c is copy.

On macOS there's an extra set of keys so Cmd-v is paste and Cmd-c is copy.

I think I committed that to muscle memory so long ago that I never really think about it unless someone asks.

Not sure about Windows as I haven't used it professionally since 2006 but I'd guess it's the same as Linux.


> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.

M-x cua-mode resolves this in Emacs. I don't use it, because I've been using Emacs for slightly longer than the CUA has existed.


Exactly. But I'm sure there are extensions to fix the web browser.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: