How to recognize keyboard insertion?

[Eli Zaretskii]

Do we have infrastructure for detecting, inside one of the functions
that insert text into buffers, characters that were inserted via the
keyboard or keyboard macros?

Failing that, can I safely assume that self-insert-command and its
optimized variant in command_loop_1 are the only ways to insert
characters from keyboard and keyboard macros, and that
self-insert-command is only supposed to be invoked by characters typed
at the keyboard?

I'm asking because, in bidirectional editing, characters that are
mirrored at display time need to be mirrored at keyboard input time.
For example, when typing right-to-left text, the character `)' should
be mirrored so that what ends up in the buffer is `(', because what
the user means is to produce an open parenthesis.  (Displaying this
text will then mirror again, and display `)'; this last part already
works in the bidi Emacs I'm working on).

So I need to mirror characters typed at the keyboard, but not
characters yanked from the kill ring or pasted from X selections.  How
can I discern the first kind from the second?

TIA

[David De La Harpe Golden-2]

Eli Zaretskii wrote:


> I'm asking because, in bidirectional editing, characters that are
> mirrored at display time need to be mirrored at keyboard input time.
> For example, when typing right-to-left text, the character `)' should
> be mirrored so that what ends up in the buffer is `(', because what
> the user means is to produce an open parenthesis.  (Displaying this
> text will then mirror again, and display `)'; this last part already
> works in the bidi Emacs I'm working on).
>

