Input methods for Unicode characters in editors and the shell | Hacker News Reader

Input methods for Unicode characters in editors and the shell

doc.perl6.org

38 pointsstesch34 comments

I love OSX's mnemonics for entering non-ascii. I don't know if they differ from keyboard layout to keyboard layout, I use US English.

Option-e then a vowel produces that vowel with an acute accent. I think "español". (Oh, `option-n, n` produces ñ). Option-! produces ¡ (upside down bang used in spanish).

Option-u then vowel produces vowel with umlaut/diëresis ö ï ä ë.

Option dash is an en-dash and shift-option-dash is an em-dash. Option-< is ≤ and option-> is ≥. option-= is ≠. shift-option-2 (ie option-@) produces the euro sign € (I wonder why it isn't option-$, it was probably already used for something else, oh well, only so much room for mnemonics).

Those are the only ones I currently remember, because those are the ones I use anything close to regularly, but many other non-ascii characters have similar mnemonics using the option key, if I need one I look it up and use it.

Works in just about any software at all, including the terminal.

I don't know why other OS's haven't done similar. Maybe lack of that useful extra 'option' key, the other meta keys may already be taken for other purposes in other OS's.

> Option-e then a vowel produces that vowel with an acute accent. > Option-u then vowel produces vowel with umlaut/diëresis ö ï ä ë.

What uncharacteristically unintuitive for Apple. On my keyboard (Linux with AltGr dead keys), AltGr-` followed by a vowel produces a grave accent, AltGr-' produces an acute accent, and AltGr-" produces an umlaut.

And now you don't have a right alt key.

And now I finally have a use for that right alt key.

You could map it to something else. I like having AltGr mapped to right Win, because I never use that key (I use left Win as Super, but I never touched the right one until I swtiched to an international keyboard layout).

I wonder why OP doesn't mention this? It just discusses various methods to enter unicode codepoint values numerically.

The compose key is far more intuitive for infrequent use [1]

To type ñ, type Compose, ~, n.

To type →, type Compose, -, >.

To type €, type Compose, C, =.

To type —, type Compose, -, -, -.

To type {vulcan salute, which HN strips}, type Compose, L, L, A, P. (Actually, this doesn't work for me, although it is present in /usr/share/X11/locale/en_US.UTF-8/Compose.

[1] https://en.wikipedia.org/wiki/Compose_key

Seconding this. No other method of inputting special characters feels nearly as intuitive as the Compose key.

I personally like to map Compose to the Menu key, because the Menu key's default behavior is totally useless.

The menu key's functionality is also usually available through Shift-F10 as well, so swapping a more useful key into its location doesn't lose you anything.

That sounds good too. Is that built into some OS/UI's? Or what do you use to add it to what you use?

If it's standard in Linux (?) wonder why OP didn't mention it?

It's standard in Linux, but needs to be enabled. Look for it in your advanced keyboard preferences, or do:

    setxkbmap -option compose:menu

to add it to the menu key.

OS X seems to make much better use of Alt than Windows does. Here in the UK, Alt Gr on Windows provides the Euro sign, acute accents... and that's about it, I think.

On OS X you get a set of different accents, dash sizes, ligatures, quotes, Greek symbols, and so on.

I have a problem with that approach as it superimposes the fifth level modifier key with the meta (alt) motifier key. When running my ubuntu I can rearrange the modifier keys that fits my use case the best (Caps lock and AltGr as ISO_Level_5, left Alt and right Super as Meta, etc) under OSX those all become the same key, and I either loose the ability to write common characters as `@` (AltGr + q), `}` (AltGr + 0) or the ability to execute common commands with simple key strokes like "Fill paragraph" (Meta + q) or "Forward word" (Meta + f).

This non-sense has resulted in most of my co-workers swapping keyboards altogether with the English keyboard and writing the ascii equivalent of special letters (ae → æ, d → ð, þáði → tadi, etc.) because swapping keybards (even though it is only one command; Shift + Option + Space) becomes such a pain if you have to do so many times over the day.

I've seen some complaints about this, but the existence of Texas versions of the operators makes this absolutely fine in my eyes.

I don't see why people would begrudge the ability to use the 'proper' mathematical symbols just because they're slightly harder to type.

Of course, it's another situation where Perl 6 is just crazy, but crazy awesome :)

I instinctively feel like I'm going to run into some stupid problems, but I blame that on the extreme difficulty in 2015 of getting UTF-8 to work consistently with the mess of locale variables, terminal emulator configuration, vty multiplexers, editors, source control systems, MIME types, and who knows what. Pretty much every time I've put Unicode symbols in source code I've ended up regretting it later for some frustrating reason. There are always solutions though... and kudos to Perl 6 for giving it a shot.

I'm sure you're right, the REPL uses Linenoise which is single byte character only for example.

The only way to fix these problems though is to increase their use, so ultimately the end goal will be worth it. That seems to have been the Perl 6 mantra for a decade or so.

Tip: don't install Linenoise and use rlwrap instead. You get unicode, history across sessions, and if you tweak it right tab completion.

For anyone confused by "Texas versions", this might help: http://design.perl6.org/S99.html#Texas_operator

My apologies, I didn't notice that it wasn't explicitly mentioned on the input page.

Inputting Unicode in X Windows is easy. Just type:

  setxkbmap -option compose:ralt

Now, right Alt (AltGr) is your compose key.

Then, for example:

  à is Compose + ` + a
  ö is Compose + " + o
  ß is Compose + s + s
  ç is Compose + , + c
  € is Compose + = + e

