Bug with S-Tab in keymaps

Bug with S-Tab in keymaps

[Alan Mackenzie]

Hi, Emacs!

I'm Running Emacs 22.2 in a Linux tty.

I've been having severe trouble with the binding S-Tab, as required by
Drew's Icicles.

When I type <shift>-<tab>, what comes out of my function-key-map is
#x2000009, that is \C-i together with the b25.

By contrast, the pertinent entry in icicle-mode-map is
(S-tab . icicle-generic-S-tab).

(lookup-key icicle-mode-map [#x2000009]) fails to find the binding for
S-Tab.

Should S-Tab be stored in a keymap as a symbol or a number?  Or are both
valid?  Which is the canonical form?  Where should the conversion from
the uncanonical form to the canonical be done?

I think this should be fixed before the next release.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug with S-Tab in keymaps

[Stefan Monnier]

> Should S-Tab be stored in a keymap as a symbol or a number?  Or are both
> valid?  Which is the canonical form?  Where should the conversion from
> the uncanonical form to the canonical be done?

IIUC the canonical name of shift-tab in Emacs is `backtab'.
The conversion from various other terminal-specific representations
should be done in function-key-map.  If it's not done there, please
report it as a bug.


        Stefan

RE: Bug with S-Tab in keymaps

[Drew Adams]

> > Should S-Tab be stored in a keymap as a symbol or a number? 
> > Or are both valid?  Which is the canonical form?  Where
> > should the conversion from the uncanonical form to the
> > canonical be done?
> 
> IIUC the canonical name of shift-tab in Emacs is `backtab'.
> The conversion from various other terminal-specific representations
> should be done in function-key-map.  If it's not done there, please
> report it as a bug.

Thanks, I didn't know that. Icicles was binding it by default to both `S-tab'
and `S-iso-lefttab', but I've now changed that to `backtab'.

I agree with Alan that the canonical form should be documented in the manual.
And just what is meant by "canonical form" should be explained there as well.

Re: Bug with S-Tab in keymaps

[Stefan Monnier]

> Thanks, I didn't know that. Icicles was binding it by default to both `S-tab'
> and `S-iso-lefttab', but I've now changed that to `backtab'.

> I agree with Alan that the canonical form should be documented in the manual.
> And just what is meant by "canonical form" should be explained there as well.

Yes, that does sound sensible.  There aren't many such "canonical
keys".  I can think of ?\t, ?\r, ?\^?, and `backtab'.  Any other?
Maybe `mwheel-up' and `mwheel-down', except that these are currently not
canonicalized correctly under X11.


        Stefan

Re: Bug with S-Tab in keymaps

[Alan Mackenzie]

Hi, Stefan!

On Mon, May 05, 2008 at 02:07:53PM -0400, Stefan Monnier wrote:
> > Should S-Tab be stored in a keymap as a symbol or a number?  Or are both
> > valid?  Which is the canonical form?  Where should the conversion from
> > the uncanonical form to the canonical be done?

> IIUC the canonical name of shift-tab in Emacs is `backtab'.
> The conversion from various other terminal-specific representations
> should be done in function-key-map.  If it's not done there, please
> report it as a bug.

That's what I thought I was doing.  I think the bug is that a symbol,
here 'S-tab, is being used when there's a perfectly good ASCII char +
bucky bit available.

I also think the canonical form of a key sequence should be defined in
the Elisp manual.  (Yes, I know, I'm implicitly volunteering to do
this.)

Icicles actually uses the symbol 'S-tab.  So, potentially, does a fair
bit of other software.

My own opinion, for what it's worth, is that read_key_sequence (in
keyboard.c) and lookup-key (in keymap.c) should both massage the
differences between #x2000009 and 'S-tab and 'S-TAB, somehow.  I suppose
even #x4000049 (&I + the control bucky bit) for the same thing is
conceivable.  Maybe `define-key' should canonicalise the key-sequences
it's given before writing them into a keymap.

In fact, `canonicalise-key-sequence' would be easy to write in Lisp, and
could be called from all of read_key_sequence, lookup-key and
define-key.  What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug with S-Tab in keymaps

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> I also think the canonical form of a key sequence should be defined in
> the Elisp manual.  (Yes, I know, I'm implicitly volunteering to do
> this.)

There is a little bit here:

   (info "(emacs) Function Keys")

RE: Bug with S-Tab in keymaps

[Drew Adams]

> > I also think the canonical form of a key sequence should be 
> > defined in the Elisp manual.  (Yes, I know, I'm implicitly
> > volunteering to do this.)
> 
> There is a little bit here:
>    (info "(emacs) Function Keys")

I really don't see how that helps. (And it is not in the Elisp manual.)

What's needed is to know which keys (e.g. `S-tab', `S-isoleft-tab') are
represented canonically by which keys (e.g. `backtab').

Re: Bug with S-Tab in keymaps

[Alan Mackenzie]

Hi, Stefan and Drew!

On Mon, May 05, 2008 at 08:54:11PM +0000, Alan Mackenzie wrote:
> Hi, Stefan!

> On Mon, May 05, 2008 at 02:07:53PM -0400, Stefan Monnier wrote:
> > > Should S-Tab be stored in a keymap as a symbol or a number?  Or are
> > > both valid?  Which is the canonical form?  Where should the
> > > conversion from the uncanonical form to the canonical be done?

[ .... ]

> My own opinion, for what it's worth, is that read_key_sequence (in
> keyboard.c) and lookup-key (in keymap.c) should both massage the
> differences between #x2000009 and 'S-tab and 'S-TAB, somehow.  I suppose
> even #x4000049 (&I + the control bucky bit) for the same thing is
> conceivable.  Maybe `define-key' should canonicalise the key-sequences
> it's given before writing them into a keymap.

> in fact, `canonicalise-key-sequence' would be easy to write in lisp, and
> could be called from all of read_key_sequence, lookup-key and
> define-key.  what do you think?

here's an embryonic `canonicalize-event' (note the American spelling ;-).
It works, e.g. for

(canonicalize-event 'TaB)
(canonicalize-event 'C-Tab)
(canonicalize-event 'C-PgUp)
(canonicalize-event #x4000049)
(canonicalize-event 'M-C-prior)

.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defconst non-canon-key-symbs
  '((tab . 9)
    (bs . 127)
    (pgup . "prior"))
  "An alist mapping non-standard keynames to canonical ones")

(defun canonicalize-event (evt)
  "Turn the event EVT into its canonical equivalent.

EVT is typically a single key press after being massaged by the
function-key-map, or a mouse action.

In the following, the \"base-key\" means the key event without
its modifiers.  If EVT is an integer, the base-key is its bottom
8 bits; if EVT's a symbol, the base-key is the symbol name
without the modifiers, a string.

The rules for a key event's canonicity are, in order of
decreasing priority:

\(i) it is a number (character, perhaps including bucky bits) if possible.
\(ii) if it contains control and a low ASCII character (?@, ?a, ...., ?z, ?{,
  ..., ~, del), the base key is the corresponding control character.
\(iii) Upper and lower case letters will be represented as such in the base
  key, rather than by use of the shift bucky bit.

\(iv) if it can't be represented by a number, it is a symbol containing the
  modifiers, e.g. 'C-M-up.
\(v) Any attached modifiers are case significant, and appear in the canonical
  order, A-C-H-M-S-s-.
\(vi) The base key part of the symbol name is in lower case, and is the
  canonical name."
  (let ((M-bit #x8000000)
	(C-bit #x4000000)
	(S-bit #x2000000)		; shift
	(H-bit #x1000000)
	(s-bit #x800000)		; super
	(A-bit #x400000)
	(base-mask #x3fffff)
	base-key			; key without modifiers; number or string.
	got-M got-C got-S got-H got-s got-A ; are explicit modifiers present?
	is-C is-upper-case		    ; is it a control/upper-case key?
	is-CC			      ; is it a "double" ctrl key, e.g. C-TAB?
	(char-mod-alist
	 '((?M . got-M) (?C . got-C) (?S . got-S)
	   (?H . got-H) (?s . got-s) (?A . got-A)))
	key-string canon-symb ch pos
	)
;;;; Analyse the argument
    (cond
     ((numberp evt)
      (setq base-key (logand evt base-mask) ; Unchanged until the "Synthesize" bit.
	    got-M (/= 0 (logand evt M-bit))
	    got-C (/= 0 (logand evt C-bit))
	    got-S (/= 0 (logand evt S-bit))
	    got-H (/= 0 (logand evt H-bit))
	    got-s (/= 0 (logand evt s-bit))
	    got-A (/= 0 (logand evt A-bit)))

      ;; Have we got a "double <ctrl>", e.g. C-TAB?
      (setq is-CC (and got-C (< base-key 32))))

     ((symbolp evt)
      (setq key-string (symbol-name evt))
      ;; get the modifiers.
      (setq pos 0)
      (while (eq (string-match "[MCSHsA]-." key-string pos) pos)
	(setq ch (aref key-string pos))
	(set (cdr (assq ch char-mod-alist)) t)
	(setq pos (+ 2 pos)))
      ;; get the base "key" (might be a mouse event).
      (or (string-match "[^-]+$" key-string pos)
	  (error "canonicalize-event: invalid symbol: %s" evt))
      (setq base-key (substring key-string pos)))

     (t (error "canonicalize-event: argument not number or symbol: %s" evt)))

;;;; Synthesize the result
    (when (stringp base-key)
      (if (eq (length base-key) 1)		; must be a letter or digit.
	  (setq base-key (aref base-key 0))
	(setq base-key (downcase base-key))
	(if (setq canon-symb (assoc (intern base-key) non-canon-key-symbs))
	    (setq base-key (cdr canon-symb))))) ; symbol or number
	
    ;; Can we transform base-key into an ASCII control sequnce (0 - 31)?
    (when (and got-C (numberp base-key))
      (cond
       ;; Convert got-C with (e.g.) ?A -> shift + ?\C-a
       ((and (>= base-key ?A) (<= base-key ?Z))
	(setq base-key (- base-key ?A -1)
	      got-C nil
	      got-S t))
       ;; got-C with (e.g.) ?@ -> ?\C-@
       ((or (eq base-key ?@)
	    (and (>= base-key ?\[) (<= base-key ?_)))
	(setq base-key (- base-key ?@)
	      got-C nil))
       ;; got-C with (e.g.) ?a -> ?\C-a
       ((and (>= base-key ?a) (<= base-key ?z))
	(setq base-key (- base-key ?a -1)
	      got-C nil))))

    (if (numberp base-key)
	(logior
	 base-key
	 (if got-M M-bit 0)
	 (if (or got-C is-CC) C-bit 0)
	 (if got-S S-bit 0)
	 (if got-H H-bit 0)
	 (if got-M M-bit 0)
	 (if got-M M-bit 0))
      (intern
       (concat
       (if got-A "A-" "")
       (if got-C "C-" "")
       (if got-H "H-" "")
       (if got-M "M-" "")
       (if got-S "S-" "")
       (if got-s "s-" "")
       base-key)))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug with S-Tab in keymaps

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> here's an embryonic `canonicalize-event' (note the American spelling ;-).
> It works, e.g. for

Why all the mucking about with symbols?!  [E.g. 'C-M-u ]

Why not use a representation that actually works with emacs like
'(control meta u)?

Thanks,

-Miles

-- 
Insurrection, n. An unsuccessful revolution.

Re: Bug with S-Tab in keymaps

[Alan Mackenzie]

'Morning, Miles!

On Wed, May 07, 2008 at 08:13:09AM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > here's an embryonic `canonicalize-event' (note the American spelling
> > ;-).  It works, e.g. for

> Why all the mucking about with symbols?!  [E.g. 'C-M-u ]

My main point is that there should BE a standard way of representing key
sequences.  At the moment there is not.  So that if I type <shift>-<tab>
on my keyboard, function-key-map turns this into #x2000009.  `lookup-key'
then fails to find the binding on the symbol 'S-tab in a keymap.  This is
a bug.

Whether the standard I tentatively proposed is the right one or not can
be debated.  I'd appreciate people agreeing with me that a standard is
wanted.

> Why not use a representation that actually works with emacs like
> '(control meta u)?

What do you mean?  Symbols actually work with Emacs very well.

For the specific instance you give, I actually proposed a number:
#x8000015 = ?\C-u + the meta bit.

But I still think 'C-M-up is superior to '(control meta up).  It takes
less space, and (eq sym 'C-M-up) is faster than (equal sym '(control meta
up)).  Also, events are represented as symbols at the moment, so why
change this to a list?

Of course, if the speed of looking up keys were a problem (it's not) we
could use an obarray.

The mucking about with symbols in my `canonicalize-event' only needs to
be twice per event per key lookup (and when the binding is made, of
course).  

> Thanks,

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Bug with S-Tab in keymaps

[Stefan Monnier]

>> > here's an embryonic `canonicalize-event' (note the American spelling
>> > ;-).  It works, e.g. for
>> Why all the mucking about with symbols?!  [E.g. 'C-M-u ]
> My main point is that there should BE a standard way of representing key
> sequences.

There is, actually, but it's only partly formalized.
See `reorder_modifiers' in src/keyboard.c for example.

> At the moment there is not.  So that if I type <shift>-<tab>
> on my keyboard, function-key-map turns this into #x2000009.

Sounds like a bug: as mentioned, shift-tab should be mapped by
function-key-map to `backtab'.

> Whether the standard I tentatively proposed is the right one or not can
> be debated.  I'd appreciate people agreeing with me that a standard is
> wanted.

No argument here.


        Stefan

RE: Bug with S-Tab in keymaps

[Drew Adams]

Hi Alan,

Any luck with your S-TAB binding?

BTW, I just noticed this:

> I've been having severe trouble with the binding S-Tab, as required by
> Drew's Icicles.

Actually, Icicles doesn't require that you use S-TAB. You can use any key (or
keys) in option `icicle-generic-S-tab-keys'.

But I think you mean that you want to use your keyboard's Shift+TAB but the code
that that sends is not picked up well by Emacs/Icicles.

Just wanted to make sure you understand that you could use any key for this; you
are not limited to S-TAB.

Regards,

  Drew