I’ve rebuilt my emacs config a few times for exactly this reason!
Some of the things I’ve found work well for me:
- it’s pretty obvious, but it took me a while to figure it out: make your `~/.emacs.d` into a git (jj, hg, whatever) repo. You don’t need a remote but as you try things out it’s nice to be able to step back in time.
- know what you want to build. For me I’m generally trying to make emacs do something that I’ve seen a colleague’s editor do: integrating language servers for source navigation; integrating a debug server for a nice visual debugging experience.
- some people manage their emacs configuration as org-mode files. This is neat because you get an experience similar to Jupiter notebooks: you can intermix commentary and elisp. I haven’t ever gotten to this point but it looks neat when I see others do it.
There are some good YouTube channels and blogs that talk about configuration, or that test different packages. I’ve found “Emacs from Scratch” and “Emacs Rocks” to be really useful.
There’s a lot to customize and select from. Without steering you one way or another, here are some changes I’ve made recently or packages that I use:
1. For language servers, I find `lsp-mode` to be easier and more full-featured than `elgot`.
2. `dap-mode` plays nicely with `lsp-mode` and makes debugging straightforward.
3. I’ve tried, and use, a few different plugins for AI coding: `greger.el` is the first one I tried, but I’ve started using `xenodium/agent-shell` more. If you want to write (or hack on) an AI agent written in elisp, there’s `steveyegge/efrit`.
4. You’re probably accustomed to some sort of “tab completion” from neovim. Within emacs you’ll need to set up a “completion framework”; there’s a bunch to choose from. Watch some videos and experiment. You’ll probably find one that feels a lot like you’re used to (whether that’s completion-as-arrow-navigable-dropdown-at-cursor, or completion-in-side-panel, or whatever).
Your muscle memory of how to move around in a document and how to tell your editor “I want to do something new now (see a list of open files, go to a new file, etc)” isn’t going to translate into emacs very well. It’s like shifting from a laptop keyboard to some weird split keyboard with thumb paddles: muscle memory won’t be satisfied, and you might just “not like” emacs due to that. There’s `evil.el` (“Emacs VI Layer”) which teaches emacs to recognize vim-style commands. I think vims have fantastic macro recording and replaying functionality - emacs has it as well, but making a recursive macro is harder for me, for some reason - and evil makes emacs’s macros feel on par with the vims.
Another tripping hazard coming from a vim-like is that “undo” operates differently in emacs. I think the vims have a fairly linear undo: like a browser history back button. emacs stores an undo tree, which can lead to surprising behavior at first.
If you’ve written or tweaked plugins for your editor and enjoy tinkering with your tools, then a vanilla greenfield approach to emacs will probably be very satisfying for you.
If you want something that “just works” which you can experiment with and gradually learn more about over time, then you might get more mileage out of spacemacs.
I think vim-style users tend to launch vim many many times through the day. cd here, edit a file; save, quit, edit the next file. emacs can act like an editor, but if you think of it as a highly customizable IDE, then you’ll get more use out of it. My uptime on emacs is generally measured in months, whereas for me vim is in seconds to minutes. I mention this because the startup time for emacs can be quite slow compared to vim; just don’t pay that cost over and over.
I just want to hack together something that works for my use case. If I can share that with the wider team, that is superb. But I really don't enjoy my hacky utils being subject to tedious code review scrutiny they don't deserve.
To be clear, I _do_ add utils that I think will be useful to the common repo, subject to review, and mostly they will be merged. But if it gets painful, I just retract the PR and keep it locally.
I'm not sure that's the (sole) rule for "Y as vowel". It acts as a vowel in "fly", "spy", and a few other words. And it seems pretty darn dipthong-like when clustered among vowels, eg "voyeur", "vying".
The word "eye" is an interesting one. It seems to be only vowels, based on pronunciation.
I use bash within tmux heavily, and got irked that a command I run in one shell session is not immediately available as a history item in other concurrent shell sessions. So I wrote a history plugin based on bash-preexec to track everything to two files: a per-directory history file, and a global history file.
I have a bash function which does history selection for me, by popping an fzf selector to look at the directory-specific history file. A keybinding within fzf allows me to switch to looking at the global history file instead.
Boring commands such as “cd”, “pushd”, and a few others don’t get logged. The log entries are in json format and include basic metadata; directory, timestamp, and pid.
Within the fzf history picker, another keybinding allows me to edit whichever file I’m actively using. So if I fumble a few times to construct a command, then when I get it right I just pop into the selector, edit the relevant file, and remove the lines I don’t want to misfire on again.
I’m sure this is basically what atuin does; now that I’m at the spot where directories are the unit of history relevant history, maybe I should give that tool another look.
One really interesting upside of all of this is that I now tend to make “activity-specific” directories in my repos. For example, I have a “.deploy” directory at the git root of most of my projects. There are no files within that directory; but my tool creates ~/.bash.d/history/home/belden/github/company/project/.deploy.json which contains the history of ~/github/company/project/.deploy/
Empty directories are invisible to git, but for me the directory “has” content: the log of how I need to deploy this service or that service.
It’s a weird way to use my shell, and just sprung out of the initial grief: I shouldn’t have to exit a shell session to have its history become available.
> command I run in one shell session is not immediately available as a history item in other concurrent shell sessions
It's hard to understand how any other way is usable. If you have a dozen concurrent shell sessions, some running a long running process for example, and you had to restart one of them, you wouldn't be able to just Ctrl-C and go to the previous command. For me it's way better shell sessions live their own life but the history is accumulated to a single pool.
Oh, yikes. I’ve come to rely on the email->sms gateway from AT&T. I’ve had they set up a s a forwarding address within my web mail for a few years now, and have filters which forward matching messages as SMS to my phone.
The formatting is often quite lousy but it’s enough to send me a nudge to check my email for a message from the library, a job I applied for, or whatever.
I wouldn’t have heard about this about it being posted here, so thank you!
Why not just have notifications only for that filter? I get not checking emails, I get so many that anything important is just ignored along with all of the other crap but if you already have a good filter, just use that.
Oh I’ve gotten weird about email, for sure — but this is more of an example of “the prototype goes to production”.
I put these filters in place long before iPhones were a thing, and when the only devices that supported push notifications were BlackBerry (maybe? I didn’t have one) and pagers.
In the early 2000s if I wanted to be notified to go home and check my email for something important, the email->sms gateway was really my only option.
Perhaps you could start a timer in a preexec, and stop it in precmd. If the elapsed time is greater than some value, notify-send yourself a message that a long-running command has finished.
Some of the things I’ve found work well for me:
- it’s pretty obvious, but it took me a while to figure it out: make your `~/.emacs.d` into a git (jj, hg, whatever) repo. You don’t need a remote but as you try things out it’s nice to be able to step back in time.
- know what you want to build. For me I’m generally trying to make emacs do something that I’ve seen a colleague’s editor do: integrating language servers for source navigation; integrating a debug server for a nice visual debugging experience.
- some people manage their emacs configuration as org-mode files. This is neat because you get an experience similar to Jupiter notebooks: you can intermix commentary and elisp. I haven’t ever gotten to this point but it looks neat when I see others do it.
There are some good YouTube channels and blogs that talk about configuration, or that test different packages. I’ve found “Emacs from Scratch” and “Emacs Rocks” to be really useful.
There’s a lot to customize and select from. Without steering you one way or another, here are some changes I’ve made recently or packages that I use:
1. For language servers, I find `lsp-mode` to be easier and more full-featured than `elgot`.
2. `dap-mode` plays nicely with `lsp-mode` and makes debugging straightforward.
3. I’ve tried, and use, a few different plugins for AI coding: `greger.el` is the first one I tried, but I’ve started using `xenodium/agent-shell` more. If you want to write (or hack on) an AI agent written in elisp, there’s `steveyegge/efrit`.
4. You’re probably accustomed to some sort of “tab completion” from neovim. Within emacs you’ll need to set up a “completion framework”; there’s a bunch to choose from. Watch some videos and experiment. You’ll probably find one that feels a lot like you’re used to (whether that’s completion-as-arrow-navigable-dropdown-at-cursor, or completion-in-side-panel, or whatever).
Your muscle memory of how to move around in a document and how to tell your editor “I want to do something new now (see a list of open files, go to a new file, etc)” isn’t going to translate into emacs very well. It’s like shifting from a laptop keyboard to some weird split keyboard with thumb paddles: muscle memory won’t be satisfied, and you might just “not like” emacs due to that. There’s `evil.el` (“Emacs VI Layer”) which teaches emacs to recognize vim-style commands. I think vims have fantastic macro recording and replaying functionality - emacs has it as well, but making a recursive macro is harder for me, for some reason - and evil makes emacs’s macros feel on par with the vims.
Another tripping hazard coming from a vim-like is that “undo” operates differently in emacs. I think the vims have a fairly linear undo: like a browser history back button. emacs stores an undo tree, which can lead to surprising behavior at first.
If you’ve written or tweaked plugins for your editor and enjoy tinkering with your tools, then a vanilla greenfield approach to emacs will probably be very satisfying for you.
If you want something that “just works” which you can experiment with and gradually learn more about over time, then you might get more mileage out of spacemacs.
I think vim-style users tend to launch vim many many times through the day. cd here, edit a file; save, quit, edit the next file. emacs can act like an editor, but if you think of it as a highly customizable IDE, then you’ll get more use out of it. My uptime on emacs is generally measured in months, whereas for me vim is in seconds to minutes. I mention this because the startup time for emacs can be quite slow compared to vim; just don’t pay that cost over and over.