bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34214: 25.3; minibuffer function help in lisp modes changes match-da


From: Stefan Kangas
Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data
Date: Thu, 13 Aug 2020 04:37:05 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

tags 34214 + notabug
thanks

Philipp Stephani <p.stephani2@gmail.com> writes:

>> Programming an Emacs lisp program that uses match-data, debugging pieces
>> by hand, I realized that managing matchs was a nightmare.  At first I
>> thought that navigation commands like C-a or C-M-f were messing
>> match-data (as one could think they use searching).  It could be.  But
>> for sure, that very handy help line that shows function arguments are
>> messing match data, making difficult to program Emacs lisp.
[...]
>> What I expect:
>>
>> No unnecessary side-effects like change match-data should happen while
>> simply navigating through code.  Lisp modes should protect searches on
>> background with save-match-data, because it makes a nightmare to
>> evaluate code by hand.
>>
>
> Any function is allowed to change the match data, see
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Match-Data.html:
> "Notice that all functions are allowed to overwrite the match data
> unless they're explicitly documented not to do so.".
> In general you almost always want to immediately bind the match
> results to variables, like so:
>
> (when (string-match "f" "foo")
>   (let ((match (match-string 0 "foo")))
>     ...
>     match))
>
> Evaluating the entire 'when' form will then work as intended.

Agreed, I don't think there's a bug here.  This is just how this works,
and is documented to work.

Any other opinions?

Best regards,
Stefan Kangas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]