bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

To reproduce this bug, you'll need a keyboard with "dead keys" (like
my spanish keyboard, for example).

Recipe from "emacs -Q":

1. Enable scroll-lock (I can't do this while the Emacs frame has the
focus - I have to select another application before).
2. Try to write an accented "a" ("á") by typing the dead key "´" and
then the key "a".

I observe that:
* What gets inserted is a plain "a" (without the accent).
* The dead key has no effect over the "a" nor the following letters I
type, until I type an <SPC>: at that moment, an "´" is inserted
instead.

The above misbehavior persists even after exiting Emacs and starting
it again (as long as scroll-lock is "on").

This bug has annoyed me for months, but until now I didn't have a
reproducible recipe.


In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-11-05 on MS-W7-DANI
Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src
 -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5
 -I../../libs/giflib-4.1.4-1-lib/include
 -I../../libs/jpeg-6b-4-lib/include
 -I../../libs/tiff-3.8.2-1-lib/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.9-w32-bin/include
 -I../../libs/libiconv-1.9.2-1-lib/include'

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Mon, 5 Nov 2012 20:54:19 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> To reproduce this bug, you'll need a keyboard with "dead keys" (like
> my spanish keyboard, for example).
> 
> Recipe from "emacs -Q":
> 
> 1. Enable scroll-lock (I can't do this while the Emacs frame has the
> focus - I have to select another application before).
> 2. Try to write an accented "a" ("á") by typing the dead key "´" and
> then the key "a".
> 
> I observe that:
> * What gets inserted is a plain "a" (without the accent).
> * The dead key has no effect over the "a" nor the following letters I
> type, until I type an <SPC>: at that moment, an "´" is inserted
> instead.

What's the evidence that this is an Emacs bug, and not something that
keyboard does on Windows?

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> What's the evidence that this is an Emacs bug, and not something that
> keyboard does on Windows?

The evidence is that Emacs is the only windows application that
presents the described misbehavior.

IOW: I always can type accented vowels in all windows applications,
regardless of whether scroll-lock is "on" or not.  The only exception
is Emacs.

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

On Mon, Nov 5, 2012 at 9:48 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>> What's the evidence that this is an Emacs bug, and not something that
>> keyboard does on Windows?
>
> The evidence is that Emacs is the only windows application that
> presents the described misbehavior.
>
> IOW: I always can type accented vowels in all windows applications,
> regardless of whether scroll-lock is "on" or not.  The only exception
> is Emacs.

And BTW: I've reproduced this bug in two different machines: at work
and at home.

Juanma, please, could you say if you can also reproduce this bug.  TIA.

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Juanma Barranquero]

On Mon, Nov 5, 2012 at 9:57 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Juanma, please, could you say if you can also reproduce this bug.  TIA.

Yes, and I agree that it is a bug, though what I see is very slightly
different from what you report, at this point:

> * The dead key has no effect over the "a" nor the following letters I
> type, until I type an <SPC>: at that moment, an "´" is inserted
> instead

If I set scroll-lock and enter Emacs -Q (or Emacs -Q, then switch out
of Emacs, set scroll-lock, switch back to Emacs), when I press ´ I get
nothing until Í press "a" (and get "a", not "á", or for example space,
and then I get ´ alone). Afterwards, pressing ´ inserts it, i.e., it
doesn't work as a dead key, apparently.

    Juanma

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> If I set scroll-lock and enter Emacs -Q (or Emacs -Q, then switch out
> of Emacs, set scroll-lock, switch back to Emacs), when I press ´ I get
> nothing until Í press "a" (and get "a", not "á", or for example space,
> and then I get ´ alone). Afterwards, pressing ´ inserts it, i.e., it
> doesn't work as a dead key, apparently.

I think we see the same behavior: After typing the dead key, only a
space or another dead key makes the "´" to show up.  But if you've
typed a second dead key, it will be "pending" until you type again a
space or a third dead key.

Anyway, it is definitely a bug.  If you need me to provide more data
or make some test, just ask.

Thank you.

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Mon, 5 Nov 2012 21:48:50 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12806@debbugs.gnu.org
> 
> > What's the evidence that this is an Emacs bug, and not something that
> > keyboard does on Windows?
> 
> The evidence is that Emacs is the only windows application that
> presents the described misbehavior.
> 
> IOW: I always can type accented vowels in all windows applications,
> regardless of whether scroll-lock is "on" or not.  The only exception
> is Emacs.

Should be fixed in revision 110822 on the trunk.  Please test, as I
don't have dead keys on my keyboard to test them myself.

(I didn't commit this on the release branch, because this problem
existed since about forever, and so doesn't fit the criteria for
changes on the branch as set by Chong.)

> 1. Enable scroll-lock (I can't do this while the Emacs frame has the
> focus - I have to select another application before).

That you cannot do this in Emacs is by design: when
w32-scroll-lock-modifier is nil, pressing that key when Emacs has
focus is handled as a function key, and Emacs forcibly restores the
previous state of Scroll Lock when you release the key.

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> Should be fixed in revision 110822 on the trunk.  Please test, as I
> don't have dead keys on my keyboard to test them myself.

The behavior I see now is the inverse: when scroll-lock is on, Emacs
does TRT, but when it is off, Emacs fails to manage well the dead key
(like before when scroll-lock was on).


-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Wed, 7 Nov 2012 20:45:50 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12806@debbugs.gnu.org
> 
> > Should be fixed in revision 110822 on the trunk.  Please test, as I
> > don't have dead keys on my keyboard to test them myself.
> 
> The behavior I see now is the inverse: when scroll-lock is on, Emacs
> does TRT, but when it is off, Emacs fails to manage well the dead key
> (like before when scroll-lock was on).

