Category: Code

Using conditionals in .gitconfig

Recently I was creating a Git alias for logs that used --date=human for date formatting, before realizing this option had only been added in Git 2.21. After pulling the alias to some of my other machines and seeing that it failed, I decided I wanted a conditional line in my Git config that tested my current version of Git, used --date=human if possible, and --date=short if not.

Git’s config syntax doesn’t allow for conditionals, but it does allow for the running of arbitrary bits of shell script. For instance, something like this will work:

[alias]
  lg = "!if (( "1 > 2" )); then git log --oneline; else git log; fi"

Because 1 is not greater than 2, git lg will perform a standard git log.

How do we compare our version of Git to a specific value, then? Let’s figure out how to get just our version number of Git first:

$ git --version | sed -E 's/git version ([0-9]+.[0-9]+).*/\1/g'

For me this returns 2.29. We need to check that this is greater than 2.20. Let’s try this:

$ if (( "2.29 > 2.20" )); then echo "Compatible"; else echo "Not compatible"; fi

Why doesn’t this work? I’m getting an invalid arithmetic operator error.

Turns out Bash only handles integer math, so we need to pipe our comparison expression to a basic calculator program:

$ if (( $(echo "2.29 > 2.20" | bc) )); then echo "Compatible"; else echo "Not compatible"; fi

Great! Works for me. Now we just need to get our actual Git version in there instead of the literal 2.29.

After some struggle — the \1 reference in sed needs to be double-escaped here, for some reason — this is the result:

[alias]
  lg = "!if (( \
      $(echo \"$(git --version | sed -E 's/git version ([0-9]+.[0-9]+).*/\\1/') > 2.20\" | bc) \
    )); then \
      DATE="--date=human"; \
    else \
      DATE="--date=short"; \
    fi; \
    git log --pretty=format:\"%h %ad %s\" $DATE"

Now git lg will show a single-line log with “human”-formatted date if possible, or a “short”-formatted date if not.

I’ve created a Gist that puts this all together.

Leave a Comment

How to correctly internationalize WordPress child themes

Internationalization (i18n) and localization (l10n) are important and often overlooked aspects of WordPress development. Themes should give developers and administrators the ability to add translations for users from among the roughly 95% of the world whose first language isn’t English.

There are plenty of articles written about how to provide i18n and l10n for a single theme, but what about child themes? When building a child theme, assuming the parent theme is properly internationalized, developers may want to do any or all of the following:

  1. Provide localizations that aren’t provided by the parent theme, either in different languages or in gaps in existing localizations.
  2. Modify existing localizations in the parent theme, for instance if the developer of the child theme wants to change the wording of some area of the site.
  3. Provide new internationalizations unique to the child theme, using the child theme’s text domain.

Let’s start by looking at a simple example of i18n in a WordPress theme. For the purposes of this article, the parent theme will be called “Parent Theme” with the text domain parenttheme, and the child theme will be called “Child Theme” with the text domain childtheme.

Continue reading “How to correctly internationalize WordPress child themes”

Leave a Comment

On Vim’s being institutionally outdated

I adore Vim, I use it every day, and I wouldn’t dream of switching to anything else, but every once in a while I’m reminded of another thing about it that is just unequivocally bad and indefensible.

I was reading about the “CoC” plugin (“Conqueror of Completion”) this morning when I thought, “Wait, can’t Omni completion do some of that?” So I opened up Vim with a minimal .vimrc and typed:

document.que<C-x><C-o>

<C-x><C-o> opens Vim’s native Omni completion function, which I would expect to be at least somewhat current on JavaScript methods in 2020. Instead, nothing came up.

I had a look at the source of the JavaScript completion function in Vim, and found this: a file that was last updated three years ago, but that hasn’t been meaningfully updated since 2006.

So how have Vim users been getting by?

Continue reading “On Vim’s being institutionally outdated”

Leave a Comment

Getting the “Belle & Sebastian effect” with CSS filters

There are a lot of articles out there regarding using SVG’s feColorMatrix with CSS filters to get a “duotone” or “Instagram” effect on photos, but frankly most of the examples looked too weird to me, and the matrix multiplication that’s going on is pretty hard to wrap my brain around.

