GNU bug report logs - #57212
29.0.50; [PATCH] Citizen's arrest of end-of-defun-moves-to-eol

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57212 <at> debbugs.gnu.org, dick.r.chiang <at> gmail.com
Subject: Re: bug#57212: 29.0.50; [PATCH] Citizen's arrest of
 end-of-defun-moves-to-eol
Date: Tue, 16 Aug 2022 15:59:39 +0300

> Date: Tue, 16 Aug 2022 08:14:46 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dick.r.chiang <at> gmail.com, 57212 <at> debbugs.gnu.org
> 
> >>> If you're convinced narrowing within a critical section of redisplay 
> >>> is safe (and I suspect it is), do it all the time, not just when 
> >>> "long_line_optimizations_p" is true.
> >>
> >> That might indeed be what Emacs could do in the long term, once we have 
> >> enough experience with it.
> >
> > No, it shouldn't, because of the adverse effects of that on some aspects 
> > of the Emacs behavior.
> 
> Indeed.  I should have added something like "if we find a way to cope with 
> these adverse effects".

I agree, but I have hard time imagining that miracle, not without
completely redesigning the display engine (and maybe some other parts
of Emacs, like buffer text) based on very different principles.  Most
of the "optimizations" we made are actually shortcuts which ignore
certain aspects of display that we decided were less important than
reasonable response time.

Previous Next

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