2012-11-22
A little Unix difference that irritates: what word erase erases
I (still) use a number of different Unixes. For the most part they aren't particularly different in day to day use, but it turns out that there is one little difference that really gets to me. That is what TTY word erase (usually Ctrl-W) erases, or the other way to put it, what it stops erasing at.
In most environments, what C-W considers to be a 'word' is 'everything back to the previous whitespace' (or the start of the line if this is the first word on the line). Suppose that you're typing this:
$ cd /some/whre
The cursor is at the end of the line and you hit C-W; you'll erase
all of the /some/whre, going back to the whitespace between the
cd and it.
But on some systems, C-W also breaks words at some non-alphanumeric
characters; I'm not sure what characters exactly, but they definitely
include '/'. On these systems if you hit C-W at the end of our sample
line, you will just erase the whre and be left with 'cd /some/' (if
you then hit C-W again it erases 'some/', so cleverness is going on).
(This may be a Linux-only behavior, since that's the only thing I can reproduce this on right now.)
It turns out that the second behavior is much more convenient for me. When I'm erasing words, I almost always want to consider the various components of a long path to be separate words; if I want to get rid of the full path, hitting C-W a few times is fast, and if I just want to erase and retype the last component because I've made a mistake in it (as in this example) that's something I can actually do. With the whitespace-only model of word erase it's much more irritating to make a mistake in a path or the like.
Of course this is basically irrelevant to most people these days. This word erase behavior only applies if you're relying on the kernel's handling of line input. Most people are using shells with built in command line editing (and the programs they use will often use readline); in those programs, word erase behaves however the program or library wants it to. I'm an exception because my shell doesn't have command line editing.
(In bash, word erase seems to be 'erase to whitespace'. There is probably some readline control or option for changing this, since readline has a huge collection of customization options.)
Optional features are in practice not optional to understand
In a comment on yesterday's entry, Aristotle Pagaltzis suggested that Markdown might be acceptable to my coworkers in part because:
It is just HTML! You can type HTML and it will come out verbatim. It's not really a separate markup language (simple or not) so much as a shorthand notation for HTML.
So you don't have to use Markdown's syntax instead of HTML. Forget how to write a link in Markdown? Just write it using HTML syntax. Will work either way.
[...]
This is a valuable feature and drastically reduces the learning curve for Markdown for writing things yourself; effectively you can learn bits and pieces of Markdown as you decide they're more convenient than straight HTML. Unfortunately this doesn't help persuade my coworkers to accept it because of a semi-paradox that optional features are in practice not optional.
The easy way to show this is to ask whether or not my coworkers ever need to learn Markdown and if so, when they need to learn it. To start with, if we never use Markdown syntax at all the answer is clearly no. But at that point Markdown isn't doing anything at all (except perhaps getting in the way because we have to escape things so that it doesn't process them); we might as well write HTML files and not process them through Markdown.
But suppose we use some Markdown. More specifically, let's suppose that I write in Markdown (as I'd like to) and my coworkers write in HTML (as they'd like to). Can they avoid learning Markdown? The answer is not really; the moment they want to touch something that I've worked on, they need to learn Markdown. In fact Markdown has a ratchet effect in this situation, in that the moment anyone introduces any bit of Markdown everyone winds up needing to know it in order to be able to understand and work on that bit of the text. If you do not learn Markdown, you're confined to the (probably shrinking) HTML-only content.
This is what makes optional features not optional to understand; they are only optional as long as they're not being used at all. The moment that they get into your codebase (or document base, or anything), you can no longer understand and work on the full codebase without learning them. Either you segment the codebase and responsibility for it or everyone gets to learn the optional feature.
(I have to thank my coworkers for patiently getting this idea through my thick skull.)
As suggested by my use of 'codebase' here, extensions to programming language features (and the use of entire programming languages) are left as an exercise for the reader. Really, there are lots of manifestations of this in development.