Usually what I want is a simple monochrome duotone effect; in other words, the Belle & Sebastian effect:

Most of these are a “dark” duotone effect, where the blacks remain black and the whites become the desired color.

Continue reading “Getting the “Belle & Sebastian effect” with CSS filters”

Leave a Comment

Chris Coyier on PostCSS

Chris Coyier on PostCSS:

We know that specs change. It happens all the time. Seems weird to base a syntax on a non-final spec. What happens when the spec changes? Do you change the language and let existing code break? How is that future-proof? Or support all past formats? Meaning the language isn’t really based on future CSS, it’s based on any experimental idea that was considered?

These have been exactly my thoughts since hearing about CSS post-processors. How can people honestly believe that the code they’re writing is future-proof? Sass source files certainly are prone to “spec rot”, but the CSS they generate isn’t (at least, insofar as anything can be immune to it).

On writing real CSS (again) | CSS-Tricks

One Response

Understanding GNU Screen’s hardstatus strings

My current development setup revolves mainly around Vim and GNU Screen. I use Screen only to keep sessions running between work days or in case I get disconnected, but lately I’ve been tempted to try using different windows inside Screen. In order to make this easier, I wanted one of those status lines that shows you all your windows as “tabs”.

Configuring this status line (the “hardware status line” or, as I’ll call it, “hardstatus”) is done with a single, often long string of characters in ~/.screenrc that at first can look entirely baffling:

hardstatus string "%{= KW} %H [%`] %{= Kw}|%{-} %-Lw%{= bW}%n%f %t%{-}%+Lw %=%C%a %Y-%M-%d"

Exactly.

To my dismay, almost everything I can find about hardstatus through Google are just dumps of other people’s strings, with little to no explanation about why they do what they do – it’s easy to imagine that the people who post them hardly know why they do what they do, either. GNU’s official documentation isn’t terribly helpful.

After finally deciphering a lot of what goes on in these strings, I wanted to spell it out to anybody else who might be hunting around for half a clue about this voodoo. There are (more than?) a few things I haven’t covered here, of course – truncation and conditionals, namely – but this should be enough to get you started.

Continue reading “Understanding GNU Screen’s hardstatus strings”

15 Responses

HTML indent settings in Vim

Despite not agreeing with all of it, “Just Use Sublime Text” (an invective against Vim — or, more accurately, against recommending Vim to anyone who isn’t already indoctrinated by it) by Andrew Ray is an interesting read. The section dealing with indenting in particular struck a chord with me:

Paste this into an empty buffer:

<div>
<p>
<span>foo</span>
</p>
</div>

:set ft=html and then gg=G. Let me know what you get. In all seriousness, never, ever tell me what you get.

As I said in a tweet, what I got didn’t offend me too much. But many people would argue that the <span> tag should be indented inside the <p> tag. I’d probably do this myself, actually — and there have been aspects of Vim’s indenting that irk me. So I set about finding a solution.

Continue reading “HTML indent settings in Vim”

Leave a Comment

Ubuntu’s Semantic Indicator Color Palette

It wasn’t until Mark Shuttleworth’s announcement of “windicators” that I learned of the rationale behind the palette of notification colors in the indicator applet. To quote:

[Windicators] would follow the same styling as Ayatana indicators: Semantically colored: with red for critical problems, orange for alerts, green for positive status changes and blue for informative states that are not the default or usual state.

This came as a real surprise given that I had (and still have) never seen a blue or orange indicator icon.

The obvious and primary objection is that four colors in a palette to convey meaning is far too many. Shuttleworth even said as late as April 1 — just four weeks before Lucid’s release — “Personally, my expectation is that green vs orange/red is as far as we want to go.” Two colors is an absolute maximum here — one for negative messages about something being broken, the other merely to notify you of something — although even one should suffice: “Something has changed; requesting your attention.”

If “orange is for alerts” and “green is for positive status changes,” then why do new IM messages turn the messaging icon green? Isn’t that an alert? What is “positive” about getting a new message? What if it’s your boss firing you? Your boyfriend breaking up with you? A spambot?

Continue reading “Ubuntu’s Semantic Indicator Color Palette”

4 Responses