I'm probably the last geek on earth to discover that the model numbers of 3V CR button cell batteries describe their size. E.g., a CR2032 is 20mm diameter and 3.2mm thick. But if I wasn't, now you are.
— matt blaze (@mattblaze) July 17, 2018
Blaze, it turns out, was not the last geek to find this out: I didn’t know it either. I’m betting neither did a bunch of you so I’m sharing the knowledge.
A couple of months ago in writing about the Microsoft acquisition of GitHub I said that many projects—large, complicated ones like Linux and Emacs at that—didn’t use GitHub or its siblings at all but depended on email and (raw) Git to manage the project and its codebase. That’s not too surprising given that Git was developed with Linux and its email driven development process in mind.
Still, if all your projects have been mediated by GitHub, it may not be obvious what the alternative looks like. Drew DeVault prefers the email based workflow and has written a post that describes how it works. Git, not surprisingly, has excellent support for handling things with email.
If you’re still concerned about Microsoft and gitHub or if the acquisition served to make you want an alternative, DeVault’s post can help you get started. One downside to that process is that you don’t (automatically) have a central repository that anyone can access: the code is held in a distributed manner. Of course, that’s an easily solvable problem even if you use GitHub as simply a public access point. As DeVault notes, using the Git/Email process works just as well for small projects. If you’re managing a distributed project, you should take a look at DeVault’s post.
Gaurab Paul has a nice post on improving your Emacs workflow with selection and navigation. He says the post is aimed mainly at Emacs immigrants from “other, so called ‘modern’ editors” but he discusses some techniques that even more experienced Emacsers may find useful.
For example, if you are going to repeat a certain bit of text in the sequel, it makes sense to first set the mark, then type the text, and then copy the text to the kill ring with Meta+w. Then when you want additional instances of the text, you can merely paste it in with Ctrl+y or Meta+y depending on what’s happened in the meantime.
He also discusses navigation and some of the Avy and Helm packages that make it easier. As regular readers know, I’m all in on Avy commands such as avy-goto-word-1 that allow me to quickly navigate to my desired location by picking the right candidate from all the words that begin with a particular character. Paul discusses a few other navigation techniques as well.
If you’re a n00b, you should definitely read this post. Even if you’re a bit more seasoned, you may learn some tricks to improve your workflow.
Susam Pal has an excellent write-up on how to fork a project, make some contribution to it, and generate a pull request for the upstream developer. That’s really handy because many times a user will find a problem and generate a solution locally but not be sure how to let the original developer know through the usual GitHub mechanisms. This can result in the contribution being lost to the wider user community.
Pal’s document doesn’t assume you’re using Magit so he does everything through raw Git commands but there’s nothing difficult or esoteric in those commands so it should be easy to do duplicate his workflow in Magit.
He starts with a quick reference sheet that shows the whole process but then explains each step in detail (including branch diagrams) so that someone unfamiliar with the process can understand what’s going on. He also looks at the workflow from the original developer’s point of view and shows how to merge a pull request into the main development branch.
If you’re a regular contributor to GitHub projects, all this will already be familiar to you. If you’re an infrequent contributor or n00b, this guide is just what you need to help you step through the process. It’s probably a good idea to bookmark the site so you can refer to it as needed.
Here’s another great tip from Wilfred Hughes’ Emacs Command of the Day:
M-x github-clone
This awesome command will clone a github repo from any URL format you can imagine.
It can even automatically fork the repo for you, so you're all ready to send pull requests!
The package is at https://t.co/3IKGFrqKNq and available on MELPA. pic.twitter.com/oYYzuq4cFk
— Ⓔ Command of the Day (@ecotd) July 9, 2018
It’s a separate package so you’ll have to install it but if you work a lot with GitHub, it appears to be a worthwhile addition. Checkout the README at its GitHub repository for instructions on how to use it.
Karl Voit has a couple of nice posts in which he discusses his key binding and file hierarchy strategies. If you’re like me, these things develop in an organic—a nice way of saying haphazard—way. They just evolve over time without a lot of thought or planning. Voit, of course, is an expert on this sort of thing so he has spent some time planning them out in a way that optimizes his workflow.
The main ways he optimizes is key binding layout is to put most of his own bindings under a single prefix. Combined with which-key, this makes it easy for him to find even infrequently used bindings. He also makes use of hydras as a sort of automatic cheat sheet for things like Dired.
Because most things I do involve Org mode in one way or another, a lot of my files live in a directory called org. The only serious subdirectory of org is blog, which contains the local copy of all my blog posts for Irreal. That directory contains just short of 3,000 files so it could probably benefit from being broken into subdirectories by, say, year.
I have additional directories for things like pictures, comics, tax forms, and source code repositories. Voit’s layout is much more thought out. He keeps most things in an archive directory that is further broken down by year and a few other specialized categories.
Voit says that research shows people would rather browse their directories than use a search tool to find files and to some extent his directory structure reflects that. I prefer to put things in broad categories and use a search tool to find what I need. Apple has Spotlight, which makes that pretty easy but I mostly depend counsel-rg and Emacs to find my files. Oddly, that approach is something I learned (or more precisely, adapted) from Voit.
It’s worth reading both his posts and mining those ideas that fit in with your own workflow. They both have a lot of good ideas.
Here’s a really useful tip from Wildred Hughes’ Emacs Command of the Day:
Want to know all the commits that affected a function?@magit_emacs as of version 2.13 provides M-x magit-log-trace-definition for this!
For any language that git log understands, it will show you all the relevant commits. pic.twitter.com/zo56kLcQAj
— Ⓔ Command of the Day (@ecotd) July 7, 2018
It’s just another way of looking at how your code has evolved but it’s one that could be very handy when debugging a problem with a particular function.
It’s sort of like magit-log-buffer-file that I wrote about previously but specialized to a particular function rather than the whole file.
Speaking of Brian Kernighan, grep, and codas, there’s a (very) short afterward to Kernighan’s excellent video telling the story of the origin of greps’s name. At the end of that video (if you haven’t watched it, you definitely should) Kernighan describes a programming challenge he used to assign to his students. Many of the comments to the original video asked how well they did with it.
The afterward answers that question as well as what editor Kernighan is using now. Spoiler: it’s not, of course, ed but he does say that he’ll occasionally fire it up for a short job or if he wants to script an editing job.
The video is just a bit over 2 minutes and provides a nice ending to the original video. If you liked the grep video, you’ll doubtlessly enjoy this one too.
If you enjoyed Brian Kernighan’s video on the genesis of the name “grep”, you will probably also enjoy the three-part Q&A with Kernighan in which he discusses programming, C, and C’s successors.
Kernighan is personable and a great speaker so the videos are easy to watch and absorb and, of course, they’re interesting. It turns out the along with the languages you’d expect, Kernighan also coded in what he describes as the world’s worst COBOL.
He makes a point that is often forgotten today. In the days of early C, it was the best language for text manipulation even though it’s not really a very good language for it. That’s undoubtedly why most of the Unix utilities (as opposed to the OS itself) were written in C.
Each of the three videos are short. The first one is here. There are pointers to the next in the comments below each of the videos.
Since I wrote this, Mike Zamansky has published his own post on these videos. Zamansky has an interesting story about Kernighan that restates something I’ve read many times over the years: Kernighan is a really nice guy who will go out of his way to be helpful even if he doesn’t know you. Be sure to check out Zamansky’s post too.
Irreal readers can’t help but know that I’m a fanatical Org mode addict. I use it for almost everything that doesn’t involve coding and sometimes, via code blocks, even then. I’m an inveterate data gatherer and note taker and all that data and notes go right into Org files.
Still, not everyone is as fond as I am of Org mode but they still need to take notes and collect data. There are lots of ways of doing that, of course, but if you’re an Emacser who hates leaving Emacs, you’ll want a way of taking notes from within Emacs.
Scott Nesbitt offers 3 Emacs modes for taking notes. One of those, of course, is Org mode and I’ve written at length about its virtues for note taking and other tasks. The other two are deft-mode and howm.
I’ve written about deft before (1, 2, 3, 4) and lots of Emacs users—including Org users—swear by it. It’s main attraction appears to be the ease with which you can search and filter the notes. I use tags in Org mode for that and have never seriously used deft but, as I say, lots of knowledgeable people have and love it.
Finally, there’s howm. I’d never heard of it before I read Nesbitt’s post so I can’t add anything intelligent to the discussion about it. Nesbitt says it’s a bit quirky but that he really likes it. You can get an idea of what it’s like by following the howm link above.
As usual, Emacs gives you lots of opportunities to do it your way.