* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
@ 2012-12-23 15:18 Bastien Guerry
2012-12-23 15:47 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Bastien Guerry @ 2012-12-23 15:18 UTC (permalink / raw)
To: 13260
`delete-char' and `delete-backward-char' modify the match data.
I know the policy is to let any function assume the match data
are not saved, but I think an exception would be useful here.
If so, I'll provide a patch.
Thanks!
--
Bastien
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-23 15:18 bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien Guerry
@ 2012-12-23 15:47 ` Stefan Monnier
2012-12-23 16:40 ` Bastien
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2012-12-23 15:47 UTC (permalink / raw)
To: Bastien Guerry; +Cc: 13260
> I know the policy is to let any function assume the match data
> are not saved, but I think an exception would be useful here.
Why?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-23 15:47 ` Stefan Monnier
@ 2012-12-23 16:40 ` Bastien
2012-12-24 0:54 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Bastien @ 2012-12-23 16:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13260
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I know the policy is to let any function assume the match data
>> are not saved, but I think an exception would be useful here.
>
> Why?
Because delete-char is very low-level and because it is hard to
guess why it would modify the match data -- hence very easy to
assume it will not, while it does. Principle of least surprise?
--
Bastien
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-23 16:40 ` Bastien
@ 2012-12-24 0:54 ` Stefan Monnier
2012-12-24 1:03 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'? Drew Adams
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Stefan Monnier @ 2012-12-24 0:54 UTC (permalink / raw)
To: Bastien; +Cc: 13260
>>> I know the policy is to let any function assume the match data
>>> are not saved, but I think an exception would be useful here.
>> Why?
> Because delete-char is very low-level and because it is hard to
> guess why it would modify the match data -- hence very easy to
> assume it will not, while it does.
AFAIK delete-char does not modify the match-data any more than other
buffer-modifying operations (such as delete-region, insert, ...).
They all just modify the buffer, which is turn can modify the match-data
because it runs various hooks which can do all kinds of things.
> Principle of least surprise?
The rule "expect the match-data to be destroyed all the time" is the one
that leads to the least surprise. 99% of the functions can destroy the
match-data, even though they may preserve it in 99% of
the circumstances.
And in 99% of the cases where they do destroy the match-data, nobody
cares anyway, which is why we shouldn't always save-match-data.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'?
2012-12-24 0:54 ` Stefan Monnier
@ 2012-12-24 1:03 ` Drew Adams
2012-12-24 1:24 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien
2012-12-24 1:25 ` Bastien
2 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2012-12-24 1:03 UTC (permalink / raw)
To: 'Stefan Monnier', 'Bastien'; +Cc: 13260
> 99% of the functions can destroy the match-data, even though they
> may preserve it in 99% of the circumstances. And in 99% of the
> cases where they do destroy the match-data, nobody cares anyway,
> which is why we shouldn't always save-match-data.
This is well put, and helpful. How about saying something similar in the Elisp
manual? It provides a good guideline for understanding when you might want to
save match data.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-24 0:54 ` Stefan Monnier
2012-12-24 1:03 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'? Drew Adams
@ 2012-12-24 1:24 ` Bastien
2012-12-24 5:09 ` Stefan Monnier
2012-12-24 1:25 ` Bastien
2 siblings, 1 reply; 8+ messages in thread
From: Bastien @ 2012-12-24 1:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13260
Hi Stefan,
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> AFAIK delete-char does not modify the match-data any more than other
> buffer-modifying operations (such as delete-region, insert, ...).
> They all just modify the buffer, which is turn can modify the match-data
> because it runs various hooks which can do all kinds of things.
Okay.
>> Principle of least surprise?
>
> The rule "expect the match-data to be destroyed all the time" is the one
> that leads to the least surprise. 99% of the functions can destroy the
> match-data, even though they may preserve it in 99% of
> the circumstances.
That's fine -- but what about "should"?
For all the functions like (defun x () "..." (save-match-data ...))
the match data is saved. For 99% of these functions, it's a design
choice saying "these functions *should* save the match data". (Yes,
there are such functions!)
> And in 99% of the cases where they do destroy the match-data, nobody
> cares anyway, which is why we shouldn't always save-match-data.
I'm fine with a rule like "anything that modifies the buffer should
be assumed to destroy the match data" -- given your explanation above.
But I'm not convinced this should apply to all other functions.
--
Bastien
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-24 0:54 ` Stefan Monnier
2012-12-24 1:03 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'? Drew Adams
2012-12-24 1:24 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien
@ 2012-12-24 1:25 ` Bastien
2 siblings, 0 replies; 8+ messages in thread
From: Bastien @ 2012-12-24 1:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13260-done
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> And in 99% of the cases where they do destroy the match-data, nobody
> cares anyway, which is why we shouldn't always save-match-data.
Ps: I wasn't talking about /always/ saving the match data of course.
Closing this report now.
--
Bastien
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?
2012-12-24 1:24 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien
@ 2012-12-24 5:09 ` Stefan Monnier
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2012-12-24 5:09 UTC (permalink / raw)
To: Bastien; +Cc: 13260
> I'm fine with a rule like "anything that modifies the buffer should
> be assumed to destroy the match data" -- given your explanation above.
> But I'm not convinced this should apply to all other functions.
Basically, if you need the match-data, you should get it right after the
match itself. So save-match-data is something to use between the match
and the match-data extraction (unless this code is trivial, as is
usually the case), rather than around functions that might potentially
appear occasionally somewhere between a match and
a match-data extraction.
I know these requests will keep coming until the byte-compiler is
enhanced to flag places where a save-match-data is potentially missing,
or maybe until we replace the "string-match followed by
match-beginning/end" with a "match and then bind subgroups to provided
vars".
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-12-24 5:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-23 15:18 bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien Guerry
2012-12-23 15:47 ` Stefan Monnier
2012-12-23 16:40 ` Bastien
2012-12-24 0:54 ` Stefan Monnier
2012-12-24 1:03 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'? Drew Adams
2012-12-24 1:24 ` bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'? Bastien
2012-12-24 5:09 ` Stefan Monnier
2012-12-24 1:25 ` Bastien
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.