Do you?  I'm not really knowledgeable about RtL, but reason I ask is
because when I switch on an arabic OS-level keyboard layout, Shift-9
actually generates a ) parenright keysym and shift-0 a ( parenleft,
which I think is then displayed mirrored as per the last bit of your
post in RtL contexts.

ثثثث(321)ثثث

You can see the transposition in /usr/share/X11/xkb/symbols on
typical gnu+linux distros

So the right place to do such keyboard  mirroring intra-emacs might be
in  quail, i.e. for when people are trying to work RtL only intra-emacs
still with a western os-level keymap.
And indeed, the transposition is shown in the commentary in
emacs/leim/quail/arabic.el  ,
though I think it's missing from the actual map at present
(possibly because emacs lacks RtL until you're done!)

So, since one can assume either the OS keymap or quail will be
pre-mirrroing in practice, you probably don't need to distinguish
keyboard vs. paste here.

N.B. I could be quite wrong here, not expert by any means.

[Eli Zaretskii]

> Date: Sat, 31 Oct 2009 16:58:45 +0000
> From: David De La Harpe Golden <david@...>
> Cc: emacs-devel@...
>
> Do you?  I'm not really knowledgeable about RtL, but reason I ask is
> because when I switch on an arabic OS-level keyboard layout, Shift-9
> actually generates a ) parenright keysym and shift-0 a ( parenleft,
> which I think is then displayed mirrored as per the last bit of your
> post in RtL contexts.

But that is wrong: per the Unicode Bidirectional Algorithm
(a.k.a. UAX#9), a `(' should only be mirrored if its resolved
directionality is R:

 L4. A character is depicted by a mirrored glyph if and only if
    (a) the resolved directionality of that character is R, and
    (b) the Bidi_Mirrored property value of that character is true.

To simplify, this means that a `(' should be mirrored when surrounded
by strong R2L characters, but not when surrounded by Latin characters
or European digits.

What you describe above means that, when typing mixed Arabic and Latin
text, the user needs to switch back from Arabic when she types
mirrored characters, even if these characters are surrounded by
digits, for example.  In Emacs, this means that we would need to
switch away from the input method, even when typing characters whose
keys are not translated by the input method.  That sounds like a
nuisance.

Alternatively, we will need to mirror characters even if their
directionality is L, which is against UAX#9 and will cause incorrect
display in some not-so-rare cases.

For example, try typing "9*(4+5)" after switching to Arabic keyboard.
What do you get?

> So the right place to do such keyboard  mirroring intra-emacs might be
> in  quail, i.e. for when people are trying to work RtL only intra-emacs
> still with a western os-level keymap.

Quail cannot easily know the context: it can only mirror these
characters always, which is not right, since the display will mirror
them only if they are surrounded by strong R2L characters.

[David De La Harpe Golden-2]

Eli Zaretskii wrote:

> To simplify, this means that a `(' should be mirrored when surrounded
> by strong R2L characters, but not when surrounded by Latin characters
> or European digits.
>

It IS only mirrored when surrounded by rtl characters, that was
what I included the nonsense string for.  When not so surrounded,
it, Shift-9 generates ")" /and it is shown as ")"/.   Arabic keyboards
still have ( printed on 9, so I guess they work majority-rtl (which
would make sense).

> Alternatively, we will need to mirror characters even if their
> directionality is L

I don't see why. Other apps don't.

> For example, try typing "9*(4+5)" after switching to Arabic keyboard.
> What do you get?
>


9*)4+5(

surrounded:

ثثث9*)4+5(ثثث
- but that was when I typed the expression as if LtR (i.e. hitting 9
first),  I suspect an arabic person might type

ثثث(5+4)*9ثثث

- i.e. hitting ")" first when transcribing "9*(4+5)".  Then it just
works I think as above (I'm including a screenshot from icedove just in
case)

> Quail cannot easily know the context: it can only mirror these
> characters always, which is not right, since the display will mirror
> them only if they are surrounded by strong R2L characters.
>
>

I expect that's in fact what arabic users expect, though an actual
arabic person might want to speak up...

[David De La Harpe Golden-2]

David De La Harpe Golden wrote:

> ثثث(5+4)*9ثثث
>
> - i.e. hitting ")" first when transcribing "9*(4+5)".

Just in case, there I meant hitting KEY with ")" physically printed on
it, producing  "(" of course, then shown as ")" ...

[Eli Zaretskii]

> Date: Sat, 31 Oct 2009 17:37:07 +0000
> From: David De La Harpe Golden <david@...>
> CC: emacs-devel@...
>
> > To simplify, this means that a `(' should be mirrored when surrounded
> > by strong R2L characters, but not when surrounded by Latin characters
> > or European digits.
> >
>
> It IS only mirrored when surrounded by rtl characters, that was
> what I included the nonsense string for.  When not so surrounded,
> it, Shift-9 generates ")" /and it is shown as ")"/.

My understanding is that Shift-9 generates `(' or `)' depending on
whether the current keyboard is Latin or Arabic, not depending on the
characters surrounding the parenthesis.  All your examples show that
(and I see the same on my Windows box if I switch the keyboard to
Hebrew).  Do you agree?

> > For example, try typing "9*(4+5)" after switching to Arabic keyboard.
> > What do you get?
> >
>
>
> 9*)4+5(

Which is wrong, don't you think?

> surrounded:
>
> ثثث9*)4+5(ثثث
> - but that was when I typed the expression as if LtR (i.e. hitting 9
> first)

This is how digits and other mathematical expressions are typed in
bidirectional text.

> I suspect an arabic person might type
>
> ثثث(5+4)*9ثثث
>
> - i.e. hitting ")" first when transcribing "9*(4+5)".

Maybe if the digits are Arabic digits.  I don't know enough Arabic to
judge this example.  Hebrew uses European digits, and they are typed
left to right, exactly like in Latin scripts.  We could, of course,
tell users to switch off Hebrew input method when typing math, but
that's an annoyance, IMO.

> > Quail cannot easily know the context: it can only mirror these
> > characters always, which is not right, since the display will mirror
> > them only if they are surrounded by strong R2L characters.
>
> I expect that's in fact what arabic users expect, though an actual
> arabic person might want to speak up...

Maybe, I really don't know.

[David De La Harpe Golden-2]

Eli Zaretskii wrote:


> My understanding is that Shift-9 generates `(' or `)' depending on
> whether the current keyboard is Latin or Arabic, not depending on the
> characters surrounding the parenthesis.  All your examples show that
> (and I see the same on my Windows box if I switch the keyboard to
> Hebrew).  Do you agree?


Probably - Shift-9 generates  parenleft (#x28) or parenright (#x29)
depending on current keyboard layout. #x28 is then displayed as ( in ltr
context, or ) in rtl context.


>
>>> For example, try typing "9*(4+5)" after switching to Arabic keyboard.
>>> What do you get?
>>>
>>
>> 9*)4+5(
>
> Which is wrong, don't you think?
>

It's clearly not a valid arithmetical expression... It is however how
mature bidi capable apps I tried behave, for better or worse. I don't
think this is an area where emacs, bidi latecomer, should diverge from
established practice, especially not by default - rtl-native users
presumably by now expect to press the key labelled ")" to get "(" when
using their native keymap but in an ltr context. Maybe they regard that
as an annoyance, I dunno, or maybe it's a semantic-map feature, since
the same shift-0 keypress still makes an opening paren (modern hebrew
text, at least, seems to sometimes use () in text, not just arithmetic
much like english, at least judging by wikipedia hebrew texts).

But therefore it's not necessary to track whether the character was
entered by keyboard unless you want to provide a further unusual "smart"
layer that doesn't work like typical bidi apps.

>> I suspect an arabic person might type
>>
>> ثثث(5+4)*9ثثث
>>
>> - i.e. hitting ")" first when transcribing "9*(4+5)".
>
> Maybe if the digits are Arabic digits.  I don't know enough Arabic to
> judge this example.

Note that western "arabic numerals" vs. eastern arabic numerals is
apparently a matter of font+bidi display (again for better or worse)  -
i.e. if I then copy just the expression above from within the rtl string
and paste it into a ltr context, I get:

(5+4)*9

[Eli Zaretskii]

> Date: Sat, 31 Oct 2009 19:26:02 +0000
> From: David De La Harpe Golden <david@...>
> CC: emacs-devel@...
>
> But therefore it's not necessary to track whether the character was
> entered by keyboard unless you want to provide a further unusual "smart"
> layer that doesn't work like typical bidi apps.

I'm not convinced, sorry.  There are mirrored characters that are not
part of the localized keyboards, at least.  They are also not
supported by most language-oriented input methods.  We still need to
DTRT with them, even if they are inserted as Unicode codepoints or in
some other way.

[David De La Harpe Golden-2]

Eli Zaretskii wrote:

>> Date: Sat, 31 Oct 2009 19:26:02 +0000
>> From: David De La Harpe Golden <david@...>
>> CC: emacs-devel@...
>>
>> But therefore it's not necessary to track whether the character was
>> entered by keyboard unless you want to provide a further unusual "smart"
>> layer that doesn't work like typical bidi apps.
>
> I'm not convinced, sorry.  There are mirrored characters that are not
> part of the localized keyboards, at least.  They are also not
> supported by most language-oriented input methods.  We still need to
> DTRT with them, even if they are inserted as Unicode codepoints or in
> some other way.
>
>

Well, you're writing the code, I'm in a ltr (not counting btt standing
stones) area, I was just pointing out how the existing crop bidi apps do
"handle" (i.e. not do anything clever) the issue.

Maybe one way to handle it would be to make an (emacs level) input
method autoswitcher, that swaps emacs input methods as the rtl/ltr
context switches with point movement.  i.e. allow (but don't require)
rtl and ltr contexts to have different emacs input methods.
Then there could be variant emacs input methods with various
transpositions suitable for use with various os-level keymaps.  And you
don't have to be able to _record_ whether  an inserted character came
from the keyboard.

[Eli Zaretskii]

> Date: Sat, 31 Oct 2009 20:42:48 +0000
> From: David De La Harpe Golden <david@...>
> CC: emacs-devel@...
>
> Maybe one way to handle it would be to make an (emacs level) input
> method autoswitcher, that swaps emacs input methods as the rtl/ltr
> context switches with point movement.  i.e. allow (but don't require)
> rtl and ltr contexts to have different emacs input methods.

We can have input methods switched on and off depending on surrounding
characters, but how will this solve the problem that different methods
of inputting the same character behave differently with mirrored
characters?  A user can conceptually type a character either via an
Emacs input method or via the OS keyboard, in the same place, can't
she?

> Then there could be variant emacs input methods with various
> transpositions suitable for use with various os-level keymaps.

Are you saying that Emacs should have a way of knowing which OS-level
keyboard layout (or keyboard language, in Windows parlance) was used
to insert the character?  If so, how to do that?

Or are you saying that switching on a suitable input method, depending
on surrounding characters, will eliminate the need to know how the
character was inserted?  If so, please explain why you think so,
because I don't follow.

> And you don't have to be able to _record_ whether an inserted
> character came from the keyboard.

I don't need to record that, I just need to know that when the
character is inserted.  After it's inserted, this information is not
needed anymore, because display-time mirroring has enough information
to DTRT.

[David De La Harpe Golden-2]

Eli Zaretskii wrote:


> Are you saying that Emacs should have a way of knowing which OS-level
> keyboard layout (or keyboard language, in Windows parlance) was used
> to insert the character?  If so, how to do that?
>

Not as such (though asking the os what the current keyboard layout is
should be possible on any reasonable os via the platform analog of
XkbGetKeyboard() ?)

- A user with a hebrew os keyboard layout who liked auto-switching could
define that in an ltr context, an emacs input method revpar* should be
switched to. That input method would yield "(" when the os sends ")" to
emacs. A user with a us os keyboard layout who wanted to use the hebrew
emacs input method and also auto-switch could use "hebrew" and
"hebrew-revpar" rtl and ltr input methods.

> Or are you saying that switching on a suitable input method, depending
> on surrounding characters, will eliminate the need to know how the
> character was inserted?  If so, please explain why you think so,
> because I don't follow.

Because it would always insert the appropriate character?



*
(require quail)
(quail-define-package
  "revpar" "revpar" ")(" t
  "transpose inserted parens"
  nil nil nil nil nil nil nil nil nil nil t)
(quail-define-rules
  ("(" ?\))
  (")" ?\())

[Jason Rumney-4]

Eli Zaretskii wrote:
> But that is wrong: per the Unicode Bidirectional Algorithm
> (a.k.a. UAX#9), a `(' should only be mirrored if its resolved
> directionality is R:
>  

I don't think you can do that mirroring on input, as the directionality
will change as the user types (Assume below letters represent an Arabic
or Hebrew character):

User types: ABCD(
Displayed as: )DCBA

User types: ABCD(4
Displayed as: 4)DCBA or (4DCBA? I suspect the first, as the user might
type something other than a number next

User types: ABCD(4+5)
Displayed as: (4+5)DCBA regardless of how directionality of parens is
interpreted.

User types: ABCD(4+5)*9
Displayed as: (4+5)*9DCBA Parens here must be LTR

I guess this is why the mirroring happens at keyboard driver level and
applications do not try to do it correctly, because in practice doing it
correctly results in text jumping around, confusing the user more than
it confuses them to manually fix the problems of a dumb implementation.
And there are always going to be ambiguous cases, where leaving the user
to manually DTRT will be the only option.

[Stephen J. Turnbull]

David De La Harpe Golden writes:
 > Eli Zaretskii wrote:

 > >>> For example, try typing "9*(4+5)" after switching to Arabic keyboard.
 > >>> What do you get?
 > >>
 > >> 9*)4+5(
 > >
 > > Which is wrong, don't you think?
 >
 > It's clearly not a valid arithmetical expression... It is however how
 > mature bidi capable apps I tried behave, for better or worse.

I think you should name the apps, so that people can judge for
themselves whether those are "generally high quality" implementations
if they have experience with them.  I'm only interested in bidi in an
academic sense, but I see an analogy to development of MUA features
for handling mailing list traffic.  Many "mature" MUAs impose
substantial user pain because they don't recognize the RFC 2369
List-Post header as a signal to prefer to reply to list, although that
header was standardized in 1998, and making this the default would
essentially eliminate all demand for Reply-To munging.  (Eg,
Thunderbird 3 finally got this feature in the "Reply" button but it is
still not bound in the key shortcuts.)

It's possible that (like reply to list) the current audience of Emacs
would prefer to learn context-dependent typing idioms for mirrored
characters in bidi rather than be able to use the same "logical"
sequence of keystrokes for "9*(4+5)" regardless of context.  OTOH,
that may be a barrier to reaching a new audience.

An advanced algorithm certainly should be the default in betas.

[Eli Zaretskii]

> Date: Sat, 31 Oct 2009 21:49:20 +0000
> From: David De La Harpe Golden <david@...>
> CC: emacs-devel@...
>
> - A user with a hebrew os keyboard layout who liked auto-switching could
> define that in an ltr context, an emacs input method revpar* should be
> switched to. That input method would yield "(" when the os sends ")" to
> emacs. A user with a us os keyboard layout who wanted to use the hebrew
> emacs input method and also auto-switch could use "hebrew" and
> "hebrew-revpar" rtl and ltr input methods.

OK, but knowing whether to mirror or not requires information about
whether a given keyboard already mirrors characters.  Can this be
found somewhere, or queried at run time?

[Eli Zaretskii]

> Date: Sun, 01 Nov 2009 09:30:35 +0800
> From: Jason Rumney <jasonr@...>
> CC: David De La Harpe Golden <david@...>,
>  emacs-devel@...
>
> User types: ABCD(
> Displayed as: )DCBA

Yes.

> User types: ABCD(4
> Displayed as: 4)DCBA or (4DCBA? I suspect the first, as the user might
> type something other than a number next

The first, yes.

> User types: ABCD(4+5)
> Displayed as: (4+5)DCBA regardless of how directionality of parens is
> interpreted.

Yes.  But I don't understand the ``regardless'' part.  If you want to
know the resolved directionality of each paren, I can tell you what
the current algorithm does (what UAX#9 requires).

> User types: ABCD(4+5)*9
> Displayed as: (4+5)*9DCBA Parens here must be LTR

No, it's displayed as 9*(4+5)DCBA.

> I guess this is why the mirroring happens at keyboard driver level and
> applications do not try to do it correctly, because in practice doing it
> correctly results in text jumping around, confusing the user more than
> it confuses them to manually fix the problems of a dumb implementation.

Sorry, I don't understand: what jumping around are we talking about,
and how is mirroring related to that?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > User types: ABCD(4+5)*9
 > > Displayed as: (4+5)*9DCBA Parens here must be LTR
 >
 > No, it's displayed as 9*(4+5)DCBA.

That seems weird to me.  From my (probably imperfect) understanding of
UAX#9 I would expect the following sequence of displays starting with
an empty buffer (notation: uppercase letters are RTL, lowercase
letters and digits are LTR, -!- is point):

-!-
-!-A
-!-BA
-!-CBA
-!-DCBA
-!-)DCBA
4-!-)DCBA
4+-!-)DCBA
4+5-!-)DCBA      [1]
-!-(4+5)DCBA     <-- point jumps
(4+5)*-!-DCBA    <-- point jumps again
(4+5)*9-!-DCBA

I gather you're saying the correct interpretation of UAX#9 is
(starting from [1]):

4+5-!-)DCBA      [1]
-!-(4+5)DCBA     <-- point jumps
-!-*(4+5)DCBA
9-!-*(4+5)DCBA

[David De La Harpe Golden-2]

Eli Zaretskii wrote:

> OK, but knowing whether to mirror or not requires information about
> whether a given keyboard already mirrors characters.  Can this be
> found somewhere, or queried at run time?

[Only if you want to do it automatically, if it was a user preference
the user would just be setting ltr and rtl current input methods as
desired? Or maybe it would be more intuitive to use just one input
method, e.g. hebrew-parenjuggle, expanding the input method layer to
support rtl/ltr context sensitive definitions for individual rules]

It is possible to find out if the current os keyboard layout is us or
hebrew or whatever which could be coupled with prior information that it
is standard for certain layouts to mirror.  I don't know exhaustively
which ones do, though a lot could probably be extracted by inspection of
the xkb database.

If OTOH you wanted to find out whether the code a keypress returns under
the current os layout actually corresponds to the glyph printed on the
keyboard, you can't really - Only the user knows that at present as
current keyboards don't really inform the computer what glyphs they have
physically printed on them AFAIK (though it would certainly be
technically feasible for a keyboard to e.g. say "Hi, I am physically a
standard british qwerty 105 key keyboard" to a computer with some
well-defined wire protocol, I don't think typical PC ones do).

[Tomas Zerolo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Oct 31, 2009 at 08:15:58PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2009 17:37:07 +0000
> > From: David De La Harpe Golden <david@...>

[...]

> > ثثث9*)4+5(ثثث
> > - but that was when I typed the expression as if LtR (i.e. hitting 9
> > first)
>
> This is how digits and other mathematical expressions are typed in
> bidirectional text.
>
> > I suspect an arabic person might type
> >
> > ثثث(5+4)*9ثثث
> >
> > - i.e. hitting ")" first when transcribing "9*(4+5)".
>
> Maybe if the digits are Arabic digits.  I don't know enough Arabic to
> judge this example [...]

I don't either, but FWIW, i can say that although Arabic uses different
glyphs to represent digits, the write direction for numerals is the same
as in Latin and Hebrew, i.e. most significant digit to the left.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFK7SBMBcgs9XrR2kYRAgNEAJ0dkBlhLxLZ26PoFJ4kMf0Pbg8BFgCfRHFu
iql3sxmw8+BKk/pwOoYk2tg=
=dJQ5
-----END PGP SIGNATURE-----

[David De La Harpe Golden-2]

Stephen J. Turnbull wrote:


> I think you should name the apps, so that people can judge for
> themselves whether those are "generally high quality" implementations
> if they have experience with them.

Actually, I think they just break down to gtk+/pango based, qt based,
and openoffice.  qt and openoffice aren't magically displaying eastern
arabic numerals sometimes like gkt+/pango does, but otherwise seem
similar in my (cursory) tests.

[David De La Harpe Golden-2]

Turning on arabic layout and using keypresses "ABCD(5+4)*96EF" i.e.
pressing a then b then c then d then Shift-0 (so generating code for
"(" not ")", remembering the arabic layout has them reversed) then 5
then + then 4 then Shift-9 (so code ")" not "(") then * then 9 then 6
then e then f. And now using "(" and ")" to indicate  displayed
orientation not underlying code:

-!- is cursor:

icedove / kmail / openoffice all do:

-!-
-!-A
-!-BA
-!-CBA
-!-DCBA
DCBA(-!-
5-!-)DCBA
5)DCBA+-!-
4-!-+5)DCBA
4+5)DCBA)-!-
4+5)DCBA)*-!-
9-!-*(4+5)DCBA
96-!-*(4+5)DCBA
-!-E96*(4+5)DCBA
-!-FE96*(4+5)DCBA