Improving my Emacs experience with completion
martinfowler.com
martinfowler.com
ivy-avy works like vim's EasyMotion or the older Emacs "ace-jump" mode (inspired by EasyMotion): you keep your eyes on the thing you want to select (or the place on the screen where you want your cursor to go to) and then invoke avy (by using a shortcut very conveniently placed as I use it all the time). Then a letter appears and you hit that letter (requires to be a touch typist as you cannot both keep your eyes on the candidate and look at your keyboard) and boom, you just selected the candidate / moved the cursor.
There's no faster way to select / move anywhere on the screen.
I'm using that since years (I used to use ace-jump before ivy/avy was a thing).
Imagine this list of candidates after I asked to open a file containing the regexp "green" (well it's just a word, but it could be a regexp):
/home/jack/work/green.pdf
/home/jack/private/greendayschedule.org
.
. (omit 10 lines here)
.
/mnt/greenvelvet.txt
/mnt/backup/green.cfg
f/home/jack/work/green.pdf
g/home/jack/private/greendayschedule.org
n
b (omit 10 lines here)
c
e/mnt/greenvelvet.txt
d/mnt/backup/green.cfg
To select, say, "mnt/greenvelvet.txt", you just hit the letter 'e'. Done.
It's really sweet and it works with nearly everything: selecting a candidate in a list (like a file, a completion, ...), moving the cursor anywhere on the screen, selecting a buffer, etc.
> To select, say, "mnt/greenvelvet.txt", you just hit the letter 'e'. Done.
With helm+avy, I need to explicitly press Ctrl+Space to select. But, pressing 'e' does move the caret to the proper line containing '/mnt/greenvelvet.txt'
I coudnt find a helm counterpart to 'ivy-avy' package though.
---------------------------------------------------------
Edit:- avy-ivy, on pressing 'e' confirms greenvelvet.txt as the selection. It is the helm equivalent of C-n...C-n until reaching '/mnt/greenvelvet.txt' and pressing Return.
I was looking for someway to 'helm mark' the line containing '/mnt/greenvelvet.txt' using avy.
Yes it's exactly the same: I'm actually reusing the same shortcut for both. In a regular buffer I'm using precisely avy-goto-char-timer and in, say, "counsel-find-file" (which I use instead of "find-file"), that same shortcut calls the ivy-avy function.
Now I use ivy/counsel/swiper/avy but don't use helm so cannot help there.
P.S: and I confirm I just hit the letter and, say, the file immediately opens (I don't need to hit enter for example)
I used Emacs full time for more than a decade without fully understanding completion and that meant I wasn't able to tweak it to my liking. Things would break and I didn't understand why. Although I think company is probably the most polished and best in-buffer completion UI there is, using modular components like eglot, orderless and corfu has helped me to understand the various aspects of completion and get it all working how I want it.
Somehow, I feel like, if I were to configure vertico etc to my liking, I might just end up recreating a ductaped version of helm.
It is also surprising how far dabbrev-expand can get you in most code bases.
The main example I can think of is "Dependency Injection". The idea to pass an object to another object (for different purposes, e.g. testing) is pretty simple and understandable. But over time the term " dependency injection" has probably confused a whole lot of people but for some reason a term just had to be coined.
I do understand that it's probably not on purpose because the author(s) are deeply studying or thinking about what they are describing (probably more so than the readers) and maybe coming up with new terminology does help them to keep making sense of it all.
Dependency injection is 'just' passing an argument to a function or method.
Whether that happens via the constructor, some method, or a plain ol' function, its very simple.
But naming it dependency injection and ascribing terms like setter injection, or constructor injection or discussing dependency injection frameworks with complicated set up instructions, can make this very simple concept seem significantly more complex and difficult for junior and mid level engineers.
All my opinion but this was also my experience.
I feel completion is an essential feature for an editor presently and not having it baked in is not a good approach.
It's gotten quite simple in recent years. use-package lsp, use-package company, and hook to enable those for the things you want
For myself as primarily a Rust developer, rust-analyzer is just part of my toolchain already, so there was no extra step.
And don't you think the convenience of like installing intellij, and it works fully is very convenient, whereas with Emacs a major component of the workflow, the LSP could be major hassle to get installed.
And it's not even like he ignores the advantages since he uses IntelliJ for Java!
Emacs users believe the tool should be adapted to the user rather than the user adapting to the tool.
I don't know what to say. Ignorance and antagonism mixed together, consciously...
... Maybe emacs users know something you don't?
(FWIW I have been using JetBrains tools' & emacs as well for over a couple decades now [since IntelliJ 3-something back in 2003 if I recall], usually complimentary to each other, not competing. As of last week, I am not renewing my CLion subscription, and work fully in emacs and it's fine.)
Though actually I'm not sure if they'll do it on directory name components or just the filename itself.
They will, however, have 5x the memory and battery consumption and not be nearly as snappy in response time, nor nearly as customizable.
a) he's wrong to call it outdated... because that's not the case, it's a very vibrant community and with boatloads of dev happening
b) he's wrong to say it only does 10% of blah blah blah -- capability wise my config does pretty much everything I had with CLion/RustRover in terms of my C++/Rust workflow... but also a whole lot more on other fronts
c) he's wrong to formulate a comment like that because it's inflammatory and not nice
Honestly, futzing with VSCode is pretty much as 'brittle' and 'batteries not included' situation as emacs, though obviously more popular. Every time I went from CLion over to VSCode I just threw my hands up in annoyance.
My emacs + lsp + company + rust-analyzer + projectile + treemacs setup works better for me, though obviously that's somewhat because I have 30 years of mild-muscle-memory for emacs keybindings. (Though there is cua-mode, y'know)
Would I recommend it for brand new devs, or for my 13-year old son starting out or something? Probably not. But it's really none of my business what tools other people use.
From then on, the experience feels pretty modern, while remaining infinitely customizeable in a structured way.
Most modern IDEs even come with key mappings for emacs so you can switch instantly and leverage their superior feature set without having to relearn anything.
* Buffer and frame management. Getting used to splits and quickly bouncing between buffers is something that is a muscle memory, at this point.
* Pretty much complete introspection of the editor. All of the help functions, as well as the *Messages* buffer are things that are often very hidden in other editors.
* The "all is fair" community. There are some grumpy style folks that use it, of course. I've found that most are far more friendly and open to you doing things however you want than in most other communities. The pedantic nature of a lot of developers falls over into a lot of our entire industry, it is refreshing to find a community that is pragmatic over pedantic to this level.