bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap

[Lars Ingebrigtsen]

This is more mysterious than I thought.  describe_map is responsible for
outputting each map, and I've been staring at it for minutes without
seeing anything odd.

But let's look at the output again:

(substitute-command-keys "\\{dired-mode-map}")
  "key             binding
---             -------

e .. f          dired-find-file

C-c             Prefix Command
RET             dired-find-file
C-o             dired-display-file
[...]
0 .. 9          digit-argument
[...]
c               dired-do-compress-to
d               dired-flag-file-deletion
g               revert-buffer
[...]
S-SPC           dired-previous-line
<follow-link>   mouse-face
<mouse-2>       dired-mouse-find-file-other-window
<remap>         Prefix Command

C-c d           lars-copy-directory

C-t C-t         image-dired-dired-toggle-marked-thumbs
C-t .           image-dired-display-thumb
C-t a           image-dired-display-thumbs-append
C-t c           image-dired-dired-comment-files
C-t d           image-dired-display-thumbs
C-t e           image-dired-dired-edit-comment-and-tags
C-t f           image-dired-mark-tagged-files
C-t i           image-dired-dired-display-image
C-t j           image-dired-jump-thumbnail-buffer

and so on.  The think to observe is that there's an extra newline
after the first "e .. f" line.  This means that it's being output as its
own keymap, I think.  describe_map does not add any extra empty blank
lines, and it sorts ranges just fine, as we can see from the "0 .. 9"
line.

So something is deciding that "e" and "f" come from a separate keymap,
and calling describe_map on that.  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no