# Non-breakable Space Problems

On OS X and apparently also some Unix-based machines you may have encountered a strange behaviour (in my experience especially on Laptop keyboards). On the shell it sometimes might just happen that you pipe something and get an error message. E.g.

pygospa@lalaith ~ % ls -ahl | grep .log
zsh: command not found:  grep

Retyping it may then bring you:

pygospa@lalaith ~ % ls -ahl | grep .log
-rw-r--r--    1 pygospa  staff    54B 15 Nov 11:55 tmux-client-8140.log
-rw-r--r--    1 pygospa  staff    24K 15 Nov 11:55 tmux-server-8142.log

So, what just happened? To me this actually happens so seldom that I never even bothered to try understanding. Therefore I often encountered another problem wich started annoying me. When editing a TeX-File, every now and then I got this error message:

! Package inputenc Error: Unicode char \u8:  not set up for use with LaTeX.
l.193 \end{align*}


I discovered that rewriting (not copying!) the line does some good. So it had to be some non-printing control character, and after searching for “OS X, Latex \u8 error” (I initially assumed that it must be an OS X thing, as I never encountered it in LaTeX on my Linux days – I now assume that it’s rather a Keyboard thing) I found a quick and dirty solution to it, adding this line:

\DeclareUnicodeCharacter{00A0}{ }

So the non-visible Unicode sequence was overwritten with a space. And thus I was never bothered again when editing LaTeX.

But now, while writing some RSpecs for a Ruby on Rails project I am working on it occurred again, and in RSpec there’s no quick and dirty solution that can be written into some preamble to fix an input error.

At first I wasn’t even sure that it again was the same problem. I hardly ever encountered the Problem in the Shell, in LaTeX it just occurred when I was on the go (with my Laptop) and after two or three times I just looked for this quick and dirty solution. So I soon forgot about it again. And only now after spending some time figuring out all kind of varieties of errors this annoyance caused (see following example) I came up with a permanent solution.

     Failure/Error: let(:new_name) { "New Name" }
NoMethodError:
undefined method  ' for #<RSpec::Core::ExampleGroup::Nested_1::Nested_3::Nested_3::Nested_3:0x007fb4c3623a70>
# ./spec/requests/user_pages_spec.rb:76:in block (5 levels) in '
# ./spec/requests/user_pages_spec.rb:79:in block (5 levels) in '

As it turns out, it is the lovely Non-breaking Space, you might have seen it in HTML, as &nbsp;, in XML/XHTML as   and in TeX/LaTeX as ~. In Unicode it is U+00A0.

Now there is no standardized way to input this character via Keyboard, but defined in the Finish national standard (FSF 5966) it is entered by pressing Alternate Graphic key together with the Space key (AltGr+Space). Now surprisingly, though it is no international standard, Unix-Machines might be set up to do the same, and so is OS X, though there’s no Alternate Graphics on Macs, but an Option key (alt+Space).

Whenever you need the AltGr/Alt key, e.g. for printing | or { }, etc. and you are just a moment to slow with your finger, you might still be press AltGr/alt while hitting Space, leading to print an Non-breaking Space. Now while in WYSIWYG text editors this might not make that a big difference, the compiler doesn’t know how to handle this character and most likely interpret it as part of the name, and not as wrong type of space. So U+00A0grep isn’t found, U+00A0 isn’t the way to enter a special character in LaTeX, and if not defined in any module, Ruby cannot find a method called U+00A0 that takes a String literal as an argument.

Now, though pretty obvious, what can you do, if you are a fast typer and often get bothered by the problem this little fellow causes?

If you are on OS X, just add following content into a file and place it under ~/Library/KeyBindings/DefaultKeyBinding.dict:

{
"~ " = ("insertText:", " ");
}

This will actually do the same as the above TeX example, only on input level, i.e. before the character get’s send from keyboard to the application. So from now on pressing alt+Space on my OS X will not send U+00A0 to the application but U+0020, which is the plain and simple Space that I normally want to insert (I actually never needed a non-breaking Space, and if I did, it was in LaTeX, where I use ~, or in HTML where I referred to &nbsp;). The file and directory might actually not exist, and if you’re not used to working with the terminal and try to find it with the Finder, you’ll fail, as the ~/Library-Path is hidden by default. In this case just hit cmd+shift+g, and then enter ~/Library and create the KeyBindings-Folder and the DefaultKeyBinding.dict. That file is pretty interesting, just take a glance at Customizing the Cocoa Text System, to get a feel for the potential of this file.

If you happen to encounter this problem a lot on a Unix running X Window System, there’s also a solution, using the X Keyboard Extension. Either add the following line to your profile File (~/.bash_profile, ~/.bash_login, ~/.zshrc, or whatever your system uses):

  setxkbmap -option "nbsp:none"

or for a system wide changed behaviour edit your xorg.conf to include this line:

  Option "XkbOptions"    "nbsp:none"`

You could also just use the first one in the console for a temporary changed behaviour.