GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Tue, 05 Jul 2022 13:24:45 +0200

Gregory Heytings <gregory <at> heytings.org> writes:

> +  When a file with extremely long lines is opened or inserted in a
> +buffer, Emacs automatically enters auto-narrow mode, and the word
> +@samp{Auto-Narrow} appears in the mode line.  This means that Emacs
> +restricts display, but not editing, to a portion of the buffer above
> +and below point.  All editing commands, including narrowing commands,
> +remain available, and they act on the whole buffer.  For example,
> +@kbd{M->} moves point to the end of the buffer, and not, as would
> +happen with ordinary narrowing, to the end of the portion of the
> +buffer to which display is currently restricted.

Oh, that's an interesting approach.  I haven't tried your patch, but it
sounds like it'd do the trick.

> +      if (!noninteractive && !NILP (Vauto_narrow_long_line_threshold))
> +	{
> +	  ptrdiff_t cur, next, found, max = 0;
> +	  for (cur = PT; cur < PT + inserted; cur = next)
> +	    {
> +	      next = find_newline1 (cur, CHAR_TO_BYTE (cur), 0, -1, 1,
> +				    &found, NULL, true);

You could also use Fbuffer_line_statistics here, which I think should be
faster.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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