Sorry, you are on your own, then.  The only similar problem I saw
previously on my system is fixed by the changes I committed.  There's
something else going on with dead keys, obviously, but without knowing
what's wrong, I cannot fix that.  Try stepping through the code around
lines 2973 to 3047 of w32fns.c, and see what is going on there when
you type the dead key and the one after it.  If you tell what you see,
maybe I can suggest a solution.

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

>> The behavior I see now is the inverse: when scroll-lock is on, Emacs
>> does TRT, but when it is off, Emacs fails to manage well the dead key
>> (like before when scroll-lock was on).
>
> Sorry, you are on your own, then.  The only similar problem I saw
> previously on my system is fixed by the changes I committed.  There's
> something else going on with dead keys, obviously, but without knowing
> what's wrong, I cannot fix that.  Try stepping through the code around
> lines 2973 to 3047 of w32fns.c, and see what is going on there when
> you type the dead key and the one after it.  If you tell what you see,
> maybe I can suggest a solution.

I'll see what can I do, but FWIW, the situation now is much worse than before:
* Scroll lock is a key that is usually set "off"; that explains why no
one noticed this bug until now.
* What is more important: I've just seen that typing `C-M-u' does
nothing on Emacs.  It is as if no key was pressed at all.  If I do
`C-h c C-M-u' the minibuffer stays as if no key was pressed after `C-h
c'.


FWIW:
* This is with bzr revno 110824.
* Your commit at revno 110822 has a typo: the bug number is "12086",
but you wrote "1280".

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> * What is more important: I've just seen that typing `C-M-u' does
> nothing on Emacs.  It is as if no key was pressed at all.  If I do
> `C-h c C-M-u' the minibuffer stays as if no key was pressed after `C-h
> c'.

I didn't mention that this anomaly happens only when scroll-lock is "on".

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Wed, 7 Nov 2012 21:36:56 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12806@debbugs.gnu.org
> 
> > * What is more important: I've just seen that typing `C-M-u' does
> > nothing on Emacs.  It is as if no key was pressed at all.  If I do
> > `C-h c C-M-u' the minibuffer stays as if no key was pressed after `C-h
> > c'.
> 
> I didn't mention that this anomaly happens only when scroll-lock is "on".

I reverted the previous change and committed a different one, please
see if it solves the problems.

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> I reverted the previous change and committed a different one, please
> see if it solves the problems.

Thanks.  This is what I see now:
* C-M-u works again, regardless of the scroll-lock setting.
* The dead keys don't work (same misbehavior already described), also
regardless of the scroll-lock setting.
* The caps-lock key doesn't work: letters are written in lowercase,
regardless of its setting.


-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Wed, 7 Nov 2012 22:29:55 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12806@debbugs.gnu.org
> 
> > I reverted the previous change and committed a different one, please
> > see if it solves the problems.
> 
> Thanks.  This is what I see now:
> * C-M-u works again, regardless of the scroll-lock setting.
> * The dead keys don't work (same misbehavior already described), also
> regardless of the scroll-lock setting.
> * The caps-lock key doesn't work: letters are written in lowercase,
> regardless of its setting.

The last one works for me just fine.  Are you sure caps-lock does not
work at all, no matter what the state of the various "lock" keys?  If
that only happened when Num Lock was on, then I fixed that in revision
110826.

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Dani Moncayo]

> The last one works for me just fine.  Are you sure caps-lock does not
> work at all, no matter what the state of the various "lock" keys?  If
> that only happened when Num Lock was on, then I fixed that in revision
> 110826.

I didn't try to change num-lock.  So, with revno 110825 the caps-lock
key works only when num-lock is off, because if I set num-lock on, all
letters are written in lowercase as I said.

Now, with revno 110826 everything seem to work correctly, even the
original problem of this bug report.

So I think you can close this bug report.

Thank you so much!

-- 
Dani Moncayo

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Eli Zaretskii]

> Date: Wed, 7 Nov 2012 23:12:27 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12806@debbugs.gnu.org
> 
> > The last one works for me just fine.  Are you sure caps-lock does not
> > work at all, no matter what the state of the various "lock" keys?  If
> > that only happened when Num Lock was on, then I fixed that in revision
> > 110826.
> 
> I didn't try to change num-lock.  So, with revno 110825 the caps-lock
> key works only when num-lock is off, because if I set num-lock on, all
> letters are written in lowercase as I said.
> 
> Now, with revno 110826 everything seem to work correctly, even the
> original problem of this bug report.
> 
> So I think you can close this bug report.
> 
> Thank you so much!

Great, closing.

bug#12806: 24.3.50; Dead keys misbehavior when scroll-lock is enabled

[Juanma Barranquero]

On Mon, Nov 5, 2012 at 8:54 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> 1. Enable scroll-lock (I can't do this while the Emacs frame has the
> focus - I have to select another application before).

BTW, this is because w32-scroll-lock-modifier defaults to nil, which
means that the scroll-lock key is not a modifier (hyper, meta, etc.)
and it's passed to Emacs (you could assign an interactive function to
<scroll>). If you set w32-scroll-lock-modifier to t it will be passed
to Windows and it will work as expected.

> I observe that:
> * What gets inserted is a plain "a" (without the accent).
> * The dead key has no effect over the "a" nor the following letters I
> type, until I type an <SPC>: at that moment, an "´" is inserted
> instead.

And BTW(2), this does not happen in emacs -Q -nw.

    Juanma