[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56393: Actually fix the long lines display bug
From: |
Eli Zaretskii |
Subject: |
bug#56393: Actually fix the long lines display bug |
Date: |
Tue, 05 Jul 2022 19:34:31 +0300 |
> Date: Tue, 05 Jul 2022 16:21:57 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56393@debbugs.gnu.org
>
>
> >> As I said, if that's the case, it's easy to add a "(let
> >> ((auto-narrow-long-line-threshold nil))" around the code, in this case
> >> either in the with-temp-buffer macro or in the code above.
> >
> > These macros are called a lot, and I don't think it's a good idea to
> > tell all their callers to make such changes.
> >
>
> As I said, this can also be done inside the with-temp-buffer macro. A
> (very quick) review of calls to insert-file-contents in Emacs core and
> ELPA tells me that that the majority of these calls are inside a
> with-temp-buffer or with-current-buffer (with a temporary buffer).
with-current-buffer can be legitimately called to insert stuff into a
buffer that is displayed. The macro doesn't know.
> > I think we should try to work out a solution that only affects the C
> > code in the display engine, such that any Lisp called from the various
> > hooks and places in display code is not affected, and neither are
> > pre-command-hook and post-command-hook. That should have almost the
> > same effect, performance-wise, but be much safer than the automatic
> > narrowing that affects everything in Emacs as long as the narrowing is
> > in effect.
> >
> > IOW, replace all BEGV and ZV in display code with a couple of new
> > macros, which effectively "narrow" the buffer, as far as the display
> > engine is concerned. Then set the limits of this restriction in
> > redisplay_window, and remove it when the window's redisplay is done. Or
> > something along these lines.
>
> I guess this means, in essence, to throw away the patch? Or do I
> interpret what you wrote too negatively?
It means I think the idea is good, but the main part of the
implementation should be on a different level, not using narrowing,
which has a too global effect.
But I'd like to hear more opinions, including from Gerd. I didn't
think about this long enough to be sure I'm right.
- bug#56393: Actually fix the long lines display bug, (continued)
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Robert Pluim, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/05
- bug#56393: Actually fix the long lines display bug,
Eli Zaretskii <=
- bug#56393: Actually fix the long lines display bug, Lars Ingebrigtsen, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/06