GNU bug report logs - #64788
29.0.92; M-s and M-r don't search in "future history"

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sat, 22 Jul 2023 08:23:02 UTC

Severity: normal

Merged with 64839

Found in versions 29.0.91, 29.0.92

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64788 <at> debbugs.gnu.org
Subject: bug#64788: 29.0.92; M-s and M-r don't search in "future history"
Date: Mon, 24 Jul 2023 20:29:02 +0300
> To reproduce:
>
>   emacs -Q
>   C-h v
>   M-n
>
> Observe that a variable's name is inserted into the minibuffer; in my
> case it's "find-sibling-rules".  (It was inserted by
> minibuffer-default-add-completions.)
>
>   M-p
>
> Now the minibuffer is empty (except for the prompt), and
> find-sibling-rules is in "future history".
>
>   M-s sibling RET
>
> Surprise: instead of finding find-sibling-rules, this displays a
> message: "No later matching history element".
>
>   M-n
>   M-n
>
> Now we have 2 elements in the "future history", but:
>
>   M-r sibling RET
>
> signals an error: Wrong type argument: stringp, nil, instead of
> finding find-sibling-rules.
>
> Bottom line: M-n and M-p unexpectedly don't search "future history".

I suppose M-s and M-r.  OTOH, C-s and C-r search "future history" nicely.
Why M-s and M-r don't use the same search functions as C-s and C-r?




This bug report was last modified 1 year and 328 days ago.

Previous Next


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