Re: Dead keys

theOn Sat, Jan 23, 2016 at 12:11 AM, Chris Jones <cjns1989@gmail.com> wrote:
> Just curious about this and couldn't find anything online.
>
> Has anybody heard of a dead key scheme where the user hits the printable
> key first and then adds the diacritic? Same as what I do when using the
> X server's Compose key.. but without the need of a Compose key.
>
> When you type the Spanish word "qué" for instance, you would first type
> q+u+e... "que" - which has both a different meaning and grammatical role
> from "qué"... and then notice... hmm. I'm missing an accent... So now
> you hit the dead acute key and the "e" at the the end of "que" magically
> becomes "é" in the buffer and "é" is echoed back to the terminal
> replacing the "e" on your screen as if you had backspaced deleting the
> original "e" and typed an "é" to replace it... All in one pass..
>
> Context: I'm proofreading a couple of e-books in Spanish and French
> (using Vim for the editing) and I'm getting aggravated at having to hit
> an extra key each time I need to add or change a diacritic.
>
> As to switching to using dead keys as I have seen them explained (with
> the dead key being hit first and the normal key second at least that's
> how I understood it)... well that would mean I'd have to change some
> rather ancient well ingrained habits. So I'm not sure that would be
> suitable at this point.
>
> So I'm wondering if anybody has ever heard of anything such as this...
> either limited to Vim... or better still... a system-wide solution on
> linux systems running the X window system... possibly as some kind of
> driver/filter/hook...
>
> Thanks,
>
> CJ

Well, "accent after" is the Unicode convention for combining
characters, which are however regarded as characters on their own
right, except that they "share space" with the character preceding
them in the text stream. For instance, Russian has an optional acute
accent, used to indicate word stress in dictionaries, reading courses
(for grade school children or foreigners) and in the rare cases where
the place of the stress changes the meaning (e.g. in a book about
chess, «у белых есть большая выгода» would normally be understood as
«у бе́лых есть больша́я вы́года», "White has a big advantage", but
with different stress: «у белых есть бо́льшая выгода» means "White has
a bigger advantage"). This acute accent is a separate Unicode
codepoint, it just doesn't occupy space on its own.

(
Since you give Spanish as an example, when typing Spanish you could
either use precomposed characters for á é í ó ú ñ (on my Belgian
keyboard all of these [except é which has its own key] are produced by
a two-key chord using the AltGr modifier, followed by a letter key:
see http://users.skynet.be/antoine.mechelynck/other/keybbe.htm), or
you could use the letter followed by a combining character, which
would result in á é í ó ú ñ, which may or may not be uglier
depending on your font and on your mailer's (or other program's)
rendering engine. In the second case you could set the clipboard to
just the Unicode codepoint U+0301 (combining acute accent) using the
Vim command
:let @+ =
followed on the same line by: single-quote ctrl-v u 0 3 0 1
single-quote Enter
and add that to make question words out of que, quien, donde, cuando,
como, etc. This assumes that a missing tilde is much rarer than a
missing acute accent; but you could also add a tilde in the same way,
with 0303 instead of 0301.

Note however that unlike the French and Spanish precomposed
characters, this combining character is not part of the Latin1
charset, which may or may not be a problem depending on the charset
expected by the recipient of your proofreading. It is also slightly
more expensive in media space since in Latin1 e = 0x65, é = 0xE9 (one
byte each) while in UTF-8 e is still 0x65 (one ASCII-compatible
codepoint, one byte), precomposed é becomes 0xC3 0xA9 (one codepoint,
two bytes), and "decomposed" é is 0x65 0xCC 0x81 (two codepoints,
three bytes).
)

OTOH, when typewriters were still widely used, their dead keys used
the "accent before" convention, simply because the character bar
bearing those accents lacked the tooth which triggered a carriage
advance: e.g. in French typewriters, when you hit ^ (circumflex,
without Shift) or " (diaeresis, on the same key but with Shift) the
character bar hit the paper (through the ribbon) and the carriage did
not advance, so that the next character typed (usually a vowel, but
when a French typewriter was used to type in Esperanto it could be a
consonant) hit the paper on the same "character cell" as the diacritic
and made the carriage advance. OTOH, the other accented French
lowercase letters (àçéèù) all had their own keys — on modern French
and Belgian computer AZERTY keyboards they still do; I'm less sure
about Swiss QWERTZ keyboards — and the French typists' tradition
included deviating from the printers' tradition in never typing
accents over capitals (with the possible exception of Ç which could be
awkwardly produced by C backspace comma or vice-versa) and in typing
OE and oe instead of Œ and œ (and also AE and ae instead of the rarer
Æ and æ, which may be found in some Danish or Latin words, and in a
few words such as the given name Lætitia, as it appears spelled-out in
Serge Gainsbourg's song "Elaeudanla téitéia", or the Catholic feast of
Lætare, which some towns use instead of Mardi Gras for their yearly
carnival).

In Vim, you can think of a "dead key" whenever an Insert- or
Command-line-mode mapping (including a keymap item) has a {lhs}
consisting of more than one characters. In those cases, it is more or
less the designer's choice whether to put the accent first or last.
The choice may even depend on which keys are used to mean what; but
remember: as long as you haven't either typed the whole {lhs}, or
typed something which discards all mappings, you won't see the {rhs}.
This may be more or less significant depending on how many successive
characters there are in your {lhs} and on how much your keyboard
charset (used in the {lhs}) differs from your text charset (as output
by the {rhs}). For instance my private russian-phonetic keymap has two
{lhs}es beginning with N (Latin capital N): just N to mean H (Russian
capital en) and also N° (N degree) to mean № (Numero sign). The result
is that whenever I type N for a Russian Н, the vertical-bar cursor (in
gvim) doesn't advance and a latin N is displayed in the same screen
cell ("to the right" of the insertion bar), until I follow it with
either a degree sign (in which case that N becomes №) or with anything
else (in which case N becomes Н, the next character also appears, and
the insertion cursor suddenly moves two cells forward). This is
sometimes a little disturbing; maybe less so for a (moderately) fast
typist not constantly looking at the text screen. For other Russian
letters which don't have a "phonetic" equivalent I use a "preceding"
dead key, usually %: so I have %Z → Ж, %C → Ч, %U → Ю, etc. This
allows me to see immediately the Cyrillic equivalent for Z → З, C → Ц,
U → У, etc.

See also
:help i_CTRL-V_digit
http://vim.wikia.com/wiki/How_to_make_a_keymap


Best regards,
Tony.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.