This is one of the most infuriating things about Macs for me. Maybe Vim/Emacs aside, I've found word jumping and Home/End operations to be absolutely consistent on Windows, but just about every OSX app seems to have a different shortcut.

As the author points out, the exact cursor position in some apps is different on Windows, but he shortcut is always CTRL+{direction}

Really? On Mac I've found it very consistent that alt+left/right jumps forward/back one word, alt+up/down jumps to start/end of paragraph, cmd+left/right jumps to end of line, cmd+up/down goes to beginning or end of all text (like Home/End). This is the case for me in Sublime, RubyMine, Xcode, Firefox, Chrome and any other app I've used in recent years - which apps are you using that don't follow these conventions?

In Chrome on OS X it differs whether I'm casting my screen or not, whether Ctrl+←/→ move me to the start/end of a line or document. (I can't figure out how to move to the end of a line while Chromecasting. It is beyond frustrating.)

^e for end-of-line, ^a for beginning-of-line. ^p for previous-line, ^n for next-line. All far more ergonomic than arrow keys.

http://www.bigsmoke.us/readline/shortcuts they're just GNU Readline shortcuts of copies of those :)

Esp when you remap caps lock to control as the Lord intended it to be.

iTerm2 doesn't

EDIT: Unless you do this: https://apple.stackexchange.com/questions/136928/using-alt-c...

Terminals are, generally, expected to behave like terminals, which brings along a host of legacy compatibility things about how keyboards used to work over the past 40 years. Not saying that’s an excuse, or that they shouldn’t try to, but balancing “sane modern defaults” vs “sane-ish defaults from the 70s that everyone’s used to now” is hard.

EDIT: To elaborate a little… Terminals pre-date arrow keys, which is partly why there are lots of default “movement” keybindings that don’t use them (ctrl-a, ctrl-e, ctrl-b, ctrl-f, ctrl-n, ctrl-p, etc.).

iterm2, at least that's what it defaulted to for me, uses ctrl + direction instead of alt + direction.

Mmm, I'd give the points for consistency to the Mac here. I bet still, in 2017, there are text inputs in Windows apps that draw a little rectangular character when you type Ctrl + Backspace instead of doing the right thing.

In my experience apps frequently hard-code their keyboard behavior (Slack, Gimp), and websites hard-code shortcuts (Gmail, Atlassian products) based on detected OS, so even if you set up shortcut overrides like Ctrl-V to paste, some apps will glitch or simply fail in odd ways.

The lack of consistent behavior for Home and End is one of the things that irked me when using Macs back in the late 1990s. Back then, first-party Apple keyboards included Home and End keys so it was fairly inexcusable.

Today, although the situation hasn't improved if you press Home or End, at least first-party Apple keyboards are essentially always laptop keyboards (even when sold for use on desktop computers). So you don't even have a Home or End key to press. I suppose that's an improvement.

The Home/End usage on Mac OS seems completely worthless to me. I find Home/End useful for going to the start or end of a line respectively, so having it jump to the top or bottom of a document (and having the frameskippy scrolling slowly catch up) isn't helpful.

Yes! This along with the lack of win + arrow drives me absolutely batty.

Yes, the win+arrow shortcut is one of the few window management things from Windows that I miss on Mac - so I use HyperDock to get that functionality (and the similar drag-and-snap-to-edge-of-screen window resizing). I have a feeling you can find free tools to do the same too if you search a bit as well

This is my second hangup! A coworker of mine recommended https://www.spectacleapp.com/ which does a great job mimicking the Windows native docking commands.

I don't want consistent behavior everywhere; I want contextual behavior. In an English text, cursor should stop at different locations than in a programming language.

In other words, the default algorithm used by a all-purpose editor (Notepad) is "don't offend too many users too much", not "we know that users are using this editing control for code, hence movement to underscores".

I think I'd prefer consistent behavior. Contextual behavior would be more efficient, but it would also take longer to internalize.

I use ctrl+left/right all the time (well actually ctrl+f/b because I use emacs), and I can't actually tell you where the cursor would stop, but my fingers do... It's become muscle memory. It would take longer for my fingers to understand contextual behavior.

Not to mention that it's impossible to write a general contextual solution, so in some contexts it would not behave properly. I would rather have a solution that works consistently across all contexts than one that's perfectly contextual in some contexts.

(Also the reason I prefer Vim/Emacs over language-specific IDEs. I like to use the same editor tools for all sorts of writing – and good tools are general enough to work that way.)

Also, what happens when you mix the two, ala comments.

Isn't the point of contextual behavior to consider things like that? So it would act differently in comments.

Absolutely, simple examples would be automatically wrapping comments to 80 characters, adding the comment sigil on the next line when you press enter, enabling spell checking, turning on syntax highlighting if it detects a docstring, changing the semantics for what qualifies as a word, statement, paragraph/block.

So my editor starts applying different keyboard shortcuts as I scroll through the same file?

Yeah, I want distinctly none of that.

And that's the exact reason there are so many text editors to choose from ;)

The same shortcut 'move on a bit more than right arrow'

This is discussed a bit in "Why Don't We Have a General-Purpose Tree Editor? (2014)"

https://news.ycombinator.com/item?id=13578256

https://news.ycombinator.com/item?id=7511979

This is where I just gave up and just started using Vim plugins wherever possible.

