My favorite way to move around in Emacs, and to move text around, is via avy-mode: https://github.com/abo-abo/avy. If you have not experienced avy-mode, give it a try, I think you will wonder how you ever got along without it.
I don't think this was the first package to use the tree idea, but `avy-goto-char-timer` is amazing and is new since the first time I tried it. After activating goto with a key press you type as many characters as you like to get where you want. Often you can get straight there if it's something unique, but if not then it goes to the tree. It's amazing how quick you get at typing "def" or something to get to a Python function definition, for example.
What I love about functionality like this is it's completely generic. It's just text. I don't need any lsp support to get me "go to def" or something. I can open a file in a language I've never seen before and use the exact same interface I'm used to to navigate around.
I have it installed and have the main commands bound to convenient keys. But I’m so used to moving via words, paragraphs and isearch that the only time I remember it is when targeting symbols.
About my only usage is to augment my isearch. I frequently use isearch to navigate to a place on screen, but sometimes there are so many matches it would take a lot of repeated "C-s" to get there. I have "C-'" bound to avy-isearch (from within isearch), which instantly turns that into one or two keystrokes to filter down.
(or I could pick up the mouse, I know, but that's not why we're here)
I haven't tried Avy, but I gave ace-jump mode a shot. Maybe I didn't give it enough time, but it just never felt fast for me. The problem is the eye -> hand -> eye feedback loop latency. If I want to jump to a given place, I need invoke ace-jump, wait to read what letter ace jump assigns my destination, press that letter, read the new letter, and repeat until the destination becomes unambitious. It just feels slower than navigating by sexp or whatever.
Maybe if I combine it with eye tracking so I can limit letter assignment to the foveated region I can reduce the cycle count and make this style of navigation win.
Just as an idea: you could try a more complicated setup where physical key positioning matches the movement direction, so Q would always be upper-left. Then at least the first jump you'd be able to do without reading, though then for the final jump you'd still need to react to feedback
(or for jumping to an arbitrary area on the screen you could use a fixed "grid" that could also allow doing the first jump blindly)
I was excited for avy until I realized its purpose is only to move the cursor to a place visible on the screen. It does nothing a mouse can't do with one click.
(This is my understanding at least; I'm open to correction.)
I'm a lover of Vim bindings, and so I appreciate keyboard controls, but where Vim enables working with files and text in a general and powerful way, avy enables avoiding one click with the mouse. I don't use Vim to avoid the mouse, I use it so I can hack some Vim macros together when I'm editing text on a text-level. Vim (or Emacs) is an eternal tool that can do big things, avy just positions my cursor.
Definitely not it's purpose. Avy can be used to select a word, line, or region. One action is move to it. But it can also, in it's own words, copy, yank, zap to, transpose, teleport, kill, mark, ispell, org-refile, and custom actions.
I've bounced off that blog post in the past, because it makes it appear the first step to doing something in avy is to position all my files and "windows" (a "window" is an editing pane inside Emacs) in some clever way, and after I got all that setup, and the windows are all looking at just the right parts of the files, then I can move a paragraph from one window to another with just a few special keystrokes.
I feel like moving from a large monitor to a small monitor would limit the usefulness of avy; it's weird that the physical size of a monitor would limit a tool like this.
If I can only see 3 lines of text at a time (maybe an accessibility thing), the usefulness of Vim-bindings is not significantly reduced. Is the same true for avy?
Again, I'm willing to learn that I was wrong, but this is the specific issue that ended my enthusiasm for learning avy.
> It does nothing a mouse can't do with one click.
But the you'd need to take the hands off keyboard, also it might be slightly more precise as a typo is less likely than a less-than-perfect mouse movement
Don't underestimate the advantage of being able to move the cursor anywhere in a few clicks without having to take your hands off the keyboard. It is much faster than a mouse. Also, you can save your elbows the pain of constantly reaching over for the mouse.
avy does more than just jump the cursor to a specific place. It also allows you search for, copy and move text round without needing to move your cursor to that text. It is extremely easy to use and very efficient.
I used Emacs for several years before I discovered "project" (it's built in). If you're navigating dired trees or similar to find files or grep for strings in groups of files, this is like magic:
C-x p f (find any file in the current "project", e.g. git repo)
C-x p v (grep the whole project super fast)
It's embarrassing how long it took me to realize it was there all along. :-)
I am consistently using `m` for marking relevant files/directories in the dired mode and then `A` to find a regex among all included files. It does not seem that I miss anything by not relying on such a project approach.
> A note on defaults. A problem with customised setups is that they mean you can’t pick up your friend’s Emacs setup and use it
> can be mitigated by sticking with the ‘language’ of the system
No? You're still going to be mistaken a lot of the time to the point of making your experience unpleasant. And how often do you really pick up your friend's Emacs setup for this to outweigh the other 99% of your time?
> Emacs has pretty clear (if arguably not very good) conventions
Indeed, so it's a waste of productivity and ergonomics to rely on it
In short: turn Emacs navigation into Vim-like navigation, make the editing modal, and thus make navigation hyper-efficient. (If you like the idea, I would suggest taking a look at evil-mode if you come from Vim, or god-mode and devil-mode if you already are used to Emacs.)
A few useful pieces of advice beside that, too. The workflow the author describes is not how I prefer to do things, but the author mentions a number of important capabilities to be aware of: operating at sexp level, subword motion, etc. Narrowing and folding, which I like to use, are not mentioned.
No mention of LSPs or compilers, but these are their own large topic.
I am going to sound like a mouse-using Luddite but I configure .emacs with a one line addition to allow a mouse click to reposition the cursor and fast scrolling works also.
I have been using Emacs for 40 years, and decades ago, before ground based fiber, it was a 2 satellite bounce ping time between my office in San Diego and the 38 data collection sites around the world for a DARPA project and the mouse click in Emacs saved a ton of time.
In the present time, I use Emacs on remote servers and local editing, either using my iPad Pro, and Apple Mouse, and a Studio monitor, or a MacBook - on both environments I find occasional mouse clicks or fast scrolls using mouse or Apple trackpad still saves time even in zero latency environments.
Grokking efficient navigation within Emacs buffers completely removed the necessity for scrolling for me - most of the time it's all about finding specific content - using consult-line, imenu, various jump methods, ex-commands, etc. - there are so many different tools in Emacs to rapidly move around, it makes scrolling feel like useless fiddling, not efficiency.
Mouse is nice for operations that don't require exact precisioning - like resizing windows in your WM, or another cool albeit pretty rare and gimmicky use for it is setting mouse clicks for multiple-cursor selection - feels like shooting lasers in a video-game, i.e.,
Selecting regions of text with mouse? Why, if vim-navigation lets me quickly grab: anything between things - parens, brackets, quotes, etc.; anything including those things; anything up to the char; including the char; until some text; backwards up to the text, etc.
With expreg (expand-region) I can quickly expand and contract my selection - it's so smart - it first selects the word, then line, then sentence, then paragraph - similarly it expands/contracts structurally for code, it understands org-mode, yaml, markdown and Lisp structure. After developing the muscle memory for these things, selecting and moving text with the mouse feels so crude and annoyingly inaccurate. Makes me feel sorry for the vscode kiddos to be honest.
Tramp isn't an option? I know people say it's slow (it is) and synchronous (yes, it is) but I'd rather pay a high latency cost only upon saving than a moderate one ALL THE TIME.
Seems to be an intro to a kind of but lite weight vi mode. I tend to like the regular mode in Emacs.
Maybe a bit OT, but I think I saw here a week or more ago a post about magit, I am toying with using it, but seems to be a rather big package. Plus I wonder why dash is needed:
Thanks for sharing. I've been off editor hopping for quite some time, nowadays I just use some pre-defined configuration like Doom Emacs, occasionally I try to build some environment, with AI help, from "scratch" for fun and curiosity.
I really like Emacs' flexibility + evil-mode and reactivity, recently I searched for something similar and found Lem: https://github.com/lem-project/lem, looks promising, I'll try it out and compare with Emacs when I have the chance and time.
In my opinion there's no reason to stick to the "old school" / classic emacs controls. They're archaic at this point.
I am an experienced emacs user and I still use CUA mode, arrow keys, and I wrote a package which completely overhauls built-in "word jumping" commands (called bbww on melpa.)
You don't need to worry about upholding traditional emacs orthodoxy
Disagree with this just because it makes everything else easier. The more you stick to common key bindings, the more intuitive various packages will be. Eg navigating lines vs blocks in a magit diff block is C-n and N respectively. Copying a full hash is M-w. All these bindings are intuitive “overlays” on conventional bindings.
Emacs shines when packages combine to form a whole greater than the sum of its parts. Changing basic key bindings is the quickest way to vitiate that symbiosis.
Unfortunately.
And while they may be old school, traditional, and orthodox, they are by no means idiosyncratic. They’re widely supported: readline , bash, everywhere on macos, even modern browsers. Eg you can actually paste in bash: try killing something with C-w or C-k, and paste it back using C-y. Or transpose arguments using C-M-t. Navigate suggestions in Firefox using C-n and C-p. Bash even supports undo using C-/.
All to say: learning emacs movement keys pays off.
I've found it crucial to have Control mapped to the keys immediately next to and on both sides of the spacebar. Thumbs are stronger than pinkies for modifying keypresses.
Yes, that's a good idea since Control is the most common keybinding modifiers, so helps in other apps as well (likewise, using Cmd on a Mac would be preferable to using the literal Control)
Meh. I'm not a fan of modal interfaces. But if it works for you, then knock yourself out. I appreciate the write-up here. I'll give it a try to see if I can see what the author is talking about. The overwhelming majority of code I write now is in snippets inside text documents (think Knuthian Literate Programming) so I don't know how that would work w/ the author's modal setup. But they went to the trouble of documenting it, and it seems sort of like what `vi` people are always yammering about. Seems a decent idea to try to understand it.
I'm assuming you're using Emacs (otherwise why would you be commenting in this thread, right?). It's weird to hear that from an Emacs user - it's inherently a modal editor - keycords are modal, isearch is modal, repeat-mode is modal, transients are all modals with states. Evil-mode only adds some consistent "language" and structure to deal with modality, there's nothing much to it.
Idea of vim-navigation is actually pretty neat thing - absolutely beautiful, practical model. Its biggest problem is that it encapsulates some tacit knowledge - nobody can really explain the benefits of it to anyone until they try it for some time and it "clicks". I suppose just how learning to ride a bike may work differently for different people - it also takes different amount of time and effort. But once you figure it out - there's really no going back - no reason. It's very rare to meet people who've mastered it and then willingly stopped using it.
There's no conceptual difference in switching between navigation and insert modes in Vim and e.g. C-c C-c/C-d in Emacs - the only difference that you're in-between state more often, but once muscle memory trained, it becomes second nature - you don't even think about what mode you're actually in - it becomes very fluid and consistent flow state that allows you to very efficiently navigate and deal with text - with any kind of text - plain and structured.
Also, I find that mastering efficiency in Emacs using only vanilla keybindings is a bit harder than becoming a keyboard-maestro with the help of evil-mode or similar modal modes like meow. I've been working over a decade in various teams where people use Emacs, and evil-mode users typically figure out things much faster, while those sticking to native keybindings, don't even discover some great features of Emacs for years.
I really like this, it's a bit hardcore, but for someone that really cares about efficiency (whether it is worth it or not - debatable), this is great.
Though I have one minor nit against one point, that I've seen basically in every similar article:
> This means no arrow keys and no mouse
I use Neovim daily, and there is no denying that 98% of the time, using mouse is less efficient than doing a fancy search or jump. But for the remaining 2%, it's provably true that mouse is better - like, selecting an arbitrary block of code (without {} or any keyword to hang on). So I always recommend leaving the mouse enabled. Just use it when it makes sense.
> But for the remaining 2%, it's provably true that mouse is better
This is definitely true. The thing is that using the mouse is a habit, and until you break it, people find themselves instinctively using it in situations where it would be better to use the keyboard. So the 'hard' mouse disable is more of a 'going cold-turkey' type thing to try and break the habit. I agree that once it's broken it makes sense to relax this.
If you're moving in emacs using per-line/character commands, you're definitely not using emacs as efficiently as you could be.
So the distance in efficiency (and therefore efficacy) between mouse and keyboard is rather a gulf, once you've paid the cost of learning the extra emacs commands.
v, then t/T or f/F if staying on the same line, j and k if it’s within a couple line, / or ? for anything else. With the repetition commands ./,/n/N if I do not land at the correct place.
This is a much better alternative to using evil-mode, kudos. It's absolutely right that losing access to the "lingua franca" of emacs keybinds makes the whole thing kind of pointless, unless you rebind everything, of course.
Hmm, would be interesting to see a "race" between this and isearch; from the examples, it looks like this has an advantage only if you have lots of similar strings, so "the one you're looking at" vs. "typing more letters of the word" is an advantage? (externally timed, see The Humane Interface for details on how self-reporting doesn't actually work to measure this kind of thing)
If your workflow feels comfortable there's really no need to change it in my opinion. The reason I do this is to avoid the frustrating feeling that I'm spending all my time moving around in the text file rather than actually making the program. It's less about speed and more about feeling good while programming.
You really only need a few shortcuts to feel comfortable. The ones in the basic tutorial are pretty much all I use, but I also enable god-mode to avoid having to keep Ctrl pressed as that hurts.
My favorite way to move around in Emacs, and to move text around, is via avy-mode: https://github.com/abo-abo/avy. If you have not experienced avy-mode, give it a try, I think you will wonder how you ever got along without it.
I don't think this was the first package to use the tree idea, but `avy-goto-char-timer` is amazing and is new since the first time I tried it. After activating goto with a key press you type as many characters as you like to get where you want. Often you can get straight there if it's something unique, but if not then it goes to the tree. It's amazing how quick you get at typing "def" or something to get to a Python function definition, for example.
What I love about functionality like this is it's completely generic. It's just text. I don't need any lsp support to get me "go to def" or something. I can open a file in a language I've never seen before and use the exact same interface I'm used to to navigate around.
I have it installed and have the main commands bound to convenient keys. But I’m so used to moving via words, paragraphs and isearch that the only time I remember it is when targeting symbols.
About my only usage is to augment my isearch. I frequently use isearch to navigate to a place on screen, but sometimes there are so many matches it would take a lot of repeated "C-s" to get there. I have "C-'" bound to avy-isearch (from within isearch), which instantly turns that into one or two keystrokes to filter down.
(or I could pick up the mouse, I know, but that's not why we're here)
Yes, that's a "paradigm shift" in behavior, so you need to force yourself to use it for some time to evaluate it properly
I haven't tried Avy, but I gave ace-jump mode a shot. Maybe I didn't give it enough time, but it just never felt fast for me. The problem is the eye -> hand -> eye feedback loop latency. If I want to jump to a given place, I need invoke ace-jump, wait to read what letter ace jump assigns my destination, press that letter, read the new letter, and repeat until the destination becomes unambitious. It just feels slower than navigating by sexp or whatever.
Maybe if I combine it with eye tracking so I can limit letter assignment to the foveated region I can reduce the cycle count and make this style of navigation win.
Just as an idea: you could try a more complicated setup where physical key positioning matches the movement direction, so Q would always be upper-left. Then at least the first jump you'd be able to do without reading, though then for the final jump you'd still need to react to feedback (or for jumping to an arbitrary area on the screen you could use a fixed "grid" that could also allow doing the first jump blindly)
I was excited for avy until I realized its purpose is only to move the cursor to a place visible on the screen. It does nothing a mouse can't do with one click.
(This is my understanding at least; I'm open to correction.)
I'm a lover of Vim bindings, and so I appreciate keyboard controls, but where Vim enables working with files and text in a general and powerful way, avy enables avoiding one click with the mouse. I don't use Vim to avoid the mouse, I use it so I can hack some Vim macros together when I'm editing text on a text-level. Vim (or Emacs) is an eternal tool that can do big things, avy just positions my cursor.
Definitely not it's purpose. Avy can be used to select a word, line, or region. One action is move to it. But it can also, in it's own words, copy, yank, zap to, transpose, teleport, kill, mark, ispell, org-refile, and custom actions.
https://karthinks.com/software/avy-can-do-anything/
I've bounced off that blog post in the past, because it makes it appear the first step to doing something in avy is to position all my files and "windows" (a "window" is an editing pane inside Emacs) in some clever way, and after I got all that setup, and the windows are all looking at just the right parts of the files, then I can move a paragraph from one window to another with just a few special keystrokes.
I feel like moving from a large monitor to a small monitor would limit the usefulness of avy; it's weird that the physical size of a monitor would limit a tool like this.
If I can only see 3 lines of text at a time (maybe an accessibility thing), the usefulness of Vim-bindings is not significantly reduced. Is the same true for avy?
Again, I'm willing to learn that I was wrong, but this is the specific issue that ended my enthusiasm for learning avy.
I would agree that the usefulness is reduced if you have tight vertical space constraints (3 lines of text).
> It does nothing a mouse can't do with one click.
But the you'd need to take the hands off keyboard, also it might be slightly more precise as a typo is less likely than a less-than-perfect mouse movement
It's really a selector or a filter. It's power comes from combining it with other tools.
Can you elaborate. I just use it by itself and think it is wonderful, but I am curious for some examples of using it with other tools.
EDIT: I just looked at the link posted by lvass and I understand now. So cool! I am going to update my workflow.
Don't underestimate the advantage of being able to move the cursor anywhere in a few clicks without having to take your hands off the keyboard. It is much faster than a mouse. Also, you can save your elbows the pain of constantly reaching over for the mouse.
avy does more than just jump the cursor to a specific place. It also allows you search for, copy and move text round without needing to move your cursor to that text. It is extremely easy to use and very efficient.
[dead]
I used Emacs for several years before I discovered "project" (it's built in). If you're navigating dired trees or similar to find files or grep for strings in groups of files, this is like magic:
C-x p f (find any file in the current "project", e.g. git repo)
C-x p v (grep the whole project super fast)
It's embarrassing how long it took me to realize it was there all along. :-)
I am consistently using `m` for marking relevant files/directories in the dired mode and then `A` to find a regex among all included files. It does not seem that I miss anything by not relying on such a project approach.
> A note on defaults. A problem with customised setups is that they mean you can’t pick up your friend’s Emacs setup and use it
> can be mitigated by sticking with the ‘language’ of the system
No? You're still going to be mistaken a lot of the time to the point of making your experience unpleasant. And how often do you really pick up your friend's Emacs setup for this to outweigh the other 99% of your time?
> Emacs has pretty clear (if arguably not very good) conventions
Indeed, so it's a waste of productivity and ergonomics to rely on it
If I couldn't give Emacs incredibly specialized behavior, I wouldn't even use it.
In short: turn Emacs navigation into Vim-like navigation, make the editing modal, and thus make navigation hyper-efficient. (If you like the idea, I would suggest taking a look at evil-mode if you come from Vim, or god-mode and devil-mode if you already are used to Emacs.)
A few useful pieces of advice beside that, too. The workflow the author describes is not how I prefer to do things, but the author mentions a number of important capabilities to be aware of: operating at sexp level, subword motion, etc. Narrowing and folding, which I like to use, are not mentioned.
No mention of LSPs or compilers, but these are their own large topic.
I am going to sound like a mouse-using Luddite but I configure .emacs with a one line addition to allow a mouse click to reposition the cursor and fast scrolling works also.
I have been using Emacs for 40 years, and decades ago, before ground based fiber, it was a 2 satellite bounce ping time between my office in San Diego and the 38 data collection sites around the world for a DARPA project and the mouse click in Emacs saved a ton of time.
In the present time, I use Emacs on remote servers and local editing, either using my iPad Pro, and Apple Mouse, and a Studio monitor, or a MacBook - on both environments I find occasional mouse clicks or fast scrolls using mouse or Apple trackpad still saves time even in zero latency environments.
> fast scrolling works also
Grokking efficient navigation within Emacs buffers completely removed the necessity for scrolling for me - most of the time it's all about finding specific content - using consult-line, imenu, various jump methods, ex-commands, etc. - there are so many different tools in Emacs to rapidly move around, it makes scrolling feel like useless fiddling, not efficiency.
Mouse is nice for operations that don't require exact precisioning - like resizing windows in your WM, or another cool albeit pretty rare and gimmicky use for it is setting mouse clicks for multiple-cursor selection - feels like shooting lasers in a video-game, i.e.,
Selecting regions of text with mouse? Why, if vim-navigation lets me quickly grab: anything between things - parens, brackets, quotes, etc.; anything including those things; anything up to the char; including the char; until some text; backwards up to the text, etc.With expreg (expand-region) I can quickly expand and contract my selection - it's so smart - it first selects the word, then line, then sentence, then paragraph - similarly it expands/contracts structurally for code, it understands org-mode, yaml, markdown and Lisp structure. After developing the muscle memory for these things, selecting and moving text with the mouse feels so crude and annoyingly inaccurate. Makes me feel sorry for the vscode kiddos to be honest.
How do you go about editing via ipad, I'm just getting into this whole world, and am finding it difficult to figure out a system.
I use an app like Terminus or Prompt to access a remote server. I have a keyboard and a mouse for my iPad Pro.
Tramp isn't an option? I know people say it's slow (it is) and synchronous (yes, it is) but I'd rather pay a high latency cost only upon saving than a moderate one ALL THE TIME.
It is an option. You are talking with an old man (me!) and I just usually like simple Emacs setups, also using mosh and ssh and tmux.
Seems to be an intro to a kind of but lite weight vi mode. I tend to like the regular mode in Emacs.
Maybe a bit OT, but I think I saw here a week or more ago a post about magit, I am toying with using it, but seems to be a rather big package. Plus I wonder why dash is needed:
https://emacsdocs.org/docs/magit/Installing-from-the-Git-Rep...
In anycase to avoid downloading additional packages I may use Melpa
https://emacsdocs.org/docs/magit/Installing-from-Melpa
Thanks for sharing. I've been off editor hopping for quite some time, nowadays I just use some pre-defined configuration like Doom Emacs, occasionally I try to build some environment, with AI help, from "scratch" for fun and curiosity.
I really like Emacs' flexibility + evil-mode and reactivity, recently I searched for something similar and found Lem: https://github.com/lem-project/lem, looks promising, I'll try it out and compare with Emacs when I have the chance and time.
In my opinion there's no reason to stick to the "old school" / classic emacs controls. They're archaic at this point.
I am an experienced emacs user and I still use CUA mode, arrow keys, and I wrote a package which completely overhauls built-in "word jumping" commands (called bbww on melpa.)
You don't need to worry about upholding traditional emacs orthodoxy
Disagree with this just because it makes everything else easier. The more you stick to common key bindings, the more intuitive various packages will be. Eg navigating lines vs blocks in a magit diff block is C-n and N respectively. Copying a full hash is M-w. All these bindings are intuitive “overlays” on conventional bindings.
Emacs shines when packages combine to form a whole greater than the sum of its parts. Changing basic key bindings is the quickest way to vitiate that symbiosis.
Unfortunately.
And while they may be old school, traditional, and orthodox, they are by no means idiosyncratic. They’re widely supported: readline , bash, everywhere on macos, even modern browsers. Eg you can actually paste in bash: try killing something with C-w or C-k, and paste it back using C-y. Or transpose arguments using C-M-t. Navigate suggestions in Firefox using C-n and C-p. Bash even supports undo using C-/.
All to say: learning emacs movement keys pays off.
> Changing basic key bindings is the quickest way to vitiate that symbiosis.
Unless you change those as well
> All to say: learning emacs movement keys pays off.
It can also cost you RSI, so not worth it
I've found it crucial to have Control mapped to the keys immediately next to and on both sides of the spacebar. Thumbs are stronger than pinkies for modifying keypresses.
Yes, that's a good idea since Control is the most common keybinding modifiers, so helps in other apps as well (likewise, using Cmd on a Mac would be preferable to using the literal Control)
Firefox opens a new window when I press C-n. Is this a setting that you have to enable?
The op is probably on Mac where emacs movements use Ctrl but FF and other apps use Cmd key, so they always work as there’s no conflict.
Is there a way to enable such a mode on a Linux Desktop Environment, so most mnemonics use Super- instead of Ctrl- ?
Honestly being able to use emacs movements everywhere is one of the reasons I stay on MacOS.
Meh. I'm not a fan of modal interfaces. But if it works for you, then knock yourself out. I appreciate the write-up here. I'll give it a try to see if I can see what the author is talking about. The overwhelming majority of code I write now is in snippets inside text documents (think Knuthian Literate Programming) so I don't know how that would work w/ the author's modal setup. But they went to the trouble of documenting it, and it seems sort of like what `vi` people are always yammering about. Seems a decent idea to try to understand it.
> I'm not a fan of modal interfaces
I'm assuming you're using Emacs (otherwise why would you be commenting in this thread, right?). It's weird to hear that from an Emacs user - it's inherently a modal editor - keycords are modal, isearch is modal, repeat-mode is modal, transients are all modals with states. Evil-mode only adds some consistent "language" and structure to deal with modality, there's nothing much to it.
Idea of vim-navigation is actually pretty neat thing - absolutely beautiful, practical model. Its biggest problem is that it encapsulates some tacit knowledge - nobody can really explain the benefits of it to anyone until they try it for some time and it "clicks". I suppose just how learning to ride a bike may work differently for different people - it also takes different amount of time and effort. But once you figure it out - there's really no going back - no reason. It's very rare to meet people who've mastered it and then willingly stopped using it.
There's no conceptual difference in switching between navigation and insert modes in Vim and e.g. C-c C-c/C-d in Emacs - the only difference that you're in-between state more often, but once muscle memory trained, it becomes second nature - you don't even think about what mode you're actually in - it becomes very fluid and consistent flow state that allows you to very efficiently navigate and deal with text - with any kind of text - plain and structured.
Also, I find that mastering efficiency in Emacs using only vanilla keybindings is a bit harder than becoming a keyboard-maestro with the help of evil-mode or similar modal modes like meow. I've been working over a decade in various teams where people use Emacs, and evil-mode users typically figure out things much faster, while those sticking to native keybindings, don't even discover some great features of Emacs for years.
I really like this, it's a bit hardcore, but for someone that really cares about efficiency (whether it is worth it or not - debatable), this is great.
Though I have one minor nit against one point, that I've seen basically in every similar article:
> This means no arrow keys and no mouse
I use Neovim daily, and there is no denying that 98% of the time, using mouse is less efficient than doing a fancy search or jump. But for the remaining 2%, it's provably true that mouse is better - like, selecting an arbitrary block of code (without {} or any keyword to hang on). So I always recommend leaving the mouse enabled. Just use it when it makes sense.
> But for the remaining 2%, it's provably true that mouse is better
This is definitely true. The thing is that using the mouse is a habit, and until you break it, people find themselves instinctively using it in situations where it would be better to use the keyboard. So the 'hard' mouse disable is more of a 'going cold-turkey' type thing to try and break the habit. I agree that once it's broken it makes sense to relax this.
How using a mouse and incurring a context switch is better than just mashing j/k a couple of times in worst case scenario?
If you're moving in emacs using per-line/character commands, you're definitely not using emacs as efficiently as you could be.
So the distance in efficiency (and therefore efficacy) between mouse and keyboard is rather a gulf, once you've paid the cost of learning the extra emacs commands.
When you're not editing lisp.
v, then t/T or f/F if staying on the same line, j and k if it’s within a couple line, / or ? for anything else. With the repetition commands ./,/n/N if I do not land at the correct place.
This is a much better alternative to using evil-mode, kudos. It's absolutely right that losing access to the "lingua franca" of emacs keybinds makes the whole thing kind of pointless, unless you rebind everything, of course.
Hmm, would be interesting to see a "race" between this and isearch; from the examples, it looks like this has an advantage only if you have lots of similar strings, so "the one you're looking at" vs. "typing more letters of the word" is an advantage? (externally timed, see The Humane Interface for details on how self-reporting doesn't actually work to measure this kind of thing)
You can also use a great vim “integration” in emacs by using doom emacs.
I've used Emacs for 20 years and I never learnt to navigate in a file except backwards and forwards search.
Is there still hope for me?
I think my biggest issue is that I am a slow coder and I never feel in a hurry.
If your workflow feels comfortable there's really no need to change it in my opinion. The reason I do this is to avoid the frustrating feeling that I'm spending all my time moving around in the text file rather than actually making the program. It's less about speed and more about feeling good while programming.
You really only need a few shortcuts to feel comfortable. The ones in the basic tutorial are pretty much all I use, but I also enable god-mode to avoid having to keep Ctrl pressed as that hurts.
Just type C-h t (help-with-tutorial) and work your way through it.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]