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

[Miguel V. S. Frasson]

Hi.

The "documented" behavior is in Elisp Reference, but not in doc-strings of functions that rely on match data. So they are not so easily spotted by non-experienced users.

This bug teached me a lesson, because it took me a lot of time to realize how volatile match-data is, changed even by a helper mode like eldoc.

IMO it is so easy to avoid interference into user experience in this case, adding convenience, just by saving match data inside eldoc...

Should a helper mode be able to "confuse" non-experienced users because it could rely on "documented" behavior? If so, why does Emacs have disabled commands, if they are also documented?

Best regards

Miguel 

Em qui., 13 de ago. de 2020 às 08:37, Stefan Kangas <stefan@marxist.se> escreveu:

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

--

Miguel Vinicius Santini Frasson
mvsfrasson@gmail.com