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

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

bug#31586: 27.0.50; `frame-title-format' doesn't save match data


From: Eli Zaretskii
Subject: bug#31586: 27.0.50; `frame-title-format' doesn't save match data
Date: Sun, 27 May 2018 19:20:52 +0300

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 26 May 2018 16:58:56 -0400
> Cc: 31586@debbugs.gnu.org
> 
> > perform-replace: Args out of range: #<buffer *scratch*>, 0, 1
> >
> > Backtrace:
> >
> > Debugger entered--Lisp error: (args-out-of-range #<buffer *scratch*> 0 1)
> >   buffer-substring-no-properties(0 1)
> >   perform-replace("a" "b" t nil nil nil nil nil nil nil nil)
> >   query-replace("a" "b" nil nil nil nil nil)
> >   funcall-interactively(query-replace "a" "b" nil nil nil nil nil)
> >   call-interactively(query-replace nil nil)
> >   command-execute(query-replace)
> 
> FWIW, I think this qualifies as a bug in query-replace: Elisp code
> should never presume that the match-data is preserved across something
> like sit-for, read-char, or any other function which can run process
> filters, redisplay, timers, or contains a yield-point.

Is this practical?  We have any number of hooks, advices, and other
means to make arbitrary Lisp run almost off any function call.  Given
that redisplay can be entered by such Lisp by calling 'redisplay' or
'message' or one of the other functions you mentioned, your suggestion
would mean we need to save-match-data around any call to any
function.  That would make our code very cluttered, indeed.

My POV is that using :eval is intrinsically tricky, and whoever does
that should take the necessary precautions.





reply via email to

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