Edit: He calls out IDEs as a place you can't use Vim. But I think most widely used IDEs tend to have Vim plugins...

Ironically, Vim IDE plugins often have slightly different behavior on seemingly identical key buildings...

I just wish that Vim plug-ins meant that the IDE would actually embed Vim inside the IDE and do some vimscript magic to do integration. Vim plug-ins that just simulate the default Vim keybindings are just sad.

But some editors do vim integration really well. I was quite amazed when I discovered that the VS Code vim plugin is actually fully compatible with multiple cursors.

I'm guessing these plugins have improved in the last couple of years? Every time I've tested them, I've been somewhat disappointed. Part of it is probably that I expect the Vim experience to include

1. The full command set, like :set paste and :set foldmethod=indent; and 2. Some basic plugins, like EasyMotion and surround.vim.

Not even evil-mode gets this completely right, but it's close enough to be worth it.

Same here. I'm really happy about the plugins. They allow me to stay with vi-style of editing almost entirely. I use them for JetBrains IDEs, Atom, zsh, Firefox, Chromium and Emacs.

"Some of you might be thinking, just use vim or emacs and you don't have to worry about using Ctrl+Left and Ctrl+Right because there are better ways of navigation. But you are not always in vim or emacs, sometimes you are in a browser or an IDE."

Uh, no. I'm pretty much always in Emacs. Except when I'm posting a comment on HN :)

And even then you could be in emacs:

https://www.emacswiki.org/emacs/Edit_with_Emacs

or

https://addons.mozilla.org/en-US/firefox/addon/its-all-text/

Not to be forgotten:

https://addons.mozilla.org/nl/firefox/addon/firemacs/

Because even for things that are not text, there is no reason not to stick to Emacs.

Non-Dutch link:

https://addons.mozilla.org/firefox/addon/firemacs/

Also, somewhere in GNOME settings, there's a setting to enable "emacs mode", which lets you use ^a, ^e, ^k, ^y in normal textboxes.

What about when you're in shell?

There is never a reason to leave Emacs.

M-x eshell

M-x term

I wish. Every now and then I try and use emacs term. It is slow, doesn't handle screen resizes well, and God forbid you try and use tmux within emacs term. You'll be sorry.

I prefer M-x shell - simple bash syntax and full emacs editing capabilities. But it's also painfully slow. Typing ls -l in the wrong directory and I'm tempted to kill the buffer. On the other hand, this encourages me to use M-x dired which is way better anyway.

I know it's not the same, but you're supposed to use multi-term to manage multiple terminal buffers.

bash has emacs keybindings by default

I'm mildly suspicious that this article is satire.

It's not that I don't sympathize--I have a personal laptop on Ubuntu, work computer on OSX from which I sometimes VN into a machine with CentOS, and using spacemacs means I often context switch between a set of shortcuts which takes from both emacs and vim. However, I feel that, of the things which need to be standardized across platforms, the CTRL+* shortcuts really is low priority.

If it's one of your primary tools of navigating code without using the mouse, it's going to be a concern.

For example, in Visual Studio ctrl-x with nothing selected will cut the whole line, but very few other programs support that. As well as using to move code around, I use it to delete lines (ctrl-l is better supported, but you can still do ctrl-x with your hand on the mouse). So when it doesn't work in Notepad++, it's quite annoying as it breaks your flow. I'm using a plugin to simulate it, but it's not quite right still.

One of the another thing that can catch you out is that the various MS code editors behave differently depending on the language you're using, SQL Management Studio will treat anything wrapped with []s as a single string, but while in text strings of SQL in Visual Studio it will stop on each bracket. It end up being quite annoying you can't mark a string in VS as a sql string when you want to make a small tweak or add an extra column.

It's muscle memory, and so it's going to annoy you when it doesn't work, it makes you feel clumsy in the new environment.

I had the same problem with vscode.

I filed this issue: https://github.com/Microsoft/vscode/issues/32246

Rather than wait, I ended up creating this extension last weekend to do it the way I wanted it to: https://marketplace.visualstudio.com/items?itemName=stringha...

I like how Sublime does this. On the Mac, if you use Ctrl instead of Option, it gives you the ability to delete individual words in a camelCase or snake_case identifier.

For the sake of completeness: on Windows and Unix Ctrl goes over entire words while Alt considers camelCase and under_score.

Are you saying Alt+Left or Alt+Right work? They don't work for me on Windows or Ubuntu Linux.

Strange, works fine here. Dev Channel build 3142 if that matters.

sublime has a configuration option ("word_separators") that lets you set which characters are considered to separate words. you can add the underscore to this option.

I did not know that, mostly because I had ctrl+arrows uselessly bound to Mission Control. Thanks!

I'm at the point we're if I'm typing anything more than a few sentences I'll write it in Vim and just copy/ paste.

Komodo Edit/IDE had some command for selecting the word which is touched by the cursor (|foo, f|oo, foo| -> would select "foo"). It's similar to double-clicking a word. I used Ctrl + Shift + Down to activate it.

Too bad it isn't a standard thing. I liked it a lot.

I've always thought that Ctrl+Left and Ctrl+Right were borrowed from Emacs M-b and M-f. Isn't it true? Are there older programs using these key bindings?

Oh, I thought this was a political article with a geeky pun on alt-right and alt-left...

What? Are they out of control?...

Maybe we should rebind them to Alt+left, and Alt+Right.