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.
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.
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.)
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.
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.
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.
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.
"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 :)
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.
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.)
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.).
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.
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.
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'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?
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.
59 comments
[ 3.1 ms ] story [ 108 ms ] threadIn 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 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.
Yeah, I want distinctly none of that.
(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.)
https://news.ycombinator.com/item?id=13578256
https://news.ycombinator.com/item?id=7511979
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...
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.
Uh, no. I'm pretty much always in Emacs. Except when I'm posting a comment on HN :)
https://www.emacswiki.org/emacs/Edit_with_Emacs
or
https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
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.
https://addons.mozilla.org/firefox/addon/firemacs/
M-x eshell
M-x term
As the author points out, the exact cursor position in some apps is different on Windows, but he shortcut is always CTRL+{direction}
EDIT: Unless you do this: https://apple.stackexchange.com/questions/136928/using-alt-c...
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.).
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.
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.
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.
Too bad it isn't a standard thing. I liked it a lot.
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...