A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-07/msg01653.html below:

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Juri Linkov 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 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
> 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?





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4