keymap display inconsistency in help

keymap display inconsistency in help

[Stephen Berman]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-19 on steve
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If a major mode keymap is defined using (make-keymap), then in both
the mode description and the function description of the mode the key
bindings are displayed in ASCII order; but if the keymap is defined
using (make-sparse-keymap), then the key bindings are displayed in
reverse ASCII order.


Recent input:
M-x l o a <tab> f <tab> <return> s <tab> <return> M-x 
s r <tab> b <tab> <return> C-h m C-x o C-x 1 C-x k 
<return> M-x s r b <tab> b <tab> <return> C-h f M-x 
<up> C-g C-h f <up> s r <tab> b <tab> b <tab> <return> 
C-g C-h f <up> <return> C-x o C-x 1 <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
Loading view...done
Type C-x 1 to remove help window.  C-M-v to scroll the help.
call-interactively: Quit
next-history-element: Beginning of history; no preceding item
Making completion list...
Loading /usr/local/libexec/emacs/21.2/i686-pc-linux-gnu/fns-21.2.1.el (source)...done
Type C-x 1 to remove help window.  C-M-v to scroll the help.
setq: Quit
Type C-x 1 to remove help window.  C-M-v to scroll the help.
Loading emacsbug...done

Re: keymap display inconsistency in help

[Richard Stallman]

    If a major mode keymap is defined using (make-keymap), then in both
    the mode description and the function description of the mode the key
    bindings are displayed in ASCII order; but if the keymap is defined
    using (make-sparse-keymap), then the key bindings are displayed in
    reverse ASCII order.

Would you please send precise test cases?
You say "are displayed", but that is not clear:
displayed by what?  With precise test cases,
I would know the answer.

Re: keymap display inconsistency in help

[Kevin Rodgers]

rms@gnu.org (Richard Stallman) writes:
>     If a major mode keymap is defined using (make-keymap), then in both
>     the mode description and the function description of the mode the key
>     bindings are displayed in ASCII order; but if the keymap is defined
>     using (make-sparse-keymap), then the key bindings are displayed in
>     reverse ASCII order.
> 
> Would you please send precise test cases?
> You say "are displayed", but that is not clear:
> displayed by what?  With precise test cases,
> I would know the answer.

I think this is the same complaint discussed in the second part of
this article:

From: kevinr@ihs.com (Kevin Rodgers)
Subject: Re: C-x r refers to both rectangle and register...
Date: Thu, 07 Mar 2002 17:03:32 -0700
Message-ID: <3C87FFD4.97202D56@ihs.com>
References: <m2it8kvtpb.fsf@dan.jacobson.tw>
Newsgroups: gnu.emacs.bug

-- 
Kevin Rodgers <kevinr@ihs.com>

Re: keymap display inconsistency in help

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

Kevin Rodgers <kevinr@ihs.com> writes:

> rms@gnu.org (Richard Stallman) writes:
[I <steve@ims.uni-stuttgart.de> had written:]
> >     If a major mode keymap is defined using (make-keymap), then in both
> >     the mode description and the function description of the mode the key
> >     bindings are displayed in ASCII order; but if the keymap is defined
> >     using (make-sparse-keymap), then the key bindings are displayed in
> >     reverse ASCII order.
> > 
> > Would you please send precise test cases?
> > You say "are displayed", but that is not clear:
> > displayed by what?  With precise test cases,
> > I would know the answer.

Whoops, my report was sent by mistake (I composed it offline and
pressed C-c C-c thinking that would send it to my Gnus queue for later
editing, but I didn't realize that M-x report-emacs-bug doesn't
interact with Gnus by default.  I assume it went into my sendmail
queue and was sent without my knowledge the next time I logged on.)
In fact I prepared a test case, which I append below.

> I think this is the same complaint discussed in the second part of
> this article:
> 
> From: kevinr@ihs.com (Kevin Rodgers)
> Subject: Re: C-x r refers to both rectangle and register...
> Date: Thu, 07 Mar 2002 17:03:32 -0700
> Message-ID: <3C87FFD4.97202D56@ihs.com>
> References: <m2it8kvtpb.fsf@dan.jacobson.tw>
> Newsgroups: gnu.emacs.bug

Hm, there you wrote:

> > I do C-x C-h and things are out of order, no matter what my LC_* env
> > variables are,
> [...]
> Because ctl-x-4-prefix is a sparse keymap, ordered from newest to oldest
> bindings.

I assume by "newest to oldest" you mean the same thing Stefan Monnier
wrote in the current thread:

> With a sparse keymap the order is determined by the order in which
> the bindings were added to the table.

But this is not the behavior I observed, as the appended test case
demonstrates -- that is, unless the bindings are added to the table in
reverse ASCII order, and not in the order they are defined in by the
mode-map defvar.  BTW, this also happens in Emacs 20.7.

--Steve Berman


