tags 23917 fixed
close 23917 25.1
quit
Eli Zaretskii writes:
>> From: npost...@users.sourceforge.net
>> Cc: 23...@debbugs.gnu.org, nljlistb...@gmail.com, jwieg...@gmail.com,
>> rpl...@gmail.com, monn...@iro.umontreal.ca, alex.ben...@linaro.org
>> Date: Thu, 21 Jul 2016
Eli Zaretskii writes:
>> From: npost...@users.sourceforge.net
>> Cc: 23...@debbugs.gnu.org, nljlistb...@gmail.com, jwieg...@gmail.com,
>> rpl...@gmail.com, monn...@iro.umontreal.ca, alex.ben...@linaro.org
>> Date: Wed, 20 Jul 2016 23:00:59 -0400
>>
>> > Please also make sure
Eli Zaretskii writes:
>> From: npost...@users.sourceforge.net
>> Cc: Eli Zaretskii , 23...@debbugs.gnu.org,
>> nljlistb...@gmail.com, jwieg...@gmail.com, rpl...@gmail.com,
>> alex.ben...@linaro.org
>> Date: Wed, 20 Jul 2016 20:56:28 -0400
>>
>> >> Maybe
Eli Zaretskii writes:
>> From: Stefan Monnier
>> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org,
>> jwieg...@gmail.com, nljlistb...@gmail.com
>> Date: Tue, 19 Jul 2016 00:48:19 -0400
>>
>> > The more general problem is when
Stefan Monnier writes:
>> 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.
>
> Oh, right, that's also an option. It might suffer from another
On Wed, Jul 20, 2016 at 9:47 PM, Stefan Monnier
wrote:
> - maybe we can even adjust_match_data in every call to replace_range
> rather than just in the one from Freplace_match.
That would be simpler, though I wasn't sure if it would be correct.
Eli Zaretskii writes:
> OK, let's wait for a few days to give time to the people who were
> affected by the issue to test the patch, and if no new issues come up,
> please push the version with the error code to emacs-25.
I'll wait until Monday for the first release candidate to
Eli Zaretskii writes:
>> From: npost...@users.sourceforge.net
>> Cc: 23...@debbugs.gnu.org, nljlistb...@gmail.com, jwieg...@gmail.com,
>> rpl...@gmail.com, monn...@iro.umontreal.ca, alex.ben...@linaro.org
>> Date: Thu, 21 Jul 2016 21:08:43 -0400
>>
>> I made the same
> From: npost...@users.sourceforge.net
> Cc: 23...@debbugs.gnu.org, nljlistb...@gmail.com, jwieg...@gmail.com,
> rpl...@gmail.com, monn...@iro.umontreal.ca, alex.ben...@linaro.org
> Date: Thu, 21 Jul 2016 21:08:43 -0400
>
> I made the same adjustments to the saved sub_start and sub_end
>
> From: npost...@users.sourceforge.net
> Cc: 23...@debbugs.gnu.org, nljlistb...@gmail.com, jwieg...@gmail.com,
> rpl...@gmail.com, monn...@iro.umontreal.ca, alex.ben...@linaro.org
> Date: Wed, 20 Jul 2016 23:00:59 -0400
>
> > Please also make sure bug#23869 is still fixed after this.
>
>
>> - maybe we can even adjust_match_data in every call to replace_range
>> rather than just in the one from Freplace_match.
> That would be simpler, though I wasn't sure if it would be correct.
I think it's definitely not an option for emacs-25. But maybe we can
try it on master.
> From: npost...@users.sourceforge.net
> Cc: Eli Zaretskii , 23...@debbugs.gnu.org,
> nljlistb...@gmail.com, jwieg...@gmail.com, rpl...@gmail.com,
> alex.ben...@linaro.org
> Date: Wed, 20 Jul 2016 20:56:28 -0400
>
> >> Maybe there's a misunderstanding. What Noam suggested
> Solution: adjust in between the before and after change functions.
> Patch below. I think there shouldn't be performance problems, although
> it does add yet another flag to replace_range (by the way, I noticed
> that the MARKERS flags is never 0, so it's redundant). I tested with
> the
> 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.
Oh, right, that's also an option. It might suffer from another problem,
which is that the match-data will be broken while the
> From: Stefan Monnier
> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org,
> jwieg...@gmail.com, nljlistb...@gmail.com, npost...@users.sourceforge.net
> Date: Wed, 20 Jul 2016 14:19:59 -0400
>
> > Is it OK to adjust the match data before
> 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
> From: Stefan Monnier
> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org,
> jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 21:50:07 -0400
>
> > Do we care that using save-match-data in every call to replace-match
> > might
> Do we care that using save-match-data in every call to replace-match
> might mean a performance hit?
I do but:
- to be honest, it's probably lost in the noise.
- if we copy search_regs.start and search_regs.end with something like
alloca+memcpy (instead of calling Fmatch_data), the cost
> From: Stefan Monnier
> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org,
> jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 12:03:51 -0400
>
> I guess the next best thing is:
> - copy search_regs.start and search_regs.end
> Before call to replace_range in replace-match:
>
>|---|---|--||
>s1 e1 s2e2 EOB
>
> (s1, e1, etc. are the start and end of the corresponding
> sub-expressions.)
>
> After the call to replace_range in replace-match:
>
>
> From: Stefan Monnier
> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org,
> jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 00:48:19 -0400
>
> > The more general problem is when there's at least one more
> > sub-expression,
> From: Stefan Monnier
> Cc: Robert Pluim , 23...@debbugs.gnu.org,
> alex.ben...@linaro.org, jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 20:58:35 -0400
>
> > I think this change performed by save-match-data is harmless: the
> The more general problem is when there's at least one more
> sub-expression, whose start and/or end are after the new EOB.
> Those sub-expression's data will be completely bogus after the
> adjustment,
If they were after the EOB, they were already bogus to start with.
So there's really not much
> From: Stefan Monnier
> Cc: Robert Pluim , 23...@debbugs.gnu.org,
> alex.ben...@linaro.org, jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 20:58:35 -0400
>
> > In the case in point, a single character at EOB (= 62) was
> In the case in point, a single character at EOB (= 62) was deleted,
> which made EOB be 61, one less than its previous value. When
> save-match-data was called from within a hook set up by Org, it tried
> to record the end of the sub-expression as 62, but set-marker silently
> changed that to
> From: John Wiegley
> Cc: Robert Pluim , Stefan Monnier
> , 23...@debbugs.gnu.org, alex.ben...@linaro.org,
> nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 12:04:11 -0700
>
> > Eli Zaretskii writes:
>
> >
> Eli Zaretskii writes:
> My suggestion to fix this is below. I ask for opinions on (1) whether this
> looks like TRT, (2) whether it is safe enough for emacs-25, and (3) whether
> someone has better ideas.
I didn't even know match-data took arguments, so I defer to your
> From: Robert Pluim
> CC: 23...@debbugs.gnu.org, Alex Bennée
> , jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 14:24:59 +0200
>
> (I'm moving this discussion to the bug, let me know if that's not OK)
Thanks.
> Make sure that you
On Monday, 18 Jul 2016 at 14:50, Kaushal Modi wrote:
> @Eric Would it be possible for you to provide a recipe to recreate
> this issue from an emacs -Q session?
With emacs-snapshot (aka 25.0.95.1), and the following emacs-minimal.el
file:
--8<---cut
I use org-capture heavily, but I do not use a template that causes this
issue.
This issue was posted once again today on the org mailing list and I would
vote for this to be made a blocking bug too.
One useful update we get from Eric Fraga (
http://thread.gmane.org/gmane.emacs.orgmode/108289 )
(I'm moving this discussion to the bug, let me know if that's not OK)
Eli Zaretskii writes:
>> From: Alex Bennée
>> Cc: Eli Zaretskii , "N. Jackson" ,
>> emacs-de...@gnu.org
>> Date: Sun, 17 Jul 2016 18:28:36 +0100
>>
31 matches
Mail list logo