GNU bug report logs - #4836
"<S-packet> is undefined" when using AutoHotKey

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4836 in the body.
You can then email your comments to 4836 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Linderman <ml <at> g.nevcal.com>
To: bug-gnu-emacs <at> gnu.org
Subject: "<S-packet> is undefined" when using AutoHotKey
Date: Fri, 30 Oct 2009 16:36:55 -0700

emacs 22.1.1 worked fine with autohotkey.  I have macros for correcting 
my common typos, and accelerating commonly entered items, and entering 
characters not found on the keyboard.

Seems none of the autohotkey macros works with emacs 23.1, instead they 
generate an error "<S-packet> is undefined".

Guess I'll have to switch back to emacs 22.1.1, as it worked fine for 
me, until this issue can be resolved.

Message #12 received at 4836-done <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Glenn Linderman <ml <at> g.nevcal.com>, 
 4836-done <at> debbugs.gnu.org
Subject: Re: bug#4836: "<S-packet> is undefined" when using AutoHotKey
Date: Sat, 14 Aug 2010 15:57:58 +0800

 On 31/10/2009 7:36 AM, Glenn Linderman wrote:
> emacs 22.1.1 worked fine with autohotkey.  I have macros for 
> correcting my common typos, and accelerating commonly entered items, 
> and entering characters not found on the keyboard.
>
> Seems none of the autohotkey macros works with emacs 23.1, instead 
> they generate an error "<S-packet> is undefined".

Apparently the "packet" key code is special, so we shouldn't treat it as 
a function key.

I have removed it from the list of function keys that Emacs recognizes, 
so the behaviour should go back to what it was before.  However my 
testing shows that we cannot receive Unicode characters outside the 
current codepage using VK_PACKET as Windows replaces such characters 
with '?' by the time we receive them. It appears that a low level 
keyboard hook may be able to retrieve the original character though, so 
if we receive Lennart's cleaned up keyboard hook patches I'll try to 
look at VK_PACKET support again.

Message #15 received at 4836 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: ml <at> g.nevcal.com, 4814 <at> debbugs.gnu.org, 4836 <at> debbugs.gnu.org
Subject: Re: bug#4814: keyboard and system bug with Emacs CVS current through
	2009-10-15 on w32
Date: Sun, 15 Aug 2010 19:21:58 -0400

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\

Message #18 received at 4836 <at> debbugs.gnu.org (full text, mbox):

From: Evan Driscoll <driscoll <at> cs.wisc.edu>
To: 4814 <at> debbugs.gnu.org, 4836 <at> debbugs.gnu.org
Subject: Further information on the "<packet> undefined" error w/
	keypress-modifying software?
Date: Wed, 25 Aug 2010 12:06:41 -0500

[Message part 1 (text/plain, inline)]

I just ran across a small annoyance today, and in looking for a solution
ran across these two bugs. 4836 sounds like it's very closely related to
what I'm seeing, and there's some discussion about how it relates to
4814, so here goes.


Brief description:
  Using Emacs >=23 with AllChars causes an error message "<packet>
  is undefined" to appear when entering a compose key sequence.


How I did caused the bug to surface:

 - Install AllChars (http://sourceforge.net/projects/allchars/).
   This is a program that gives Windows a compose key feature.
 - Install Emacs >=23.
 - Start AllChars with the default configuration, start Emacs.
 - Try to use a compose-key sequence, e.g. '<compose> / o' or
   '<compose> ` a'. (By default, <compose> is <menu>, but I tried
   another option or two.)


Symptoms:

 - In Emacs 22.3, the composed character (ø or à) shows up as
   expected
 - In Emacs 23.1 and 23.2, as well as CVS Emacs distributed at
   ntemacs.sourceforge.net, an error in the minibuffer is
   displayed: "<packet> is undefined"

Hopefully this'll help.

Evan Driscoll

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.