[Gllug] Xmodmap Help

Krishna Birth krishnabirth at gmail.com
Wed Sep 22 20:00:21 UTC 2010

Then this mailing list software is not UTF8 enabled to read different

Good that you researched nix at esperi.org.uk.

>From what I was told, it seems that Xmodmap is useful for first tests /
implementation and then later it can be implemented to  the one you prefer.

Has Tavultesoft KeyMan (Linux) better solution?

On Tue, Sep 21, 2010 at 11:20 PM, Nix <nix at esperi.org.uk> wrote:

> [I don't believe I blew an hour on this. It's been too long since I
>  did any X keyboard hacking... or my mind has gone. Probably the latter.]
> On 21 Sep 2010, Krishna Birth verbalised:
> > Firstly please note that all k / K letters on this posting are altered to
> ~
> > / ~ (spiritual reasons.)
> You changed the letter K to a black rectangle? Is this something to do
> with the monolith from 2001?
> (Your assumption that most people on this *UK* mailing list will have
> Devanagari glyphs in the fonts on their machine is unlikely to be
> accurate, so both your chosen characters got replaced with the glyph for
> U+FFFD REPLACEMENT CHARACTER. I had to dig around in Unicode tables just
> to figure out what on earth you were trying to represent. In any case,
> replacing common English characters like that is *fiercely* annoying. As
> a tactic to make people not want to help you, messing with English words
> by replacing individual letters with letters from other writing systems
> is a superb one. You're lucky I didn't put thorns in all şe appropriate
> places in şis response. At least şe şorn has deep historical roots in
> English, but even it is fiercely annoying to any modern reader who
> doesn't also happen to read Middle English for a hobby.)
> Nonetheless I have read through the noise. I can't be nasty like that
> without being nice to make up for it. Also, X keyboarding is interesting
> if you have no life like me.
> First, a caveat: my interest in this area lies mostly in the handling of
> keyboards with unusual layouts, so while I've done quite a lot of Xkb
> stuff I'm not an expert on the sort of thing you'll need for this by a
> long chalk, though I do have a reasonable idea of what is and is not
> possible in the X keyboard model (and I'm sorry to say that what you
> suggest appears not to be possible, at least not the way you suggest).
> If anyone here is more of an expert, I'm sure they'll pipe up.
> > I am sorry to thrust this project to you (mailing list).  I am loo~ing
> for
> > advice or if you have the time to construct a ~eyboard mapping.  There
> seems
> > to be some problem regarding "if you assign Mode_switch and
> ISO_Level3_Shift
> > to different keys, you can assign up to six characters to one key!"
> > see http://tr.opensuse.org/SDB:Using_the_Extra_Keys_on_the_Keyboard
> You shouldn't be using xmodmap at all. It is obsolete, terribly limited,
> and when used on systems that are already configured via Xkb (i.e. all
> Linux systems you are ever likely to see) it is also incredibly
> confusing because the interactions between the two configuration systems
> are irregular at best and demented at worst. In particular, xmodmap
> can't cope with Mode_switch very well at all, and has no understanding
> of compose sequences. Peter Hutterer in
> <
> http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html
> >
> calls it a 'keyboard deconfiguration' tool, which I think is quite
> accurate: if you use it on modern systems, your keyboard is likely to
> work worse after you ran it than it did before.
> Unfortunately its replacement, Xkb, is not terribly well documented (in
> much the same way as the sun is 'quite bright'). Again Peter Hutterer
> comes through with some nice stuff:
> <http://who-t.blogspot.com/2008/09/rmlvo-keyboard-configuration.html>.
> Doug Palmer's _Unreliable Guide to Xkb Configuration_ at
> <http://www.charvolant.org/~doug/xkb/xkb.pdf<http://www.charvolant.org/%7Edoug/xkb/xkb.pdf>>
> is the only halfway decent
> approach to a manual I have ever seen, but it too was written by someone
> desperately trying to figure out how the thing worked. There doesn't
> seem to be anything useful written by the actual implementors (and Xkb
> went through at least two major generations in any case, so anything you
> find about the first generation will be inaccurate, and any docs written
> at the time the second generation was implemented are likely to assume
> knowledge of the first!)
> The XKb configuration in x.org is normally kept in /usr/share/X11/xkb,
> which is itself built from datafiles in the xkeyboard-config project
> <http://freedesktop.org/wiki/Software/XKeyboardConfig>. That's probably
> the upstream source you should be looking at for Mode_switch et al.
> (But not for compose sequences. See below.)
> > The diacritics are usually typed with non-diacritic letter.   It would be
> > nice to have facility to use both in convenient way e.g. toggling with a
> > Fonts / Scripts ~ey by permanently turning the Caps Loc~ to a Fonts /
> > Scripts ~ey.
> >
> > Could this be done - When this Fonts / Scripts  ~ey is pressed with a
> letter
> > ~ey it toggles to diacritic letter 1 or 2 or  3 (depending on how many
> > diacritics are there connected with a 'target' letter) - this toggling
> will
> Yes. This sort of thing (toggling the meaning of all keys at once when
> Mode_switch is hit) is indeed what Mode_switch is for. You just can't
> (as far as I know) teach it how to do this with xmodmap. (And if you can,
> you probably shouldn't. xmodmap is rusty and horrible.)
> > need to factor in a 'remain at same spot' and toggle these diacritics
> > feature.  When the Fonts / Scripts ~ey is released then the cursor would
> > move to the next base.
> It looks like you need Mode_switch or the Compose key or possibly both.
> The Compose key lets you string together long strings of keys to produce
> a single keysym: Mode_switch (and ISO_Level3_Swift) let you change the
> meaning of everything on the keyboard in one fell swoop. Mode_switch is
> meant to flip between e.g. writing systems; ISO_Level3_Shift is meant as
> a way to provide an 'extra shift key' to flip between things within a
> single writing system. (However, they *can* be used for quite different
> purposes.)
> You may be able to get closer to what you want with
> Option "XkbLayout" "in"
> Option "XkbVariant" "bolnagri"
> in your InputDevice section in xorg.conf.
> This keyboard layout is described here, with geometry:
> <http://www.indlinux.org/wiki/index.php/BolNagri>. It may at least be a
> useful starting point. (Or you may already have considered and
> discounted it. I don't know.)
> > Referring to the above 32 diacritics, in theory a diacritic letter  could
> > have up to 7 diacritics 'sign' variations per letter:
> This feels very much like a job for a (large) compose table. I don't
> think Mode_switch could do it alone. (Obviously you also need a
> keybinding for the compose key!)
> You can easily add a compose table for your preferred language if X11
> supports it by adding it to the Compose file in the appropriate
> directory under /usr/share/X11/locale/ (their format is hopefully
> obvious from inspection); if such a directory doesn't exist yet, you can
> often start by copying the contents of one of the directories under
> /usr/share/X11/locale to one named after your preferred locale, adding
> that to compose.dir, and hacking at it.
> If you want anyone else to be able to use these compose sequences, you
> probably want to contribute them upstream, to Xlib. The Xlib upstream
> lives on the xorg at lists.freedesktop.org mailing list and is generally
> receptive to suggestions for keysym additions, especially if they are
> real characters in living human languages, like these seem to be: adding
> Klingon or Ogham characters may be a different matter. However, given
> that recent X compose sequence additions included sequences for U+24B6
> CIRCLED LATIN CAPITAL LETTER A (the international symbol for anarchism)
> symbol for Unicode standards geeks with too much time on their hands), I
> suspect that additions for your characters would be a shoo-in, although
> there may be arguing about which actual compose sequences are
> appropriate to generate them.
> > Thus if you can turn the Caps Loc~ into a Fonts / Scripts ~ey that can
> allow
> > up to 7 diacritics variations using this toggle approach:
> The specific toggle approach you suggest is not implementable under X,
> as far as I know. Mode_switch and ISO_Level3_Shift let you get as high
> as four (and, with difficulty, six) symbols, but there is no way to tie
> those into the keyboard in such a way as to make 'repeatedly tap' work
> right. A custom input method could do it, I think, but that is even more
> black magic than hacking the compose tables. Again, ask on the xorg list
> (but note that the skilled X keyboard and input method hackers are
> really, really busy people, and there are only about three of them, so
> if you mess with all your letter k's in your mail to the xorg list, they
> are almost certain to decide that it is too much trouble to read
> anything you write. That's the nature of high-traffic lists, I'm
> afraid.)
> To me a compose sequence seems easier to remember and (much, much)
> easier to implement than a custom input method. What's wrong with typing
> COMPOSE L C in your preferred locale to get access to U+004C LATIN
> There is unfortunately no way to have compose sequences for both COMPOSE L
> *and* COMPOSE L C, or it might have done what you want: but the way X
> compose sequences work is that the instant an appropriate sequence is
> completed, it is emitted to the app without delay, paying no attention
> to the state of the compose key, so you can't have one compose sequence
> be a superset of another like that. I think. But of course a lot of this
> is totally undocumented, so there may well be some mysterious way to use
> the X composition system to do what you want. Again, the place to ask is
> the xorg list.
> (Normally I'd suggest avoiding the combining diacritical marks: to this
> day a lot of applications have awful support for combining characters.
> However, you appear to have no choice in this case: some of the
> characters you want appear only to be available in the combining form.)
> > "if you assign Mode_switch and ISO_Level3_Shift to different keys, you
> can
> > assign up to six characters to one key!"
> > see http://tr.opensuse.org/SDB:Using_the_Extra_Keys_on_the_Keyboard
> > Does this mean it is possible?  Could 7 characters to one ~ey be
> possible?
> Yes, but you have to hit different keys *first* (compose, or
> mode_switch, or both). It's not a matter of 'hit repeatedly'. I think
> only a custom IM could do that. But, in any case, I think a compose
> sequence is likely to be nicer to use anyway.
> > 1. Toggle other ~eyboard mapped layouts for example, languages and
> > diacritics.
> Language toggling is what Mode_switch is for. It lets you flip the
> definitions of potentially *every* key on the keyboard simultaneously
> (actaully, it always does that, but in most keyboard maps many keys are
> bound to the same thing in both modes, especially the non-alphanumeric
> ones.)
> > 2. Access other fonts through toggling (Fonts / Scripts ~ey + another
> ~ey)
> > without needing going every time to the particular application's micro
> > layer.
> That's certainly impossible without per-application assistance. In any
> case, there is no X 'change font' keysym that applications could
> responds to. You could add one, but then you'd have to change all the
> affected applications as well. It's a lot of work.
> > It would be nice to have some person/s on board and get these things
> done.
> The X list is without a doubt the place to go. (Or, at least, one place
> to go. A list dedicated to improving X support for input in Indian
> languages under X/Linux/Unix/... would probably also be useful, but I
> have no idea whether any such lists exist. Probably they do, but I can't
> google for them as I don't speak a single one of the likely-required
> languages, being a typical English pathetic monoglot.)
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20100922/26135ea2/attachment.html>
-------------- next part --------------
Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list