[Top][All Lists]

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

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was

From: Eli Zaretskii
Subject: [O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Date: Wed, 20 Jul 2016 21:55:29 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden
> Date: Wed, 20 Jul 2016 14:19:59 -0400
> > Is it OK to adjust the match data before actually making the
> > replacement?  If so, I think it's a simpler solution.
> >> PS: I can think of one (theoretical) other/better way to fix this
> >> problem: move the match-data adjustment so it's done within
> >> replace_range before running the after-change-functions.
> > Isn't that almost the same as what Noam suggested?
> Yes, it's the same.  And yes, I like the idea, but I just don't know
> what it would look like as a patch.  I have the impression that it could
> prove either expensive in CPU time and backward incompatible
> (e.g. adjust markers for every buffer modification), or require
> extensive code surgery and/or breaking some abstractions.
> This is just an impression, tho.  I think it'd definitely be the better
> solution, so it's worth investigating anyway, if only for "master" rather
> than for "emacs-25".

Maybe there's a misunderstanding.  What Noam suggested was just to
move the code which adjusts search_regs.start[i] and .end[i] to before
the call to replace_range.  The above values are not markers, and no
other markers are involved, so I'm not sure which markers did you
allude to.  Or why it would be CPU intensive.

What did I miss?

reply via email to

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