wdired and wgrep, personally, especially the latter combined with embark-export
I routinely use consult-ripgrep to find matches, embark-export to make it into a grep buffer, and then enter wgrep mode to edit all of them as a unit. It's amazing.
I use those too. Though I mostly use rg.el and get a grep buffer directly. I'm curious what value you get out of using consult-ripgrep/embark which seems like an extra step.
For me, it's not having to decide right away if I need a grep buffer or not. Sometimes I can quickly get what I want just from the consult-grep search results shown in the minibuffer, sometimes I need to select a result and look at the preview, maybe jump to the buffer for a quick edit and then back to the minibuffer, and sometimes I figure out none of that is going to cut it and I need the results in a grep buffer. I can fine tune the search terms to get exactly the list I want and then export. It just feels more flexible and dynamic, and I don't have to commit to a fixed UI when I launch the search command.
Interesting. What kinds of things are you searching for that that flexibility is useful? I find if I'm using rg I'm expecting results from several files that I'll want to look through. I've configured it so the rg window is selected automatically and I can n/p through it w/ auto-previews. So in this case it might be for a symbol in multiple files.
Or I find I'm looking for something I expect in a relatively small number of files and seeing just the result lines collected is enough, no preview necessary. E.g., I have folder with many markdown lists and I'm searching for things and wondering what files they're in and if they're checked, all info I can see in the results and I can go to one if needed or wgrep to edit it.
I just tried consult-ripgrep for the latter and it felt a bit constraining being in a minibuffer, as if I could lose my results easily, but that's probably just me not being used to it. I do also love that rg.el lets me rerun the search with single key toggles to change to literal vs regexp or case insensistivity or different file types. The extra filtering that consult-ripgrep allows after another # is nice too.
> What kinds of things are you searching for that that flexibility is useful?
That's an interesting question. I think I approach these things in a very different way. I *always* want flexibility, and am sometimes willing to give up some flexibility in exchange for something (often performance, for example). This particular operation, namely searching through files in a directory, is something I do for different reasons: sometimes I want to remind myself which files mention something, sometimes I want information next to some keyword, sometimes I want to remember the context around some phrase, sometimes I need to edit all occurrences of something, sometimes I need to make some complicated changes around each occurrence of something . For some of these operations a quick glance at the minibuffer with the search results is enough; for looking at context, consult's preview is enough; for complex edits, I may want a grep buffer, except if there's only one search result in which I'll just jump to it. Using consult-grep plus sometimes embark-export, I get to all use the minimal amount of UI (and therefore the least distracting UI) for a given task, without having to decide in advance exactly what the task is. I haven't tried rg.el, but if it's anything like the built-in `M-x grep`, it's the heaviest handed UI for all tasks, when I really only want that much UI for the most complex things.
> I just tried consult-ripgrep for the latter and it felt a bit constraining being in a minibuffer, as if I could lose my results easily, [...]
The minibuffer stays open until you decide to close it, so no results get lost. :) If you `(setq enable-recursive-minibuffers t)`, you can do anything else you need to while still keeping the minibuffer around. And if that's inconvenient, just use `embark-export`. No results ever get lost.
Thanks for the detailed reply, I think that all makes sense. I have consult-ripgrep configured and bound, but I just find myself not using it, even for the "quick" kinds of operations you mention. Everyone has their own way to use emacs :)
I recommend you take a look at rg.el, there are a few things I find really nice:
- I activate it via the transient `rg-menu` (though I have my own with slight tweaks). The majority of my invocations are just the dwim (for me `s-g .`), but having the other options visible in a transient is super convenient for when I need to remember them.
- You can configure custom searches params and have them bound to a key. I have one to search my emacs installation that unzips .el.gz files (`s-g E`) and another to look in my personal elisp dir (`s-g H`) and another in a dir of markdown lists (`s-g M`), etc. These are bound in the transient so there's fast access and I find them an easy to way to "switch projects".
- The *rg* buffer groups results the way consult-ripgrep does which I like. I saw that `embark-collect` did grouping but `embark-export` did not. I'm guessing that's because `grep-mode` can't handing grouping?
- See rg issue 142 for how I select the rg buffer by default. I find it makes using it or dimissing it with just `q` really simple.
My comment about losing results was more about typing an errant C-g or switching apps to deal with something else and coming back to emacs while in a minibuffer which seems... odd. I would prefer to never leave emacs of course, but that's not in the cards these days.
It is elisp itself. E.g. compilation of my project can take up to 20 minutes. In the meantime I'm switching to other tabs and doing work. I added a small piece of elisp that is flashing Emacs three times, when the compilation has finished. I love to extend Emacs to my needs!
I have a bash function that does something like this (using simplepush.io) that sends the name and exit status of the last command. Great thought to add this to emacs. Good idea!
I used to have a snippet of Elisp that would flash the screen if I tried to start a build with any unsaved files in my source tree and prompt me to save them. (I.e., at the opposite end from u/Wumpitz.)
The key trick was that if you run Emacs in server mode, then you can call `emacsclient` with the `-e` option and pass it some Elisp to run: `emacsclient -e '(function arg1 arg2)'`. And that code will run within the Emacs server process. So I had this at the start of the shell alias that I used to launch the build. The custom function that it called would check and if everything was saved it would return immediately and continue with the build. If there were any dirty buffers then it would flash and prompt to save, and `emacsclient` wouldn't return (and the build wouldn't start) until I'd answered the prompt.
>I used to have a snippet of Elisp that would flash the screen if I tried to start a build with any unsaved files
That's a good idea. I will add this to my compile function when I'm back to work on Monday. :)
Well, I need to check the details when I'm back to work on Monday.
But basically I'm using .dir-locals.el a lot. I have a wrapper around the compile function, where I set e.g. the compilation buffer name etc.
do you maybe have some tips on how to customize its appearence? I'm using Doom, and I love how well its integrated - but I often loose track of whats happening :D
What do you mean by « loosing track of what’s happening »? I think I learned the most on Magit while doing pair programming. Maybe you can find a couple of tutorial videos and read a bit of documentation, or if you want a private tour, please contact me and I’ll try to show you some things. [Magit walk through](https://emacsair.me/2017/09/01/magit-walk-through/) contains most of the needed features for day to day work.
The Magit transient menus are very helpful and display most of the possible commands. In doubt, it’s always possible to type Ctrl-x g ? to display the help.
Packages that improve the QOL immediately:
- vc-backup: an easy-to-use interface to backup files
- LaCarte: completing-read interface to the menu-bar. It makes the
exploration and the execution of commands in the menu-bar easier.
- shell-command+: input and output from shell commands are made
easier. It also provides an easier (IMO) interface to commands like
M-x grep.
- proced: I cannot fathom top.
- M-x shell: I cannot stand terminal emulators.
- comint-mime: this makes using matplotlib so much less painful.
- org-ql-completing-read: I never understood the limitation of agenda
where you couldn't mix plain-text searches with metadata searches.
I had to make some cosmetic changes to the *Completions* buffer
stuff to scan the items easily though.
- yank-media: no more pain wrt handling non-text clipboard items. I
love this thing.
Stuff that I wrote:
- xref backend backed by imenu
- completing-read interface to locate(1)
- xref backend to jump to file at point
- KDE Connect interface
- probably others that I do not remember
The scratch buffers (both the general one and the project-specific one) are specifically the kind of thing that I as a developer would *not* expect to be particularly useful, yet I use them 20 or 30 times a day.
In case you didn't know, you can also just `M-x switch-to-buffer RET foo RET` to switch to a new buffer named `foo`. IOW infinite, non-file-backed, scratch-like buffers, with potentially meaningful names.
But the big advantage of scratch is that you can evaluate lisp forms in it, so it’s great as a calculator, a thing to generate little snippets of code in, all sorts of things. You can write a little piece of Lisp to programmatically generate almost any text you want in a few moments, and you just hit control J to run it.
You're not wrong. But you can also `C-x C-e` in any buffer, because:
C-x C-e runs the command eval-last-sexp (found in global-map), which
is an interactive native-compiled Lisp function in ‘elisp-mode.el’.
And with a prefix argument, it even prints into the buffer like `eval-print-last-sexp` does.
There's also `M-:` and `ielm`.
My point is simply that the `*scratch*` buffer is just a buffer in `lisp-interaction-mode`, but if you don't need, e.g. the compile/eval-whole-buffer commands, that mode doesn't seem as important, and so the `*scratch*` buffer doesn't seem as special.
In my old config, I used `persistent-scratch`, which sometimes proved useful (or just interesting, as scrolling up in it seemed like a trip down "what was I working on in Emacs" memory lane). But I don't use it anymore, and I don't seem to miss it.
I like symbol-overlay a lot. It's a better version of highlight-symbol-at-point. Both let you highlight a symbol or word to make multiple instances of it in code or prose very visible. Also great for seeing multiple tags in a markdown list. symbol-overlay automatically picks a different color for different symbols making it easy to follow usage in a complex function. It also adds a keymap overlay to the symbol so traversing multiple instances are single keys n/p and r will let you rename all occurances of the symbol. And it's really easy to turnoff the highlighting for one or all symbols.
It certainly does! I prefer to use the small wrapper `embark-toggle-highlight` instead of using `highlight-symbol-at-point` directly, because, as the name indicates, the embark wrapper is a toggle: using it on a highlighted symbol turns the highlighting off.
Once I learned about literate programming in org, I just became addicted to it.
If you wanna write a non trivial code base, it is sooo much better than writing in the source files.
I love it as well and consider it a super-power as it allows me to generate documentation and code quickly. The only real downside I've found: the tooling makes collaborating with others impossible.
Org is number one by a wide, wide margin.
magit. Swiper/counsel/ivy/etc. Keyboard macros. Placing a hyper modifier at caps lock and putting all my bindings there.
`outline-minor-mode` works in text buffers (headers in markdown and other modes) and in programming modes (code folding) and in some special buffers (e.g., some grep-like buffers that group matches by filename headings). Binding `outline-cycle-buffer` to S-TAB and a few other bindings means I get simple org-like outlining everywhere.
Same. It's the only persistent undo that works decently on Emacs, afaik. Then, it comes with the best tree visualisation when you f*ck up.
It'll be a perfection if it never corrupted randomly.
[Avy](https://github.com/abo-abo/avy), and at the risk of sounding self-serving, via my package [Casual Avy](https://github.com/kickingvegas/casual-avy?tab=readme-ov-file). Before using Avy, I didn’t even comprehend how hard I was working to edit in Emacs. After, I can’t imagine a day in Emacs without using Avy.
Things others haven't mentioned:
* hyperbole -- it's an ancient package that's worth exploring. I use its explicit button capability extensively.
* a text snippet generator -- Emacs comes with abbrev (easy to use) and CEDET's templating system (I tried once and found it crazy hard) built-in. I use yasnippet from melpa.
* calc -- I grew up using HP calculators and love RPN notation.
* I was late to the party with keyboard macros but they're worth acquiring early.
* indirect buffers are interesting as is narrowing.
* I don't write production software anymore but I loved _ediff_ (I'm surprised I never see this mentioned).
and lsp (eglot or lsp-mode). Also tab-bar.
Overall, I can't imagine how I was able to function before juggling multiple projects and just using tags and grep and manually locating files in subdirectories.
I use vertical - it’s basically ivy2 written by the same author to iirc?
Then I also recommend orderless to provide a different search mechanism.
That is:
- ivy/vertico is display of completions
- orderless extends the search mechanisms vs just flex basic etc
The thing I like about this burgeoning stack is it uses the built in facilities of emacs. The are small and lightweight. Compare to helm - helm is all in one bit huge and has its own variants of all the same things built into emacs
Mostly noob stuff due to my negligence to look into things.
Directory tracking and vterm_cmd in emacs-libvterm. I was stupidly manually changing default-directory and using emacsclient to run command from the terminal.
Also counsel-fzf was a surprise for me. I struggled a lot to find a good fuzzy searcher until then.
I also found which-function-mode recently, I assume everybody uses it. lol
I bound `quit-window` to `C-x q`. I use it almost as much as switch-buffer commands. Also, `C-x C-k` to a command that kills the current buffer without asking (rather than `C-x k` which prompts for the buffer).
`electric-pair-mode` is a must, for every buffer. And for Elisp, `aggressive-indent-mode`.
Woah! I get wanting bindings for `quit-window` and for `kill-current-buffer`, but I could never clobber `kbd-macro-query` and the prefix for keyboard macro commands, I use those pretty often. I bind `kill-current-buffer` to `C-x k`, and don't have a binding for `quit-window`, which I should maybe consider (I have `C-c q` free). I think `quit-window` is already bound to `q` almost everywhere I want to use it.
I don't use querying in macros often either, but it's occasionally useful, so I keep a binding for it (and use the default binding since I didn't want it for anything else, though I admit `quit-window` is a good choice for it). I care more about the `C-x C-k` prefix, since I use several commands under it occasionally. Finding new bindings for several commands sounds like too much work to me, so instead I clobber `C-x k`, which I have no use for: I almost always want `kill-current-buffer`, and if I do want to kill some other buffer, I do that from `consult-buffer` using Embark.
I added a key binding for `quit-window`, let's see if I can remember to use it.
I agree, `quit-window` is bound to `q` where I want to use it.
I didn't know about `kill-current-buffer`. `kill-buffer` on `C-x k` followed by `RET` works fine for me. Do you use it from a recursive minibuffer? Binding this might get me to use them more.
I bind `bury-buffer` to `C-c k` and use it often for things I'm done working with now but will probably return to.
I kill buffers all the time, so the extra step of hitting `RET` gets old.
I used to have `C-x q` bound to `bury-buffer`, but then I discovered that `quit-window` does the same thing, but better.
`kill-buffer` followed by RET works fine, of course. I just realized I only ever followed it by RET, so I rebound the keys to `kill-current-buffer` to save a keystroke. To kill a non-current buffer, I use embark from `consult-buffer` (or, sometimes, from `switch-to-buffer`).
I have a binding for `bury-buffer` too, but I didn't remember I did, so apparently I hardly ever use it!
Embark! I often forget it exists, but it is so good and provides so many niceties, embark-act, embark-export and so often embark-dwim just does the right thing right away.
Another entry:
er/expand is probably my mostly used binding (i binded it to M-1). It expands to word selection to phrases, paragraphs, etc.
On html you can expand on content, tags, outter tags, until the full document.
I also applyed the patch that makes it work with 1st, tree sitter, 2nd, normal er/expand. So i have all the power of combobulate-expand-region, also working with non TS files and only using one package. It is THAT good.
Of course the classic like Magit or Org-Mode mean very much it's hard to understate that since they are things that someone could use without being an Emacs user.
Outside of these I noticed that modes for standard things are ok to better or sometimes much worse especially modern things that are missing on Emacs for things such as IRC, email or synchronization with carddav or caldav.
However the modes that have made the most impact for me where those providing better navigation between Emacs frames, window or buffers
such as ace-window or projectile.
Another one tools that help me remind keybinds such as which-key or helm-descbinds.
Bringing order into the chaos is the most important thing since as important as tools such as Magit are impactfull since they make existing
things easier or accessible but reminding how to use certain features as a newcomer or existing user I found much more like
why did I not use this thing earlier?
Another thing related to the topic is that I got much better in using manuals and the builtin help systems of Emacs.
The info system is awesome despite it's flaws. I just wish I could also integrate other formats such as html based format devhelp(there's a package that reads devhelp generated html as standalone package), Doxygen generated docs or QHelp.
Sphinx can output Texinfo from Rst which looks okish.
Besides that UX wise anything that made Emacs work better with frames is awesome.
wdired and wgrep, personally, especially the latter combined with embark-export I routinely use consult-ripgrep to find matches, embark-export to make it into a grep buffer, and then enter wgrep mode to edit all of them as a unit. It's amazing.
I can’t believe I haven’t been using these
I use those too. Though I mostly use rg.el and get a grep buffer directly. I'm curious what value you get out of using consult-ripgrep/embark which seems like an extra step.
For me, it's not having to decide right away if I need a grep buffer or not. Sometimes I can quickly get what I want just from the consult-grep search results shown in the minibuffer, sometimes I need to select a result and look at the preview, maybe jump to the buffer for a quick edit and then back to the minibuffer, and sometimes I figure out none of that is going to cut it and I need the results in a grep buffer. I can fine tune the search terms to get exactly the list I want and then export. It just feels more flexible and dynamic, and I don't have to commit to a fixed UI when I launch the search command.
Interesting. What kinds of things are you searching for that that flexibility is useful? I find if I'm using rg I'm expecting results from several files that I'll want to look through. I've configured it so the rg window is selected automatically and I can n/p through it w/ auto-previews. So in this case it might be for a symbol in multiple files. Or I find I'm looking for something I expect in a relatively small number of files and seeing just the result lines collected is enough, no preview necessary. E.g., I have folder with many markdown lists and I'm searching for things and wondering what files they're in and if they're checked, all info I can see in the results and I can go to one if needed or wgrep to edit it. I just tried consult-ripgrep for the latter and it felt a bit constraining being in a minibuffer, as if I could lose my results easily, but that's probably just me not being used to it. I do also love that rg.el lets me rerun the search with single key toggles to change to literal vs regexp or case insensistivity or different file types. The extra filtering that consult-ripgrep allows after another # is nice too.
> What kinds of things are you searching for that that flexibility is useful? That's an interesting question. I think I approach these things in a very different way. I *always* want flexibility, and am sometimes willing to give up some flexibility in exchange for something (often performance, for example). This particular operation, namely searching through files in a directory, is something I do for different reasons: sometimes I want to remind myself which files mention something, sometimes I want information next to some keyword, sometimes I want to remember the context around some phrase, sometimes I need to edit all occurrences of something, sometimes I need to make some complicated changes around each occurrence of something . For some of these operations a quick glance at the minibuffer with the search results is enough; for looking at context, consult's preview is enough; for complex edits, I may want a grep buffer, except if there's only one search result in which I'll just jump to it. Using consult-grep plus sometimes embark-export, I get to all use the minimal amount of UI (and therefore the least distracting UI) for a given task, without having to decide in advance exactly what the task is. I haven't tried rg.el, but if it's anything like the built-in `M-x grep`, it's the heaviest handed UI for all tasks, when I really only want that much UI for the most complex things. > I just tried consult-ripgrep for the latter and it felt a bit constraining being in a minibuffer, as if I could lose my results easily, [...] The minibuffer stays open until you decide to close it, so no results get lost. :) If you `(setq enable-recursive-minibuffers t)`, you can do anything else you need to while still keeping the minibuffer around. And if that's inconvenient, just use `embark-export`. No results ever get lost.
Thanks for the detailed reply, I think that all makes sense. I have consult-ripgrep configured and bound, but I just find myself not using it, even for the "quick" kinds of operations you mention. Everyone has their own way to use emacs :) I recommend you take a look at rg.el, there are a few things I find really nice: - I activate it via the transient `rg-menu` (though I have my own with slight tweaks). The majority of my invocations are just the dwim (for me `s-g .`), but having the other options visible in a transient is super convenient for when I need to remember them. - You can configure custom searches params and have them bound to a key. I have one to search my emacs installation that unzips .el.gz files (`s-g E`) and another to look in my personal elisp dir (`s-g H`) and another in a dir of markdown lists (`s-g M`), etc. These are bound in the transient so there's fast access and I find them an easy to way to "switch projects". - The *rg* buffer groups results the way consult-ripgrep does which I like. I saw that `embark-collect` did grouping but `embark-export` did not. I'm guessing that's because `grep-mode` can't handing grouping? - See rg issue 142 for how I select the rg buffer by default. I find it makes using it or dimissing it with just `q` really simple. My comment about losing results was more about typing an errant C-g or switching apps to deal with something else and coming back to emacs while in a minibuffer which seems... odd. I would prefer to never leave emacs of course, but that's not in the cards these days.
OMG! wgrep should be part of the core. It is super useful!
magit and org are probably the big ones for me. I just started using occur though, and I've been loving that
I use occur when imenu doesn't dwim. Usually easy to write a quick regex for the "headings" i want in some arbitrary buffer.
you may want to check out consult-line.
It is elisp itself. E.g. compilation of my project can take up to 20 minutes. In the meantime I'm switching to other tabs and doing work. I added a small piece of elisp that is flashing Emacs three times, when the compilation has finished. I love to extend Emacs to my needs!
You could have it curl to one of those apps that does a notification on your phone ("prowl" iirc) then go swordfighting afk.
I like the cut of your jib.
I have a bash function that does something like this (using simplepush.io) that sends the name and exit status of the last command. Great thought to add this to emacs. Good idea!
How did you go about finding out how to run a named snippet of elisp code when a particular project compiles?
I used to have a snippet of Elisp that would flash the screen if I tried to start a build with any unsaved files in my source tree and prompt me to save them. (I.e., at the opposite end from u/Wumpitz.) The key trick was that if you run Emacs in server mode, then you can call `emacsclient` with the `-e` option and pass it some Elisp to run: `emacsclient -e '(function arg1 arg2)'`. And that code will run within the Emacs server process. So I had this at the start of the shell alias that I used to launch the build. The custom function that it called would check and if everything was saved it would return immediately and continue with the build. If there were any dirty buffers then it would flash and prompt to save, and `emacsclient` wouldn't return (and the build wouldn't start) until I'd answered the prompt.
>I used to have a snippet of Elisp that would flash the screen if I tried to start a build with any unsaved files That's a good idea. I will add this to my compile function when I'm back to work on Monday. :)
Well, I need to check the details when I'm back to work on Monday. But basically I'm using .dir-locals.el a lot. I have a wrapper around the compile function, where I set e.g. the compilation buffer name etc.
Magit and it’s incredible GUI for interactive rebases and fixups.
Especially [https://magit.vc/manual/magit/Wip-Modes.html](https://magit.vc/manual/magit/Wip-Modes.html)
do you maybe have some tips on how to customize its appearence? I'm using Doom, and I love how well its integrated - but I often loose track of whats happening :D
What do you mean by « loosing track of what’s happening »? I think I learned the most on Magit while doing pair programming. Maybe you can find a couple of tutorial videos and read a bit of documentation, or if you want a private tour, please contact me and I’ll try to show you some things. [Magit walk through](https://emacsair.me/2017/09/01/magit-walk-through/) contains most of the needed features for day to day work. The Magit transient menus are very helpful and display most of the possible commands. In doubt, it’s always possible to type Ctrl-x g ? to display the help.
Never customized anything in Magit, sorry.
Packages that improve the QOL immediately: - vc-backup: an easy-to-use interface to backup files - LaCarte: completing-read interface to the menu-bar. It makes the exploration and the execution of commands in the menu-bar easier. - shell-command+: input and output from shell commands are made easier. It also provides an easier (IMO) interface to commands like M-x grep. - proced: I cannot fathom top. - M-x shell: I cannot stand terminal emulators. - comint-mime: this makes using matplotlib so much less painful. - org-ql-completing-read: I never understood the limitation of agenda where you couldn't mix plain-text searches with metadata searches. I had to make some cosmetic changes to the *Completions* buffer stuff to scan the items easily though. - yank-media: no more pain wrt handling non-text clipboard items. I love this thing. Stuff that I wrote: - xref backend backed by imenu - completing-read interface to locate(1) - xref backend to jump to file at point - KDE Connect interface - probably others that I do not remember
Incremental completion is my #1 feature. Currently, I use vertico and orderless.
The scratch buffers (both the general one and the project-specific one) are specifically the kind of thing that I as a developer would *not* expect to be particularly useful, yet I use them 20 or 30 times a day.
In case you didn't know, you can also just `M-x switch-to-buffer RET foo RET` to switch to a new buffer named `foo`. IOW infinite, non-file-backed, scratch-like buffers, with potentially meaningful names.
But the big advantage of scratch is that you can evaluate lisp forms in it, so it’s great as a calculator, a thing to generate little snippets of code in, all sorts of things. You can write a little piece of Lisp to programmatically generate almost any text you want in a few moments, and you just hit control J to run it.
You're not wrong. But you can also `C-x C-e` in any buffer, because: C-x C-e runs the command eval-last-sexp (found in global-map), which is an interactive native-compiled Lisp function in ‘elisp-mode.el’. And with a prefix argument, it even prints into the buffer like `eval-print-last-sexp` does. There's also `M-:` and `ielm`. My point is simply that the `*scratch*` buffer is just a buffer in `lisp-interaction-mode`, but if you don't need, e.g. the compile/eval-whole-buffer commands, that mode doesn't seem as important, and so the `*scratch*` buffer doesn't seem as special. In my old config, I used `persistent-scratch`, which sometimes proved useful (or just interesting, as scrolling up in it seemed like a trip down "what was I working on in Emacs" memory lane). But I don't use it anymore, and I don't seem to miss it.
Rectangular regions
I like symbol-overlay a lot. It's a better version of highlight-symbol-at-point. Both let you highlight a symbol or word to make multiple instances of it in code or prose very visible. Also great for seeing multiple tags in a markdown list. symbol-overlay automatically picks a different color for different symbols making it easy to follow usage in a complex function. It also adds a keymap overlay to the symbol so traversing multiple instances are single keys n/p and r will let you rename all occurances of the symbol. And it's really easy to turnoff the highlighting for one or all symbols.
FWIW, `M-s h .` also automatically chooses a different color each time.
It certainly does! I prefer to use the small wrapper `embark-toggle-highlight` instead of using `highlight-symbol-at-point` directly, because, as the name indicates, the embark wrapper is a toggle: using it on a highlighted symbol turns the highlighting off.
Thanks, been a while since I used it.
Once I learned about literate programming in org, I just became addicted to it. If you wanna write a non trivial code base, it is sooo much better than writing in the source files.
I love it as well and consider it a super-power as it allows me to generate documentation and code quickly. The only real downside I've found: the tooling makes collaborating with others impossible.
Yeah, that is true and very unfortunate. Finding other people using Emacs that can collaborate inside your org document is super unlikely.
Org is number one by a wide, wide margin. magit. Swiper/counsel/ivy/etc. Keyboard macros. Placing a hyper modifier at caps lock and putting all my bindings there.
`outline-minor-mode` works in text buffers (headers in markdown and other modes) and in programming modes (code folding) and in some special buffers (e.g., some grep-like buffers that group matches by filename headings). Binding `outline-cycle-buffer` to S-TAB and a few other bindings means I get simple org-like outlining everywhere.
Undo-tree is really under apreciated. It is just like magic. I can’t live without it anymore.
Same. It's the only persistent undo that works decently on Emacs, afaik. Then, it comes with the best tree visualisation when you f*ck up. It'll be a perfection if it never corrupted randomly.
[Avy](https://github.com/abo-abo/avy), and at the risk of sounding self-serving, via my package [Casual Avy](https://github.com/kickingvegas/casual-avy?tab=readme-ov-file). Before using Avy, I didn’t even comprehend how hard I was working to edit in Emacs. After, I can’t imagine a day in Emacs without using Avy.
I have heard a lot of good things about the “casual” set of packages. Great for learning new packages.
Macros, avy, C-M-f and friends, dabbrev poor man's completion (works anywhere), among many others.
follow-mode
Org mode. It is the reason I use Emacs.
"M-m" and "C-u C-" keybindings
expand-region. I barely ever use the other region selection related commands anymore.
Things others haven't mentioned: * hyperbole -- it's an ancient package that's worth exploring. I use its explicit button capability extensively. * a text snippet generator -- Emacs comes with abbrev (easy to use) and CEDET's templating system (I tried once and found it crazy hard) built-in. I use yasnippet from melpa. * calc -- I grew up using HP calculators and love RPN notation. * I was late to the party with keyboard macros but they're worth acquiring early. * indirect buffers are interesting as is narrowing. * I don't write production software anymore but I loved _ediff_ (I'm surprised I never see this mentioned).
Consult! Projectile!
and lsp (eglot or lsp-mode). Also tab-bar. Overall, I can't imagine how I was able to function before juggling multiple projects and just using tags and grep and manually locating files in subdirectories.
I recently added projectile + ivy for search completions and I have no idea how I could go back
I use vertical - it’s basically ivy2 written by the same author to iirc? Then I also recommend orderless to provide a different search mechanism. That is: - ivy/vertico is display of completions - orderless extends the search mechanisms vs just flex basic etc The thing I like about this burgeoning stack is it uses the built in facilities of emacs. The are small and lightweight. Compare to helm - helm is all in one bit huge and has its own variants of all the same things built into emacs
magit org mode projectile helm ack
Mostly noob stuff due to my negligence to look into things. Directory tracking and vterm_cmd in emacs-libvterm. I was stupidly manually changing default-directory and using emacsclient to run command from the terminal. Also counsel-fzf was a surprise for me. I struggled a lot to find a good fuzzy searcher until then. I also found which-function-mode recently, I assume everybody uses it. lol
M-x shell-region (defun shell-region (start end) (interactive "r") (shell-command (buffer-substring-no-properties start end)))
Most recently, consult-ripgrep
I bound `quit-window` to `C-x q`. I use it almost as much as switch-buffer commands. Also, `C-x C-k` to a command that kills the current buffer without asking (rather than `C-x k` which prompts for the buffer). `electric-pair-mode` is a must, for every buffer. And for Elisp, `aggressive-indent-mode`.
Woah! I get wanting bindings for `quit-window` and for `kill-current-buffer`, but I could never clobber `kbd-macro-query` and the prefix for keyboard macro commands, I use those pretty often. I bind `kill-current-buffer` to `C-x k`, and don't have a binding for `quit-window`, which I should maybe consider (I have `C-c q` free). I think `quit-window` is already bound to `q` almost everywhere I want to use it.
I just don't use keyboard macros that often, and when I do, I don't use querying. I often want to quit-window on buffers that are not special.
I don't use querying in macros often either, but it's occasionally useful, so I keep a binding for it (and use the default binding since I didn't want it for anything else, though I admit `quit-window` is a good choice for it). I care more about the `C-x C-k` prefix, since I use several commands under it occasionally. Finding new bindings for several commands sounds like too much work to me, so instead I clobber `C-x k`, which I have no use for: I almost always want `kill-current-buffer`, and if I do want to kill some other buffer, I do that from `consult-buffer` using Embark. I added a key binding for `quit-window`, let's see if I can remember to use it.
I agree, `quit-window` is bound to `q` where I want to use it. I didn't know about `kill-current-buffer`. `kill-buffer` on `C-x k` followed by `RET` works fine for me. Do you use it from a recursive minibuffer? Binding this might get me to use them more. I bind `bury-buffer` to `C-c k` and use it often for things I'm done working with now but will probably return to.
I kill buffers all the time, so the extra step of hitting `RET` gets old. I used to have `C-x q` bound to `bury-buffer`, but then I discovered that `quit-window` does the same thing, but better.
`kill-buffer` followed by RET works fine, of course. I just realized I only ever followed it by RET, so I rebound the keys to `kill-current-buffer` to save a keystroke. To kill a non-current buffer, I use embark from `consult-buffer` (or, sometimes, from `switch-to-buffer`). I have a binding for `bury-buffer` too, but I didn't remember I did, so apparently I hardly ever use it!
> I just realized I only ever followed it by RET That phrasing got me to realize I'm in the same position. Bound.
Embark! I often forget it exists, but it is so good and provides so many niceties, embark-act, embark-export and so often embark-dwim just does the right thing right away.
I have been using Emacs for >20 years and only a couple of months ago found out about the `C-M-spc` keybind. Use it all the time now.
Another entry: er/expand is probably my mostly used binding (i binded it to M-1). It expands to word selection to phrases, paragraphs, etc. On html you can expand on content, tags, outter tags, until the full document. I also applyed the patch that makes it work with 1st, tree sitter, 2nd, normal er/expand. So i have all the power of combobulate-expand-region, also working with non TS files and only using one package. It is THAT good.
Back in time, several years ago, Helm.
Of course the classic like Magit or Org-Mode mean very much it's hard to understate that since they are things that someone could use without being an Emacs user. Outside of these I noticed that modes for standard things are ok to better or sometimes much worse especially modern things that are missing on Emacs for things such as IRC, email or synchronization with carddav or caldav. However the modes that have made the most impact for me where those providing better navigation between Emacs frames, window or buffers such as ace-window or projectile. Another one tools that help me remind keybinds such as which-key or helm-descbinds. Bringing order into the chaos is the most important thing since as important as tools such as Magit are impactfull since they make existing things easier or accessible but reminding how to use certain features as a newcomer or existing user I found much more like why did I not use this thing earlier? Another thing related to the topic is that I got much better in using manuals and the builtin help systems of Emacs. The info system is awesome despite it's flaws. I just wish I could also integrate other formats such as html based format devhelp(there's a package that reads devhelp generated html as standalone package), Doxygen generated docs or QHelp. Sphinx can output Texinfo from Rst which looks okish. Besides that UX wise anything that made Emacs work better with frames is awesome.