Xcode Docs Navigator

[The following is basically a transcription of a series of tweets.]

I have my wishes and druthers regarding the Xcode docs, but the Navigator pane in the docs window is pretty nice. Sometimes I want to learn the lay of the land of an unfamiliar framework. The docs Navigator is organized well for that use case.

Screen Shot 2018 07 26 at 1 47 40 PM

I like this list of Sequence and Collection protocols. For me it helps to have things like this summarized in one place. When I dive into a new project with an existing code base, I sometimes make a similar list by hand — for example, an outline of a particular class hierarchy.

Sequence and Collection Protocols

I like that there are "First Steps" sections for many of the frameworks. It's good to present them in this structured, discoverable way. They remind me of the old "concepts manuals" in NeXTSTEP.

Core Location First Steps

UIKit First Steps

One suggestion for improvement: IMO it would help to add an "Xcode" tab here:

Xcode Docs Navigator Tabs

The stuff that's in Help > Xcode Help > Show topics could be moved there. It would be more discoverable, it would provide a unified UI for all of Xcode's documentation, and we'd be able to open help topics in new tabs.


I've known for a long time that who am i prints info about the current user. Today I learned it's synonymous with who -m, though not synonymous with whoami.

I also learned that the two words after the who can be any non-option arguments. The Linux man page says:

If ARG1 ARG2 given, -m presumed: 'am i' or 'mom likes' are usual.

For example:

$ who -m
alee     ttys019  Jan 28 21:58 

$ who am i
alee     ttys019  Jan 28 21:58 

$ who mom likes
alee     ttys019  Jan 28 21:58 

$ who fred wilma
alee     ttys019  Jan 28 21:58 

This works on the Mac too, even though the Mac's man page only mentions am i and not that you can use any two words.

So of course I've now added an alias whom so that I can type whom Mom likes. I actually pride myself on not being a grammar pedant. I make an exception in this case because it amuses me.

Using Xcode for Advent of Code 2017

This year I'm using Swift as much as I can for Advent of Code. After fiddling with a few different coding environments, I settled on Xcode. I have a "Command Line Tool" project that I reset everyday to contain some minimal boilerplate code. Starting with that, I code my solution for the day's AoC puzzle.

This might seem like the obvious choice — what else would one use for writing Swift code? — but I actually started out with CodeRunner, a great tool that I used last year as well. I switched to Xcode after a few days because I was having trouble getting Swift breakpoints to work in CodeRunner.

On top of that I realized how helpful the other goodies in Xcode are, even for one-off exercises like AoC. By using Xcode I get integration with the documentation, automatic "fix-its" for common syntax errors, and "Edit All in Scope". That last feature is handy because when I catch myself agonizing over a name I can stop, use anything quick that comes to mind, and move on. It'll be trivial to change the name when a better one comes to me, usually while I'm on some other part of the code. I don't need the full "Refactor" feature, which is a bit slower to use, because all my code is almost always in one file.

I do keep CodeRunner on my Dock and use it all the time to try out bits of syntax in various languages. It's much easier to open a new file and start coding, and possibly never even save the file, than to set up a full-blown project directory. I have used Swift, Python, Java, and Objective-C to code AoC solutions, all in CodeRunner, and usually the integration with the respective language's symbolic debugger worked fine.

You might think a Swift playground would be just the thing for AoC, but I have not found that to be the case. For one thing, as far as I can tell there is no support for symbolic debugging. For another thing, AoC puzzles sometimes involve loops with millions of iterations, and it is prohibitively slow to have the results pane updated on every iteration. As far as I know there is no way to turn that off.

Out of curiosity I took a quick look at AppCode and VSCode. Both are highly un-Mac-like and required more of an investment than I was willing to make at this time.

An approach I might try when I'm feeling my hacker oats is to do my Swift coding in Terminal, with vim in one window and lldb in another. The oats aren't quite there yet, though. Maybe next year.

Enjoying Another Advent of Code

On his blog, Karthik Balakrishnan wrote:

My interest in competitive programming dwindled pretty quickly and eventually I stopped doing it all together.

Until I discovered Advent of Code.

The whole article describes exactly how I feel, except I'd never even tried competitive programming before. The very thought of it fills me with dread — or at least it did until, like Karthik, I was turned on to AoC when I was at the Recurse Center. I enjoyed it so much I looked forward to it all this year, and I was delighted when December finally came around.

I liked this too:

As time goes by, I see this becoming more a battle of who can keep the cadence of doing this every day (instead of within minutes/hours).

So far this year I've been hustling to solve each problem as fast as I can. At some point (and to be honest I'm not there yet) I will settle into a "cadence" where I take the time each day to savor the feeling of methodically solving a problem and learning stuff along the way. This will happen naturally as the problems get harder, kind of the way New York Times crosswords get harder throughout the week. I get a different kind of pleasure from a Saturday puzzle than I do from a Monday puzzle.

I've been posting code and brief commentary each day on GitHub. Many others do the same, at their own links and on r/adventofcode.

Workarounds for Font Glitches in BBEdit 12.0.1

[UPDATE: Wow, Rich Siegel of Bare Bones replied to my email within a few hours — on Thanksgiving morning! See the updates below.]

Issues in BBEdit 12.0.1:

  • If I change the default font using BBEdit > Preferences… > Editor Defaults > Default font: > Select…, the display of currently open documents doesn't change. They keep using the old font, even if I resize the window to force the text layout to update. (This "nudging" used to be needed in older versions of BBEdit to get font changes to get applied to open documents.) Newly opened files do use the new font preference.

    • Workaround: either relaunch BBEdit or close documents and reopen them.
    • UPDATE: This is fixed in 12.0.2. I thought I had reproduced the bug in the beta of 12.0.2 but was mistaken.

  • If I open the Font Panel with ⌘T (View > Text Display > Show Fonts) instead of through Preferences, I can modify the font of the currently open document — but only that document. Same Font Panel, different effect. Furthermore, that particular document is stuck with that font across launches, because the association between font and file is remembered in ~/Library/BBEdit/Document State.plist. As far as I can tell there's no UI for telling that file to revert to the default font preference.

    • Workaround: quit BBEdit, delete Document State.plist, and relaunch.
    • UPDATE: Persistent per-document fonts are actually a feature. The UI I had missed was the Edit > Normalize Options… menu item, which changes the document back to using your Preferences settings.

I've reported these to Bare Bones. They've always been responsive to my issue reports. If I'm missing something they'll let me know, presumably after the Thanksgiving holiday.