In Emacs, the easiest way to input Unicode directly is to set read-quoted-char-radix to 16 in your .emacs. Then use C-q (typically bound to quoted-insert) to input a glyph directly via hex code point.

  ∀ is C-q + 2200
  λ is C-q + 3bb
  ∃ is C-q + 2203
  若 is C-q + 82e5
  世 is C-q + 4e16

An easier way is to dial up a character map program like gucharmap and copy and paste.

I've always wondered why it wasn't the default in Linux to have a compose key configured, and I used to have it set in the distant past.

I just found it's editable in the Gnome settings editor. Browse to Keyboard->Shortcuts->Typing. Then click the "Disabled" next to Compose, which will allow selection of the compose key. The directions at the bottom of the settings window are simply incorrect, or don't apply to this particular screen, I dunno. Regardless, it works well for most common characters (the only language I regularly type with need for them is Spanish, so it covers all the bases there).

Or you could use linux and XCompose and set up easily recallable shortcuts for frequently-used symbols that don't have them already. I think trying to use and remember different input methods in different apps is insanity.

That's what I came here to say. I can't believe the use of the compose key isn't more common. I just remap caps lock (which I don't like) to compose and kill two birds with one stone...

On a lot of Linuxes you can use alt-gr for third level keys too, which is handy for «» for example (altgr + z, x) or “” (v, b)

I imagine it's uncommon because it's thoroughly undiscoverable, and not super useful by default for lack of a good .XCompose file. I know how this stuff works and I haven't bothered because I don't want to figure it out again on each machine / desktop environment / etc.

The "bash" thing seems to actually be a GTK+ thing (and that's how Wikipedia documents it), and probably only works in gnome-terminal and a couple of other X11 terminals. I can't seem to get this to work in iTerm2 + OS X bash nor iTerm2 + ssh + Debian bash.

On the other hand, I guess I'm running OS X so I merely need to re-memorize all the Mac mnemonics that I knew back when I used OS 9, and have now forgotten in favor of GNU screen's digraphs....

On OS X, Ctrl-Cmd-Space brings up the Emoji palette. From there you can also search for other kinds of Unicode characters.

The built-in panel has gotten better in recent versions of OS X but still has some quirks. It doesn't copy the character into the clipboard (it copies the full description along with it, and even that requires a right-click), but you can double click things to paste a character into the app that previously had focus, most of the time that works pretty well.

Before I found out about the built-in panel I wrote a menu bar app[0] that does copy directly to the clipboard, and I still use it since that's what I need more often than the "paste into previous app" behavior of the built-in panel.

[0] https://itunes.apple.com/us/app/codepoints/id499161264

Copy to the clipboard? Ctrl-Cmd-Space brings up a panel that directly inserts text.

Provided the application you're using supports it.

For example I just needed to insert some UTF-8 characters into MacVim, which doesn't support this palette. So I had to:

- switch to Safari

- open the palette and find the character

- make sure a text field is focused *

- double-click to insert *

- finally copy the character *

Those last few steps wouldn't be needed if one could simply copy just the character from the palette.

(Disclaimer: normally I would just search google for "Unicode _____", but wanted to try this after seeing it mentioned)

I'm using tcsh, and recently found out that it is practically impossible to enter curly-braces { } into it. For example:

    echo "{"
    echo '{'
    echo "\{"
    echo '\{'

all fail. This makes tcsh totally unsuitable to work with, for example, JSON expressions.

I just opened tcsh and all of "{", '{', and \{ (an option you missed) work.

Hmm, okay, upon closer inspection, you are right. The problem I have is that I have the following definition in my .cshrc file:

    alias precmd 'echo `date` "#@#" `pwd` "#@#" `history 1` >> ~/.complete_history'

This basically saves all my commands to a file (which is very handy, by the way).

So somehow this interferes with the curly braces. I put the history part in double-quotes, and now it works:

    alias precmd 'echo `date` "#@#" `pwd` "#@#" "`history 1`" >> ~/.complete_history'

Thanks for helping me solve this :)

XCompose is great for this (oddly, it's completely missing from the page): Compose+th = þ, Compose+"u = ü &c.

Reply on news.ycombinator.com