[-- Attachment #2: test case for key bindings display --]
[-- Type: application/octet-stream, Size: 1584 bytes --]

Too see an example, start Emacs with -q --no-site-file and eval the
following four expressions:

(defun srb-test1-mode ()
  "Major mode to test display of key bindings.
\\{srb-test1-mode-map}"
  (use-local-map srb-test1-mode-map))

(defvar srb-test1-mode-map
  (let ((map (make-keymap)))
    (define-key map "a" 'srb-test-1)
    (define-key map "B" 'srb-test-2)
    (define-key map "C" 'srb-test-3)
    (define-key map "d" 'srb-test-4)
    map))

(defun srb-test2-mode ()
  "Major mode to test display of key bindings.
\\{srb-test2-mode-map}"
  (use-local-map srb-test2-mode-map))

(defvar srb-test2-mode-map
  (let ((map (make-sparse-keymap)))
    (define-key map "a" 'srb-test-1)
    (define-key map "B" 'srb-test-2)
    (define-key map "C" 'srb-test-3)
    (define-key map "d" 'srb-test-4)
    map))


Typing `M-h f srb-test1-mode' brings up this *Help* buffer:
___________________________________________________________
srb-test1-mode is a Lisp function.
(srb-test-mode)

Major mode to test display of key bindings.

key             binding
---             -------

B		srb-test-2
C		srb-test-3
a		srb-test-1
d		srb-test-4
___________________________________________________________


Typing `M-h f srb-test2-mode' brings up this *Help* buffer:
___________________________________________________________
srb-test2-mode is an interactive Lisp function.
(srb-test-mode)

Major mode to test display of key bindings.

key             binding
---             -------

d		srb-test-4
a		srb-test-1
C		srb-test-3
B		srb-test-2
___________________________________________________________

Re: keymap display inconsistency in help

[Richard Stallman]

    Typing `M-h f srb-test2-mode' brings up this *Help* buffer:
    ___________________________________________________________
    srb-test2-mode is an interactive Lisp function.
    (srb-test-mode)

    Major mode to test display of key bindings.

    key             binding
    ---             -------

    d		srb-test-4
    a		srb-test-1
    C		srb-test-3
    B		srb-test-2

What I get with the latest development version is

    d		srb-test-4
    C		srb-test-3
    B		srb-test-2
    a		srb-test-1

which is the reverse of the order they were added.

Maybe the CVS version differs from 21.2 in this behavior.

Re: keymap display inconsistency in help

[Stephen Berman]

[I provided test cases showing that with make-keymap, the *Help*
buffer displays the key bindings is ASCII order, while with
make-sparse-keymap, the *Help* display is in reverse ASCII order:]

>     Typing `M-h f srb-test2-mode' brings up this *Help* buffer:
>     ___________________________________________________________
>     srb-test2-mode is an interactive Lisp function.
>     (srb-test-mode)
> 
>     Major mode to test display of key bindings.
> 
>     key             binding
>     ---             -------
> 
>     d		srb-test-4
>     a		srb-test-1
>     C		srb-test-3
>     B		srb-test-2

Richard Stallman <rms@gnu.org> writes:
> 
> What I get with the latest development version is
> 
>     d		srb-test-4
>     C		srb-test-3
>     B		srb-test-2
>     a		srb-test-1
> 
> which is the reverse of the order they were added.
> 
> Maybe the CVS version differs from 21.2 in this behavior.

I just ran my make-sparse-keymap test case again, and to my
embarrassment and perplexity, I now get this too, and not reverse
ASCII order.  Sorry for the false report.  I don't know what I did
before to get reverse ASCII order, but it was definitely there,
because I pasted it from the *Help* buffer.  I still reproducibly get
ASCII order (not input order) for the make-keymap test case.  So the
display inconsistency remains.  I'm curious why make-keymap and
make-sparse-keymap differ in this respect (as well as others, as I've
recently learned).  Are there efficiency or other reasons?  (I tried
looking at keymap.c but I'm not fluent enough in the Emacs source code
to see what's going on on my own.)

--Steve Berman

Re: keymap display inconsistency in help

[Miles Bader]

steve@ims.uni-stuttgart.de (Stephen Berman) writes:
> I'm curious why make-keymap and make-sparse-keymap differ in this
> respect (as well as others, as I've recently learned).  Are there
> efficiency or other reasons?

It's just that they use different data structures -- sparse keymaps are
lists, and bindings are added by just pushing them on the front, whereas
keymaps are vectors, and bindings are added in the appropriate place
(indexed by the key).

I suppose it would be simple enough to sort sparse keymaps before
displaying them, to have the same order as a normal keymap.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: keymap display inconsistency in help

[Richard Stallman]

    I suppose it would be simple enough to sort sparse keymaps before
    displaying them, to have the same order as a normal keymap.

In the past, this was the sort of thing I deliberately didn't do,
to keep Emacs small.  However, nowadays the extra code for this
is not a problem.

Re: keymap display inconsistency in help

[Stefan Monnier]

>>>>> "Stephen" == Stephen Berman <steve@steve.ims.uni-stuttgart.de> writes:
> using (make-sparse-keymap), then the key bindings are displayed in
> reverse ASCII order.

No.  With a sparse keymap the order is determined by the order in which
the bindings were added to the table.


        Stefan