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

Re: Using .XCompose

On Fri, 10 Jul 2020 Ajith R wrote:

Hi,

Thanks for your experiment. The fact that it works atleast in some
applications gives hope.


There remains the strange fact that in no application (yet) have we
seen *both* properties:

 1. application produces multiple characters in accordance with
    XCompose rule that specifies this

 2. application displays the sequence of the three unicode characters
    U+0D19 U+0D4D U+0D19 as the appropriate geminate glyph

I found xterm and mlterm to have property (1), and some graphical
browsers (firefox-esr and qutebrowser) to have property (2). We have
not yet seen anything do both.

(Actually, I have just learned how to make firefox-esr do both. See
GTK_IM_MODULE below.)

Curious parties (like myself) wishing to understand the orthographic
peculiarities at issue here, might find the following section of the
Wikipedia entry on Malayalam script provides brief, helpful
background:

 https://en.wikipedia.org/wiki/Malayalam_script#Ligatures

The "appropriate geminate glyph" refered to in property (2) above is
illustrated in this table, in the "ligated" row under the column
headed "ṅṅa".

 https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures


I copied your exact sentences to my compose file. 

In Konsole the command cat ~/.XCompose gives the result:

include "%L" 
<U0D19>  : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) (U0D19)
<Multi_key> <s> <x> : "✄"  # (U2704) white scissors, h/t David Wright
<Z>                : "ARGA WARGA IN THE DARGA instead of Z"


Do you know what I see in four lines above, representing the content
of your ~/.XCompose file?  I see "non-breaking space" characters
(two-byte sequences 0xc2a0). I see 8 of them in the last line alone
(the <Z> rule). Do you know what non-breaking space characters are?

I'm not quite sure how best to describe them, myself.

But I will tell you what they *aren't*. They aren't spaces. They
aren't tabs. And the only thing their presence is going to do --in
your code and in your configuration files-- is wreak havoc.

Their name is very ironic. For our purposes,

  1. they aren't spaces, and
  2. they break EVERYTHING.

Whatever it is you are doing that puts them there, STOP DOING IT.

You can print all lines of sometextfile which contain them by doing
this:

 $ grep $'\xc2\xa0' sometextfile


Next, I issued setxkbmap -layout us, just to make sure that the layout is us.

I used konsole and UXterm to test Z. The test failed with Z remaining unchanged. 


The non-breaking spaces alone explain this much.


So, as Zeenan says, there is something fundamentally wrong in my
system. I have to find that and correct it or reinstall everything.


Is the situation still as you describe here?

  8 July 2020 Ajith R to debian-user
  [🔎] 620563117.3978825.1594226239402@mail.yahoo.com">https://lists.debian.org/msgid-search/[🔎] 620563117.3978825.1594226239402@mail.yahoo.com

  Now, things are even more strange. When I press the Caps Lock, a
  strange character appears. (I copy pasted it, searched the net and
  found it to be unicode compose character.) Then when I type s, the
  Caps Lock light gets switched on and the character S (caps) appears
  on screen. Then when I type X, the compose character and S become
  invisible and x/X doesn't appear. When I change focus to another
  window, the terminal in which I was typing shows the compose
  character and S.

  This behaviour has not changed after I unchecked the settings
  through KDE settings menu, after restarting computer, re-issuing
  xmodmap command or changing the layout to us. The same sequence is
  seen with typing in Kate as well. Even when I use Scroll Lock as the
  compose key, the situation is only different in that the s is not
  capitalised.

If this is still so, we ought to figure out what's going on. To this
end, I previously asked for the output of

 $ xmodmap

and

 $ xmodmap -pk


I tried in another computer with Debian and KDE. The Z gets replaced
by the first letter in replacement string, while nothing happens in
Xterm.


Try again, for firefox-esr (and with a ~/.XCompose file that is not
befouled with nonbreaking spaces).

But make one change to the procedure. When you launch firefox-esr, do
so like this:

 $ env GTK_IM_MODULE=xim firefox-esr

Let us know how that goes.


Is KDE the problem? I checked IceWM and got the same result.


into what appears (to my utterly ignorant eye) to be a "freshly
synthetic" glyph


That "freshly synthetic" glyph would be the geminate form.


I must say that the more I learn about the project you outlined in
your original post, the more interesting it becomes.

May I ask how you happened to find the post about providing linux
support for the Breton keyboard

  https://dominiko.livejournal.com/20206.html

which you mentioned in this 7 July reply to David Wright?

  [🔎] 563409927.3312315.1594115078623@mail.yahoo.com">https://lists.debian.org/msgid-search/[🔎] 563409927.3312315.1594115078623@mail.yahoo.com

However it is that you came across it, that is a very interesting case
as well.


firefox-esr issued the following errors, which appear to be explanatory:
(firefox-esr:11619): Gtk-WARNING **: 16:27:05.630: GTK+ supports to output one char only:


This means that all softwares that use Gtk will behave similarly?


I would not hastily draw broad conclusions. I don't know about you,
but for my part --conceptually speaking-- I am still stumbling around
in a dark room trying to acquire some semblance of object permanence
without knocking over the coffee table.


 NB: If, like me, you occasionally confuse the Ctrl key with the
compose key, then keep in mind that when testing this rule in a
terminal emulator, that typing Ctrl-s (presumably by accident) may
well stop the terminal from echoing entered characters to the display
until you enter Ctrl-q to resume normal terminal operation. (That is
to say, Ctrl-s doesn't "break your keyboard", it only pauses your
terminal's printout to the display until you resume it with Ctrl-q.)


Thanks for pointing this out. I don't think I have done so because
Konsole flashes the message that I have suspended display when I
press Ctrl S. I would have noticed it.


That is very friendly of konsole to do. I did not know this.


Thanks a lot for your detailed explanations,


Well, they are detailed. As to whether I have managed to explain
anything, I think that is open to interpretation. But it is kind of
you to say.

--
You won't feel the collar if you don't go anywhere.
Reply to: