GNU bug report logs -
#23917
25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
Previous Next
Reported by: Robert Pluim <rpluim <at> gmail.com>
Date: Fri, 8 Jul 2016 12:43:02 UTC
Severity: normal
Tags: fixed
Found in version 25.0.95
Fixed in version 25.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rpluim <at> gmail.com, 23917 <at> debbugs.gnu.org, alex.bennee <at> linaro.org, jwiegley <at> gmail.com, nljlistbox2 <at> gmail.com, npostavs <at> users.sourceforge.net
> 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?
This bug report was last modified 8 years and 303 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.