all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
@ 2012-04-24 15:11 Drew Adams
  2012-09-17  0:02 ` Drew Adams
  2014-02-10  4:59 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 11+ messages in thread
From: Drew Adams @ 2012-04-24 15:11 UTC (permalink / raw)
  To: 11325

eamcs -Q
 
1. Visit a Dired buffer, then switch back to *scratch*.
 
2. Type this: (substitute-command-keys "\\{dired-mode-map}")

3. Then hit C-j.
 
Look at where you find these entries: `e..f' and `0..9'.
They are out of order.
 
The order provided in all Emacs versions prior to Emacs 23 is
reasonable and user-friendly.  It puts `e..f' among the
lowercase letter, in alphabetical order, i.e., between `d' and
`g'.  It puts `0..9' between `.' and `<', i.e., in ASCII order
(`:' is not bound in Emacs prior to Emacs 23).
 
This was broken first in Emacs 23, which puts `0..9' and `e..f'
first in the list, in that order.
 
Then it was broken differently in Emacs 24, which puts `e..f'
first in the list, but restores `0..9' to its rightful place.
 
Users should be able to find chars/keys in ASCII order.  This is
particularly important for letters.
 

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-04-23 on MARVIN
Bzr revision: 108006
agustin.martin@hispalinux.es-20120423103325-xmra3329elgzhmpc
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2012-04-24 15:11 bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap Drew Adams
@ 2012-09-17  0:02 ` Drew Adams
  2014-02-10  4:59 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 11+ messages in thread
From: Drew Adams @ 2012-09-17  0:02 UTC (permalink / raw)
  To: 11325

ping

regression






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2012-04-24 15:11 bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap Drew Adams
  2012-09-17  0:02 ` Drew Adams
@ 2014-02-10  4:59 ` Lars Ingebrigtsen
  2014-02-10  5:09   ` Drew Adams
                     ` (2 more replies)
  1 sibling, 3 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-10  4:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11325

"Drew Adams" <drew.adams@oracle.com> writes:

> Then it was broken differently in Emacs 24, which puts `e..f'
> first in the list, but restores `0..9' to its rightful place.

Isn't the main problem here that it even tries to do a two-letter range?
Seems awfully odd to me:

(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
C-t		Prefix Command
ESC		Prefix Command
SPC		dired-next-line
!		dired-do-shell-command
#		dired-flag-auto-save-files
$		dired-hide-subdir
%		Prefix Command
&		dired-do-async-shell-command
(		dired-hide-details-mode
*		Prefix Command
+		dired-create-directory
-		negative-argument
.		dired-clean-directory
0 .. 9		digit-argument


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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2014-02-10  4:59 ` Lars Ingebrigtsen
@ 2014-02-10  5:09   ` Drew Adams
  2016-04-28 14:43   ` Lars Ingebrigtsen
  2021-10-20 21:32   ` Stefan Kangas
  2 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2014-02-10  5:09 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 11325

> > Then it was broken differently in Emacs 24, which puts `e..f'
> > first in the list, but restores `0..9' to its rightful place.
> 
> Isn't the main problem here that it even tries to do a two-letter
> range?

You could argue that also.  But there is no ambiguity in such a
notation, given that if `e .. f' were a multiple-key sequence
then it would be handled differently (via `Prefix Key').

Anyway, that is not what this bug report is about.  But yes,
if we got rid of that notation then presumably `e' and `f' would
go back to their rightful places alphabetically.

> Seems awfully odd to me:

Being out of order is odd.  That is what this bug thread is about.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2014-02-10  4:59 ` Lars Ingebrigtsen
  2014-02-10  5:09   ` Drew Adams
@ 2016-04-28 14:43   ` Lars Ingebrigtsen
  2016-04-28 15:00     ` Lars Ingebrigtsen
  2021-10-20 21:32   ` Stefan Kangas
  2 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-28 14:43 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11325

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2016-04-28 14:43   ` Lars Ingebrigtsen
@ 2016-04-28 15:00     ` Lars Ingebrigtsen
  2016-04-29 16:35       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-28 15:00 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11325

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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:

That was totally wrong.  What happens is that the e .. f is output by
describe_vector, but all the other characters are in the else.

  for (tail = map; CONSP (tail); tail = XCDR (tail))
    {
      QUIT;

      if (VECTORP (XCAR (tail))
	  || CHAR_TABLE_P (XCAR (tail)))
	describe_vector (XCAR (tail),
			 prefix, Qnil, elt_describer, partial, shadow, map,
			 1, mention_shadow);
      else if (CONSP (XCAR (tail)))

For some reason or other.

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2016-04-28 15:00     ` Lars Ingebrigtsen
@ 2016-04-29 16:35       ` Lars Ingebrigtsen
  2022-01-31 16:32         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-29 16:35 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11325

Here's a test case that's easier to work with.

(defvar foo-map
  (let ((map (make-keymap)))
    (define-key map "a" 'left-char)
    (define-key map "f" 'right-char)
    (define-key map "g" 'right-char)
    (define-key map "z" 'left-char)
    map))

This gives the following wrong output:

(insert (substitute-command-keys "\\{foo-map}"))
key             binding
---             -------

f .. g		right-char

a		left-char
z		left-char

If I use a `make-sparse-keymap' instead, I get the following, correct
output:

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

a		left-char
f .. g		right-char
z		left-char

So in non-sparse keymaps, there's something odd about how consecutive
key bindings are represented, and this leaks out in
`substitute-command-keys'.

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






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2014-02-10  4:59 ` Lars Ingebrigtsen
  2014-02-10  5:09   ` Drew Adams
  2016-04-28 14:43   ` Lars Ingebrigtsen
@ 2021-10-20 21:32   ` Stefan Kangas
  2021-10-21  3:11     ` Lars Ingebrigtsen
  2 siblings, 1 reply; 11+ messages in thread
From: Stefan Kangas @ 2021-10-20 21:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 11325

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> Then it was broken differently in Emacs 24, which puts `e..f'
>> first in the list, but restores `0..9' to its rightful place.
>
> Isn't the main problem here that it even tries to do a two-letter range?
> Seems awfully odd to me:

This could be easily fixed using:

diff --git a/src/keymap.c b/src/keymap.c
index ca1dbe368e..1c6f75a767 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -3101,10 +3101,13 @@ describe_vector (Lisp_Object vector,
Lisp_Object prefix, Lisp_Object args,
 	    }
 	}

