When desktop widgets first turned up in macOS I was pretty quick to embrace them. On my personal Mac Mini I use a pair of screens, the right one mostly given over to Emacs, and there was generally room to space there. These days that screen generally looks something like this:

Recently I've got into streaming while I do some coding and it's the right-hand screen that I work on and capture using OBS. When I was setting this up I realised that the widgets being there could be a problem; not because they could distract or anything, more that they could, at times, contain sensitive information (there's my reminder list and my calendar there after all).

What I needed was a quick method of hiding all the widgets, and showing them again later, without it being a lot of faff.

With a little bit of digging around on the net I finally came up with a pair of fish abbreviations that do just the job!

abbr -g widoff "defaults write com.apple.WindowManager StandardHideWidgets -int 1"
abbr -g widon "defaults write com.apple.WindowManager StandardHideWidgets -int 0"

Now, when I'm going to stream, part of my "getting stuff ready to go live" checklist is to run widoff in the terminal; once I'm finished I can then just run widon again to have them come back.

Fast, clean, handy.

I've also got a pair for when I'm using Stage Manager:

abbr -g smwidoff "defaults write com.apple.WindowManager StageManagerHideWidgets -int 1"
abbr -g smwidon "defaults write com.apple.WindowManager StageManagerHideWidgets -int 0"

Although, really, I can't remember the last time I used Stage Manager. I dabbled with it for a wee while, found it vaguely handy in a couple of situations, but it doesn't seem to have stuck as part of my workflow or work environment.

I first got into Python in the mid-to-late 1990s. It's so far back that I think the copy of Programming Python that I have (sadly in storage at the moment) might be a first edition. I probably fell out of the habit of using Python some time in the early 2000s (that was when I met Ruby). It was only 22 months ago that I started using Python a lot thanks to a change of employer.

As you might imagine, much had changed in the 15+ years since I'd last written a line of Python in anger. So, early on, I made a point of making Pylint part of my development process. All my projects have a make lint make target. All of my projects lint the code when I push to master in the company GitLab instance. These days I even use flycheck to keep me honest as I write my code; mostly gone are the days where I don't know of problems until I do a make lint.

Leaning on Pylint in the early days of my new position made for a great Python refresher for me. Now, I still lean on it to make sure I don't make daft mistakes.

But...

Pylint and I don't always agree. And that's fine. For example, I really can't stand Pylint's approach to whitespace, and that is a hill I'll happily die on. Ditto the obsession with lines being no more than 80 characters wide (120 should be fine thanks). As such any project's .pylintrc has, as a bare minimum, this:

[FORMAT]
max-line-length=120

[MESSAGES CONTROL]
disable=bad-whitespace

Beyond that though, aside from one or two extras that pertain to particular projects, I'm happy with what Pylint complains about.

There are exceptions though. There are times, simply due to the nature of the code involved, that Pylint's insistence on code purity isn't going to work. That's where I use its inline block disabling feature. It's handy and helps keep things clean (I won't deploy code that doesn't pass 10/10), but there is always this nagging doubt: if I've disabled a warning in the code, am I ever going to come back and revisit it?

To help me think about coming back to such disables now and again, I thought it might be interesting to write a tool that'll show which warnings I disable most. It resulted in this fish abbr:

abbr -g pylintshame "rg --no-messages \"pylint:disable=\" | awk 'BEGIN{FS=\"disable=\";}{print \$2}' | tr \",\" \"\n\" | sort | uniq -c | sort -hr"

The idea here being that it produces a "Pylint hall of shame", something like this:

  12 wildcard-import
  12 unused-wildcard-import
   8 no-member
   6 invalid-name
   5 no-self-use
   4 import-outside-toplevel
   4 bare-except
   2 unused-argument
   2 too-many-public-methods
   2 too-many-instance-attributes
   2 not-callable
   2 broad-except
   1 wrong-import-position
   1 wrong-import-order
   1 unused-variable
   1 unexpected-keyword-arg
   1 too-many-locals
   1 arguments-differ

To break the pipeline down:

rg --no-messages "pylint:disable="

First off, I use ripgrep (if you don't, you might want to have a good look at it -- I find it amazingly handy) to find everywhere in the code in and below the current directory (the --no-messages switch just stops any file I/O errors that might result from permission issues -- they're not interesting here) that contains a line that has a Pylint block disable (if you tend to format yours differently, you'll need to tweak the regular expression, of course).

I then pipe it through awk:

awk 'BEGIN{FS="disable=";}{print $2}'

so I can lazily extract everything after the disable=.

Next up, because it's a possible list of things that can be disabled, I use tr:

tr "," "\n"

to turn any comma-separated list into multiple lines.

Having got to this point, I sort the list, uniq the result, while prepending a count (-c), and then sort the result again, in reverse and sorting the numbers based on how a human would read the result (-hr).

sort | uniq -c | sort -hr

It's short, sweet and hacky, but does the job quite nicely. From now on, any time I get curious about which disables I'm leaning on too much, I can use this to take stock.

I'm filing this as a TIL because, while it wasn't T, I did L it very recently and it was a new trick that impacted on around 25 years if prior working practice.

I think it must have been around 1991 when I first encountered 4DOS. While I'd used the odd Unix shell here and there previously, it'd only been in passing. It was 4DOS that first introduced me to the power of aliases on the command line. Many of the aliases I set up and used in 4DOS still remain with me to this day, on GNU/Linux and macOS, in some form or another.

I'm sure I don't need to tell anyone reading this why aliases and cool and handy and pretty much vital if you do lots of work on the command line.

And then, a couple or so weeks ago, as a very recent convert to fish, I discovered the abbr command. At first glance it didn't seem to make much sense. It was like alias, only it expanded what you typed rather than acted as a command in its own right.

I did a bit of digging and some of it started to make sense. One thing that really won me over -- and while it's something that doesn't directly impact on me -- was the argument that it allows for a far more transparent command history; especially if you're likely to use a transcript of a shell session in a place where people might not know or have access to your aliases.

Imagine being in a position where you have loads of handy and cool aliases, but you also need to record what you've done so other people can follow your work (does it show that I sit amongst people who maintain lab notebooks?); it seems like it would be a bit of a bother needing to record all of the aliases in your own work environment up front. Without that information few people will be able to make sense of the recorded commands, with that information they'd still need to double-check what each command does.

So imagine an alias that, when used, expands in place. Then you'd get all of the benefit of aliases while also having a full and readable record of what you actually did.

Seems neat!

Here's a silly example. For a long time I've carried around an alias called greedy that runs something like this:

du -hs * | sort -rh

It's pretty straightforward: I'm using du to get a sense of which directories are using what space, and then using sort to make a worst-to-best-offender list out of it. So I could use an alias:

alias greedy="du -hs * | sort -rh"

The only downside to this is that, any time I run it, if I were to record the shell session and make it available for someone else to read, they'd just see:

~/develop$ greedy
1.1G    JavaScript
824M    C
699M    rust
 93M    python
 33M    fonts
 33M    elisp
3.4M    zsh
3.0M    misc
1.1M    bash
840K    ocaml
428K    C++
316K    lisp
172K    Swift
152K    git
132K    ruby
 28K    ObjC

Now, with an abbreviation rather than an alias, I'd type greedy but as soon as I hit Enter it'd get expanded to something anyone could read and follow:

~/develop$ du -hs * | sort -rh
1.1G    JavaScript
824M    C
699M    rust
 93M    python
 33M    fonts
 33M    elisp
3.4M    zsh
3.0M    misc
1.1M    bash
840K    ocaml
428K    C++
316K    lisp
172K    Swift
152K    git
132K    ruby
 28K    ObjC

This is far from the only benefit of abbreviations; for most people it probably isn't one of the most important ones, but I find it neat and compelling and this alone drove me to rework almost all of my aliases as abbreviations.

Having done that, I get other benefits too. For example, fish (like other shells) has good support for argument completion for well-known commands. The problem is, if you alias such a command, you don't get that completion. With an abbreviation though you do! All you need to do is type the abbreviation, hit space and it'll expand to the underlying command and then the full range of completion can happen.

There's also one last reason why I like abbreviations over aliases, and it's kind of a silly one, but in a good way. It's actually fun to see what you type magically expand as you do things, it makes you look like you can type even faster than you normally can! ;-)

PS: If you've never tried fish before and you're curious, it's easy to try in your browser.

These days fish is my shell of choice. I started out with bash back in the 1990s, went through a bit of a zsh/oh-my-zsh phase, but earlier this year finally settled on fish.

At some point I might write a post about my fish config, and why fish works well for me. But that's an idea for another time.

In this post I thought I'd share a little snippet of code that can come in handy now and again.

Sometimes I find myself inside a git repo, in the shell, and I want to get to the "forge" for that repo. This is most often either on GitHub, or in a company-local installation of GitLab. To get there quickly I wrote gh.fish:

##############################################################################
# Attempt go visit the origin hub for the current repo.

function gh -d "Visit the repo in its origin hub"

    # Check that there is some sort of origin.
    set origin (git config --get remote.origin.url)

    # If we didn't get anything...
    if not test "$origin"
        # ...complain and exit.
        echo "This doesn't appear to be a git repo with an origin"
        return 1
    end

    # Open in the browser.
    open "https://"(string replace ":" "/" (string replace -r '\.git$' "" (string split "@" $origin)[ 2 ]))

end

### gh.fish ends here

The idea is pretty simple: I see if the repo has an origin of some description and, if it has, I slice and dice it into something that looks like the URL you'd expect to find for a GitHub or GitLab repo. Finally I use open to open the URL in the environment's browser of choice.