Saturday, Nov 15, 2014, 10:10
Almost ever since I started using Vim, I have been in search for a satisfactory persistent visualisation of the buffer list. I have used many hacks over the years, some written by others, some of my own attempt. None ever felt right.
Roughly a year ago, I had a sudden moment of clarity: Vim has already had for a while the functionality required to build this feature, it just usually serves a different purpose. Namely, ever since Vim has supported tabs, it has been able to render them both in text mode and as GUI tabs. Their text mode rendering is exactly what a buffer list would need as well. Why not re- (or ab-)use the
tabline for buffer tabs?
I implemented a first stab at this but it had several severe deficiencies. It scratched my own itch just well enough, howeer, so I dragged my feet for a year.
To my chagrin, I cannot even claim to have had this idea first, much less (in my tardiness) claim first implementation: Airline shipped an implementation of this exact idea at the time it occurred to me independently. Oh well. (Subsequetenly I discovered several more plugins, all of which seem to be younger than Airline’s implementation.)
But recently I finally got around to finishing up my own script to the point where it is actually releasable. So without further ado:
It is designed with the ideal that it should Just Work, and has no configurable behaviour: drop it into your configuration and you’re done. Needless to say I like my own take better than the competitors; but I have also contrasted it with each of them in the documentation, so you can make your own call on that.
Wednesday, Sep 17, 2014, 07:44
I program in English and always have because builtins and the standard library of (asymptotically) every programming language are named based on English. If you try to choose identifiers by another language, your source will inevitably be a mishmash of English plus that other language. I find the resulting jumble to be alternately jarring and grating by equal measures.
Monday, Sep 8, 2014, 11:07
Thesis: algorithmically curating the feed that your service provides is an implicit admission that your service is a net negative for its average user because its signal-to-noise ratio is too terrible to harvest value from it without programmatic aid.
(Behold, Facebook, what “frictionless sharing” hath wrought.)
Or as I quipped recently:
Nobody hangs out on Twitter any more. It’s too crowded.
Tuesday, Mar 11, 2014, 05:21
This entry is mostly for my own benefit, since – being an occasional user – I keep having to figure this out from scratch. What I was aiming for is a workflow that gives me both convenience and full control.
I don’t like
git send-email. The command assembles and sends mail all in one go, so you have to know what it will do blindly. Running
git format-patch manually first only helps a little, since
git send-email still performs its own mail assembly on top of its input. It needs practice – using it frequently for a while and looking at the results. I don’t use it enough for that.
Unfortunately the patchmail I do send every once in a while goes to places with many subscribers, and I’m unwilling to rattle their inboxes with my (repeat!) learning process. I want to be sure I’ll send exactly the mail I mean to, on the very first try. Of course I could dry-run my patchmails by sending them to myself first – fiddly and always one command line typo away from making any mistake public.
I also have msmtp set up on my home server with all the details of my SMTP accounts and really don’t want to maintain another copy of that information on my laptop, especially on a per-repository basis.
So for me, the answer is to avoid
git send-email entirely.
The key realisation is that once a mail is properly formatted, sending it is nothing more than piping it to
/usr/bin/sendmail (or whatever equivalent you employ) – so you actually need only
There is just one little wrinkle to take care of: the “
From ” line it generates needs to be removed before its output can be piped to
sendmail. This is easily done using
formail, which can also split mboxes, making it a convenient companion to
git format-patch --stdout.
Bottom line, this replicates
git format-patch --stdout origin | formail -I 'From ' -s sendmail -t
(Obviously, you season the
git format-patch invocation with
--to email@example.com etc., to your taste.)
git format-patch produces an mbox-format mail folder, which
formail splits into individual mails (“
-s …”), and for each mail, deletes the
From line (“
-I 'From '”) and then pipes the mail to
But note what I gained here:
I can omit the pipe.
I can just call
git format-patch by itself. That allows me to inspect the exact mail that will be sent. In fact, if you don’t pipe the output anywhere, Git will invoke the pager for you and even highlight the diffs within the attachments: excellent. Very convenient for careful reading. Then if I’m satisfied, I add the pipe and out go the patches. (This is much like sending a dry-run to myself first, then sending for real, except with all the friction removed.) I know exactly what is being mailed out. There is no blackbox.
And if there was a cover letter I needed to edit? Then I just pipe to a file first, before piping to
formail. In between those steps, I can edit the file – whether in Vim directly, or using
mutt -f mbox.
Of course, this isn’t necessarily for everyone. You need a machine with procmail installed (for
formail) and a
sendmail-compatible MTA set up. You also need to be comfortable working with mail in the raw. There is, after all, no blackbox.
But it works for me. Sending patchmail is no longer something I put off.
Monday, Dec 30, 2013, 14:50
Sunday, Dec 22, 2013, 00:32
Hypothesis: ideal line length is in the range where you can peripherally glance the end of the line while fixating on its start, because (further hypothesis) this allows your focus to travel toward a fixed point rather than carefully trying to stay in the narrow track of the line.
(From this would follow that large leading only helps by mitigating the difficulty of tracking an over-long line, but leaves the underlying problem of a missing destination fix point unaddressed.)
Monday, Oct 7, 2013, 09:11
v1 The less words you use to tell a story, the more effective its message will be, and a greater number of people will read it to completion. Anyone who cares about the user experience in regards to their software, will tell you “people don’t read.” Which while being somewhat accurate, really isn’t the case. People do read, they just value their time. That is just as important in blogging. Protect your reader’s time, and deliver the message as quickly as possible.
v2 Many designers will say users don’t read text, and therefore, you should have as little copy as possible. This is a lie. Users do read text. Users protect one thing above all: their time. The more text they have to read, the more time of theirs is lost. Protect their time by delivering strong messages with fewer words.
v3 Reading takes time. The less reading you force someone to do, the more time you save them.
v4 Fewer words create a more powerful message.
(Excuse the full-quote – I will refer to different parts repeatedly, so I thought it necessary.)
This is a perfect illustration of the effect that twitterization has on ideas: all nuance and tangent is brutally sawed off until only platitude survives into writing. Elliot’s v4 is so vacuous as to not be worth saying at all. Still, it is an improvement on v3 – because though longer, v3 somehow manages to be even worse. V1 may be unnecessarily long, but among these it is the only one worth writing, because the only one worth reading, because the only one containing an idea. Even in v2, the idea is already watered down: the writing is clumsier and more redundant than in v1, in spite of the reduction in length.
But all of my criticism so far is too myopic. Step back and you’ll notice the real blunder: Elliot missed his own point! He went for brevity above all else, and his message suffered for it. People do read, he asserted – they just value their time… which v4 is a waste of. Presumably the grim takeaway so far is that if you aren’t sure which parts of your writing can be removed and which need keeping, maybe you should go ahead and remove all of it…
Fine, that was the wrong direction. What might be a better one? How do you nudge the text toward conveying ideas? I admit that because I find the arguments here somewhat ill-matched (not in any way that can’t be fixed, mind you – just not without going into the matter at greater length), I am having some difficulty rewriting the text without altering the message. But if I restrain myself to just run with what’s there for the sake of this exercise, I arrive at something like this:
v2 Waste no words in telling a story and it will be effective and keep more readers’ attention until they finish it. Designers will often say that users don’t read; the reality is they just value their time. This is true in blogging too – because it is true everywhere. Don’t waffle.
And that is where I’d stop.
Purely in terms of metrics, this is notably shorter than Elliot’s v2. I think it also manages to retain all the ideas from v1 in spite of its brevity, though that is clearly subjective. Of course it isn’t (nor can be) anywhere near as short as v3 or v4. But is it more powerful? (V4’s own words!)
Oh, and if Elliot really wanted to be serious about it?
v5 Short is powerful.