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.
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
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.
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
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
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.
Not sure I understand why vi navigation is better. I always thought emacs' arrow keys were better than escape-h,j,k or l. Much of the time I just use emacs' equivalent of leaping, ctrl-s and ctrl-r to search forward and back.
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.
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.
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.
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.
(or I could pick up the mouse, I know, but that's not why we're here)
(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.
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 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.
EDIT: I just looked at the link posted by lvass and I understand now. So cool! I am going to update my workflow.
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
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.
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.
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. :-)
> 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
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.,
(global-set-key (kbd "C-s-<mouse-1>") 'mc/add-cursor-on-click)
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.
nine_k•2mo ago
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.