[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