GNU bug report logs - #34214
25.3; minibuffer function help in lisp modes changes match-data

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 34214 <at> debbugs.gnu.org, "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com>
Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data
Date: Thu, 13 Aug 2020 04:37:05 -0700

tags 34214 + notabug
thanks

Philipp Stephani <p.stephani2 <at> 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

Previous Next

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