GNU bug report logs - #77942
31.0.50; replace-region-contents gets stuck

Previous Next

Full log

Message #53 received at 77942 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: monnier <at> iro.umontreal.ca, 77942 <at> debbugs.gnu.org
Subject: Re: bug#77942: 31.0.50; replace-region-contents gets stuck
Date: Tue, 22 Apr 2025 16:06:34 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  77942 <at> debbugs.gnu.org
> Date: Tue, 22 Apr 2025 13:43:51 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: 77942 <at> debbugs.gnu.org
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Date: Mon, 21 Apr 2025 22:39:39 +0200
> >> 
> >> Just found that replace-region-contents apparently uses a diff
> >> algorithm from diffseq.h, and that says
> >> 
> >>    The basic algorithm is described in:
> >>    "An O(ND) Difference Algorithm and its Variations", Eugene W. Myers,
> >>    Algorithmica Vol. 1, 1986, pp. 251-266,
> >> 
> >> If N is the buffer size and D is the diff size, and both are large, good
> >> luck with that. And indeed, reducing the buffer size by 2 orders of
> >> magnitude makes things acceptable for my use case.
> >
> > You should be able to cut your losses by passing a sufficiently small
> > number for MAX-SEC, perhaps even zero.
> 
> MAX-SECS isn't working as expected said Stef elsewhere.

If you set it to zero, it must work as expected.  If it doesn't, it's
a bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.