-      /* If we have a range of more than one character,
-	 print where the range reaches to.  */
+      /* If we have a range of more than two characters, print where
+	 the range reaches to.  We specifically avoid printing two
+	 character ranges, as they aren't very easy on the reader.  */

-      if (i != starting_i)
+      if ((i - starting_i) < 2)
+	i = starting_i;
+      else
 	{
 	  insert (" .. ", 4);

> (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
> C-t		Prefix Command
> ESC		Prefix Command
> SPC		dired-next-line
> !		dired-do-shell-command
> #		dired-flag-auto-save-files
> $		dired-hide-subdir
> %		Prefix Command
> &		dired-do-async-shell-command
> (		dired-hide-details-mode
> *		Prefix Command
> +		dired-create-directory
> -		negative-argument
> .		dired-clean-directory
> 0 .. 9		digit-argument





^ permalink raw reply related	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2021-10-20 21:32   ` Stefan Kangas
@ 2021-10-21  3:11     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-21  3:11 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 11325

Stefan Kangas <stefan@marxist.se> writes:

>> Isn't the main problem here that it even tries to do a two-letter range?
>> Seems awfully odd to me:
>
> This could be easily fixed using:

Looks good to me (but I haven't tried the patch).

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2016-04-29 16:35       ` Lars Ingebrigtsen
@ 2022-01-31 16:32         ` Lars Ingebrigtsen
  2022-01-31 16:38           ` bug#11325: [External] : " Drew Adams
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-31 16:32 UTC (permalink / raw)
  To: Drew Adams; +Cc: 11325

I've now fixed this in Emacs 29 for dired (and other two-character
ranges).  Bigger ranges are still output separately in a block at the
start, but I think that's OK.  (And it's quite rare.)

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






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11325: [External] : Re: bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap
  2022-01-31 16:32         ` Lars Ingebrigtsen
@ 2022-01-31 16:38           ` Drew Adams
  0 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2022-01-31 16:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 11325@debbugs.gnu.org

> I've now fixed this in Emacs 29 for dired (and other two-character
> ranges).  Bigger ranges are still output separately in a block at the
> start, but I think that's OK.  (And it's quite rare.)

The question is whether the regression was fixed.
Is the output as sane as what it used to be,
before it was broken?  See the bug report for
more detail.

If the regression isn't fixed then please change
the status to "won't fix".





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-01-31 16:38 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-24 15:11 bug#11325: 24.1.50; regression: bad order for `substitute-command-keys' with keymap Drew Adams
2012-09-17  0:02 ` Drew Adams
2014-02-10  4:59 ` Lars Ingebrigtsen
2014-02-10  5:09   ` Drew Adams
2016-04-28 14:43   ` Lars Ingebrigtsen
2016-04-28 15:00     ` Lars Ingebrigtsen
2016-04-29 16:35       ` Lars Ingebrigtsen
2022-01-31 16:32         ` Lars Ingebrigtsen
2022-01-31 16:38           ` bug#11325: [External] : " Drew Adams
2021-10-20 21:32   ` Stefan Kangas
2021-10-21  3:11     ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.