bug#4836: bug#4814: keyboard and system bug with Emacs CVS current through 2009-10-15 on w32

[MON KEY]

Hi Jason,

> but could this be related to bug#4836?

The short answer is:

Feel free to close bug#8814 and/or fold it in with bug#4836 if this is
what is needed to continue the ongoing development progress of Emacs.

The long answer is:

I'm not sure if the two are related, though it did occur to me when I
read the bug#4836 report (filed on Fri, 30 Oct 2009 three days
subsequent to the Oct 27, 2009 filing of bug#4814) that the two _may
be_ related.  FWIW I had assumed that they were and would eventually
be folded together.

This said, unfortunately (and largely due to bug#4814/4836), I am no
longer using Emacs on w32 systems (or w32 systems in general)... the
nature of the problem posed such serious functionality issues w/
integration of Emacs on my w32's as to render the combination
useless. As such, I am not able (nor am I now willing) to re-examine
the issue.

If the problem is now fixed this is good to hear, if not, you will
have to find other users better able to clearly describe the impact
and nature of the problems made manifest by these bugs esp. given the
following:

> You don't explain the problem you are seeing clearly,

Jason, no offense, but this is BS (and a cop out) and I take some
degree of displeasure in pointing out that;

 - Your recent follow up to bug#4814 was not cc'd to me;

 - The bug report in question is now nearly 10 months old;

 - The nature of the bug wasn't/isn't a clearly describable problem.

 - The affected builds in question are now 13, 14, and 8 months old
   respectively;

 - As noted above I am not now willing/able to further troubleshoot
   the problem

This said, I _did_ make multiple follow up reports over an extended
period w/re the bug and have not until now received any further requests
for additional information.

Likewise, I tested multiple different builds (at least five over an
eight month period) and made a cumulative report on my findings in an
attempt to lend some clarity to the problem.

Moreover, I did my best to indicate (and document) specifically that
the problem did appear (at least to me) to involve:

- 0x2ed76000 control key events;

- changes in `local-function-key-map', submaps, and associated
  event-modifiers;

- curious differences between the composition and and length of
  `input-decode-map';

Specifically my comparison/contrasting of this build known (by me) to
pose the problem:

,----
|
| - "GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600)
|   of 2010-01-02 on PRETEST" <- FAILED
|
`----

 with these two builds known to work as expected:

,----
|
|  - "Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
|     of 2009-06-30 on LENNART-69DE564 (patched)"
|
|  - "Emacs 23.1.1 of 2009-07-30 on SOFT-MJASON"
|
`----

This included my indication that:

,----
|
| "The value 0x2ed76000 appears in my dribble-file and recent-keys
| output for all ``control'' key presses."
|
`----

My indication that at some point a change occurred such that;

,----
|
| "The value of the map: (0 . [67108896]) in `local-function-key-map'
| does not seem to have been present until after 07-2009."
|
`----

and that this change may have impacted/affected the return values for
`input-decode-map' from the Emacs builds (patched and unpatched) of
circa June/July 2009 e.g. these two builds:

,----
|
| "GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
|  of 2009-07-30 on SOFT-MJASON"
|
| "In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
|  of 2009-06-30 on LENNART-69DE564 (patched)"
|
`----


which each returned as follows for `input-decode-map':

,----
|
| input-decode-map
|  => (keymap)
|
`----

whereas the 2010-01-02 build e.g.:

,----
| "GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600)
|  of 2010-01-02 on PRETEST"
`----

had this return value for `input-decode-map':

,----
|
| input-decode-map
| => (keymap (27 keymap (C-backspace) (C-delete))
|    (C-M-backspace) (C-M-delete) (M-backspace) (M-delete))
|
`----

My indication that the significant differences in the size of the
`key-translation-map' from the non-functioning version of 2010-01-02
which had a length of 2 as compared with the functioning version of
Summer-2009 which were considerably lager.

My indication of the significant differences in both the size and
structure of the sublists of `local-function-key-map'. With the
non-functioning version of 2010-01-22 having a length of 66 and the
functioning versions of Summer-2009 having a length of 60. And with
the non-functioning version.

My provision for the implicitly indicative (though apparently
non-obvious) fact, that the size/structure differences of
`local-function-key-map' happened to map suspiciously to the
differences in length for `input-decode-map'. E.g. that the
non-functioning version of 2010-01-02 (which had an `input-decode-map'
length of 6) as compared with the functioning versions of Summer-2009
which had an `input-decode-map' containing the single element:
(keymap).

--
/s_P\