Category Archives: Writing

Understanding the word “semantics” in the context of programming

tl;dr- It’s usually safe to substitute the phrase behaviors and guarantees into a sentence where you see the word “semantics”–and the discussion is about programming.

Longer version: New programmers often come across the word semantics, and wonder what it means. Pretty much every explanation they will read points out the distinction between syntax (form) and semantics (meaning). This is easy to grasp, but not useful for understanding the word in the context of a sentence like: The stylistic choices should typically be driven by a desire to clearly communicate the semantics of the program fragment.

Go ahead and substitute the word “meaning” there. It isn’t much help unless you’re already an experience developer.

So to that end, new programmers… if ever you come across this word, it’s generally safe to substitute the phrase behaviors and guarantees in its place. This may help you understand the semantic intent (ha!) of the writer a little more.

3 ways to make the CLI (cmd.exe) more friendly

By default, cmd.exe isn’t especially friendly for most tasks, including basic things like copying and pasting text. Displaying long paths while still allowing you to see the commands you’re typing is even worse. Here are a few ways you can make the Windows shell less awful to work in.

Quick and easy stuff

First, the point-and-click options. Right click the bar, go down to Properties. Set the colors and font to whatever floats your boat. On the Options tab, and enable QuickEdit and Insert modes; this allows you to left click highlight/copy text, and right click to paste into the CLI window. (There’s a reason this isn’t enabled by default.)

On the Layout tab, increase the Screen Buffer Size to something more useful. Mine’s set to a height of 1000. If you want the CLI window to be larger or smaller, you can do that, too.

Getting fancier

By default, my fingers type ls when I want the contents of a directory. When I’m in bash, I generally have ls aliased to ls -l, which is pretty close to the standard Windows dir command, so I’ve edited my registry to do this every time cmd.exe is launched (download .reg 258 bytes):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"AutoRun"="doskey ls=dir"

(You can also do this is HKEY_CURRENT_USER, if you’d prefer this to be a per-user setting.)

If you don’t have permission to edit your registry, or don’t want to, or would rather come up with a script-y way of doing things, the command is “doskey ls=dir”, so you can type this into the CLI whenever you want, or write a script to do this another way. You can also add in other commands, if you find your fingers typing grep instead of findstr, for example.

Icing on the cake

This next piece is, in my opinion, the single most useful thing you can do to make the shell friendlier, aside from enabling Insert and QuickEdit. Using the prompt command, you can alter the appearance of your shell prompt. For example, to get a Unix-like prompt, you can do this:

prompt=$p$_%username%@%computername%:

To get a Terminal.app style prompt, you can do this:

prompt=$p$_[%username%@%computername%]$$$s

As I’m the only user on this machine, and I’m really only interested in my current working directory, I go with a simpler:

prompt=$p$g$_$$$s

which gets me a prompt that looks like this:

My cmd prompt

Play around with the prompt command until you find a setting that you like. (Type “prompt” with no arguments to go back to the Windows default if you make a mistake.) Once you’ve found a setting you like, you can make the change permanent by editing your environment variables.

Tap the Windows key, type “environment variables”, and select “Edit the System Environment Variables”. (You’ll need to be logged in as an Administrator.)

edit system environment variables

Then do the following, entering your prompt options without the equals sign. Click OK and you’re finished!

Set prompt environment variable

The final results of the above look like this:

Final results

Making Word less awful for technical writers

Yesterday Carol Saller, the senior editor of the Chicago Manual of Style, had a post on taming some of Word’s infuriating features. There are some good suggestions there, but I thought I would offer another tip which may be helpful for technical writers, and others who work with a lot of non-standard language: turning off spelling and grammar checking on specific user-defined Styles.

(While I’m going to show you a quick and dirty method of solving this problem in an existing document, you may want to follow the same steps to modify your document template(s).)

Most of my technical writing is for the software industry, which means I work with code examples quite a bit. The idea of checking the spelling and grammar of Python code is a little ridiculous. Have a look; it’s gross:

before monospace font Style

It’s easy to get rid of all this ugly red and green by quickly defining a new Style. Selecting the code or text that you’d like to change, and then create a new Quick Style:

Save Selection as a New Quick Style

Give your Style a name–I’m calling mine “Code”–and then click “Modify”. You can make whatever changes you like there, then head down to “Format” and click Language:

MS Word Format Language

Tick the “Do not check spelling or grammar” checkbox:

Don't check spelling or grammar

Voila! Happy code example. In the Ribbon, you’ll see that the text has been set to the new Code Style:

Happy code 1

If you have other text in your document that needs to be changed to this new Style, find some, then on the Home tab on the Ribbon, go all the way over to Editing -> Select -> Select Text with Similar Formatting, and then apply the new Style to all of the selected text in the document.

Select Text with Similar Formatting

The result is this:

Happy code 2