[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Linux keyboard mapping files ...

On Fri 02 Jul 2021 at 02:24:20 (-0400), Albretch Mueller wrote:
>  David Chartash at the corpora research mailing list pointed out to me
> I could find what I wanted at:
>  http://kbdlayout.info/

That's for Windows, isn't it.

>  and within Debian using `man 5 keyboard`

Yes, as it says, this will explain how you use the files I mentioned
to configure a keyboard.

> > There's no such table: it cannot exist. Which unicode number would you
> > assign to CapsLock, or RightShift. There are several layers of
> > translation which lie between pressing/releasing a key and assigning
> > a character to the result. Some of these tables are built up out of
> > component parts, like the basic letter keys, the "shift"s at their
> > edges, function keys, keypads, multimedia, etc.
> > For a start, mapping key depressions to unicode text is a many-to-one
> > mapping.
>  Well, when I said "look up table" I meant also such sequences of
> chars including escape sequences which end up being written as a
> character in text files. Non-alphabetical languages use input methods.

Yes, that's why I brought up Compose sequences. One might think of
Compose as the introducer of printed-characters just as Escape is
of Control-characters.

My point about the mapping of unicode → keys depressed² seems to
have been missed. On this keyboard, I can type ø by
. holding AltGr and typing o
. typing CapsLock / o
. typing CapsLock o /
so if you were to meet ø in your subject text, how would you
determine which keys were struck in order to add them to your
heat map?

> > ¹ AltGr o yields ø, fair enough,
> >  but
> >   CapsLock /o yields ø
> >   CapsLock 'o yields ó
> >   CapsLock `o yields ò
> >   CapsLock ^o yields ô
> >   CapsLock ~o yields õ
> >   CapsLock -o yields ō
> >   CapsLock "o yields ö
> >   CapsLock !o yields ọ
> >   CapsLock .o yields ȯ
> >   CapsLock #o yields º
> >   CapsLock oo yields °
> >  and there's really no limit, so long as I can recall them:
> >   CapsLock co yields ©
> >   CapsLock ro yields ®
> >   CapsLock so yields §
> >   CapsLock %o yields ‰
> >  and you don't need an AltGr key, and you can configure it
> >  to seamlessly work on both VC and in X.
>  From your examples you included I will only need yielded glyphs if
> they are commonly used in a language. Now, defining "commonly used"
> would be an entirely different, yet valid question.

If you look at my email address, you'll realise that I don't type
diacritics very often. So composing one as above, from its appearance,
is much easier than memorising which shifted key³ it's bound to.
And the same emphasis on appearance is how "they" and I choose to
compose symbols, which I type much more frequently.

>  I will have to code my way through those files to parse unicode <->
> key (or key sequence) "lookup tables" for each language and my effort
> will need definitely more than "parsing" for non-alphabetical
> languages.

² Most of the documentation I've seen concerns itself with the
  direction keys depressed → characters rather than the opposite.
  After all, any reverse document presentation is going to be
  incomplete, and nobody much cares because all you need to do
  in most editors to type a bizarre character is specify its
  raw codepoint.

³ None of the British and American keyboards layouts in that
  reference above bear much resemblance to the ones I possess,
  particularly in their engraved diacritics.


Reply to: