- Speaking for myself, reasons why I don’t immediately share my own tooling:
Perhaps I want to hold it to my own standard for tooling, not the team’s.
Perhaps I want to write it in a language that the team doesn’t really embrace.
I might not think it’s worth anyone’s time to code review changes I make to my own tools.
I might want to do something dumb like bake an API key into the tool.
Maybe the project already has a similar tool, and I don’t want to explain why I am wrapping/ignoring it.
In short: sometimes the cost to collaborate on idiosyncratic tools is just higher than I’m willing to pay.
- 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 fall into the hoard-and-curate camp.
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.
- 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.
It’s probably worth a revisit now though!
- 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!
- If I’m looking for code changes:
If it’s commit messages I’m interested in:git log -S <the-string>
Sometimes I want to know “all the commits that introduced a pattern”:git log --grep <the-word-or-phrase>
This last one I use frequently enough that I wrote a little shell script for it, called "git-blep" (for "blame-grep")git blame —- $(git grep -P -l 'the.*regex') | grep -P 'the.*regex'———
If there’s a function name that you’re logging, then you might get mileage from
Though that probably would not have worked in the original author’s case.git log -L :<the-function-name>:<the-file-name> - I wonder if bash-preexec https://github.com/rcaloras/bash-preexec could be used here.
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.
- Naming our first child was tricky. My wife and I had a final list of 5 names, any of which would work as a first-middle combination. She’d randomly toss out two: “Washington Stewart? Kennedy Frakes?”
After a few minutes of that I just wrote the loop to give us all possible combinations; and from there we selected the name.
It took 2 minutes tops, and I’d have forgotten about this except she still talks about how I wrote a program to name our child.
- RetailNext, Inc. | Full-Stack Engineer | Retail Analytics | Bay Area, CA | Full-time | Remote | https://retailnext.net/en/about-us/careers/
RetailNext is hiring for full-stack engineers to join the UI team. We use Ember and Ruby to build the configuration and reporting platform used by retailers to gather and understand customer behavior in-store. Our hardware and software system uses computer vision and a wide variety of other inputs to answer questions that retailers are interested in: how many people walked into the store today compared to last week? which direction did they walk? is this store hitting its sales targets for the week?
I am the engineering manager for the UI team. We're a group of 4 full-stack developers, looking to add more engineers who understand modern CSS and HTML; know Javascript well; and want to have control over the API side of their work. Experience with Ember.js and Ruby on Rails is good but not required. Remote experience is highly preferred for remote candidates. If this sounds like a good fit, please reach out to me! belden@retailnext.net
- When I change jobs, I check which version of my editor the dev environments have installed. If it's too old, I build a local copy of the latest version of my editor. No worries asking IT or Ops to update a package for me.
When it comes to production servers, I'm more likely to build my editor in my home directory than use my sudo privileges to install my editor in the system.
So developers can be building newest versions of code on old systems. I do.
- If you find "no problem" to be hard to say - or perhaps you feel it is hard for your listener to hear - then you could try "my pleasure". I made this small edit to my speech a few years ago.
I recently heard a nurse say, "It's my privilege" in response to a thank-you. This felt like a more heartfelt acknowledgement of the gratitude being expressed.
One might also experiment with "It's no burden", which seems to fall somewhere between "My pleasure" and "It's my privilege".
- Macros in vim can call themselves; so if you want to make an edit across an entire file, something like:
<esc>qqq //clear q macro qq //start recording q macro /foo // search for something 3clbar // do some edit @q // call q macro q //done recording @q //invoke q macro
No need to guess how many times to call your macro.
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.