From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Wed, 06 Jul 2022 20:50:45 +0300 Message-ID: <83wncq5dvu.fsf@gnu.org> References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <83a69n90t8.fsf@gnu.org> <38c1a31040ad21b41adc@heytings.org> <835ykb8x3z.fsf@gnu.org> <38c1a310403dbabc7270@heytings.org> <834jzv8sv4.fsf@gnu.org> <38c1a31040ba2976eb4d@heytings.org> <83y1x77c2w.fsf@gnu.org> <87k08rkvgb.fsf@gnus.org> <38c1a31040e94458bd3d@heytings.org> <83o7y277b8.fsf@gnu.org> <762d224809bcab0d6bbc@heytings.org> <83fsje74pz.fsf@gnu.org> <762d224809bc038d2030@heytings.org> <838rp672p7.fsf@gnu.org> <762d224809114fbaf4af@heytings.org> <834jzu6wnu.fsf@gnu.org> <762d224809c7a439895e@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9907"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56393@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 06 19:54:05 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o99Dv-0002J1-Ex for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 19:54:03 +0200 Original-Received: from localhost ([::1]:44050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o99Du-00087j-G4 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 13:54:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o99B0-0004Nk-CR for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 13:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32925) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o99B0-0006rA-3c for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 13:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o99Az-0007nv-WC for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 13:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2022 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165712985829988 (code B ref 56393); Wed, 06 Jul 2022 17:51:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 6 Jul 2022 17:50:58 +0000 Original-Received: from localhost ([127.0.0.1]:55055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o99Av-0007nc-Sc for submit@debbugs.gnu.org; Wed, 06 Jul 2022 13:50:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o99Au-0007nN-KH for 56393@debbugs.gnu.org; Wed, 06 Jul 2022 13:50:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o99Ap-0006nU-4S; Wed, 06 Jul 2022 13:50:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=E/B8qcxFujU1E8oM+QEAw1iSS+JzvUOyhFjMxns+Tdo=; b=TweP9EhP/qFR HYUNzecuYdcwb8jAc7JVsXbk7hW8AmIZ9sJD50GEocSHYLBYhwsk/XgRgmafdIbmFWy0BFFD8q7IC XdUhauEAjR1ehKy1TB/zVd7RaoNL9QzLNRUMEF4wE2CoqsP/HtbQQP40k3gxtDsgleXrUXeByM/mF 8pRHOHSq+SpG47d/eoEsZ1kiJWQQ153uUrAJ/Q8vt614+BBtIqgx0bse7G2cUduZ3WjOIdTAS07lf D6o3r9VdGSeljqB/EnkCb6WWeROPaf1zYDWYUY5WTO1gCdV4Lu7cc1vqtYMSAOJLaXLzKNMS9zctB fr+EdlFj+kMIpwtmLsLIag==; Original-Received: from [87.69.77.57] (port=3783 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o99Ao-0008Ic-K6; Wed, 06 Jul 2022 13:50:50 -0400 In-Reply-To: <762d224809c7a439895e@heytings.org> (message from Gregory Heytings on Wed, 06 Jul 2022 16:57:22 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236283 Archived-At: > Date: Wed, 06 Jul 2022 16:57:22 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 56393@debbugs.gnu.org > > > How is it different from the code in the display engine that calls > > next-single-char-property-change or remove-text-properties, or loops > > over all the overlays at certain position calling overlay-get? In Emacs > > nowadays font-lock is almost always called as part of redisplay, so I > > don't see how we can separate them and say that this is a different > > problem. > > Again, I don't know (my understanding of the font-lock machinery is very > limited). Your understanding of font-lock, or your understanding how it is invoked from the display code? I can help with the latter. When Emacs is about to display some chunk of text, it checks whether the text has a non-nil 'fontified' property. If it does, that chunk of text was already fontified, but if not, the display engine calls font-lock (via jit-lock.el) to fontify the next 1500 characters, and puts a non-nil 'fontified' property on those 1500 characters. The result is face properties, which are then actually displayed. So if font-lock is slow for some reason, it will slow down redisplay. > I only observe that turning font lock mode off makes things > significantly better. And that turning highlighting off in such > files is what other editors do, too. So at this point I don't see > why it wouldn't be a reasonable thing to do. I think we should understand why it becomes slow before we decide whether to turn it off or speed it up somehow. Other editors fontify text using very different methods, so their limitations are not necessarily similar to ours. Btw, what happens if you turn on jit-lock-debug-mode? > That's something I already did, and yes, I do see Emacs choking. Try to > navigate in the attached 30K file. Then try again after turning font-lock > mode off. > > (But I do not understand what you mean by "leave 'recenter' as it behaves > on master".) I meant disable its disabling. > > For example, why not use 2 window-fulls before and after the window > > (assuming that gives us a smaller chunk)? > > That would mean to compute the dimensions of the window in a command-hook. > I tried to make that hook as efficient as possible, so it is on purpose > that I used a constant there, with something that seemed a reasonable > default, instead of computing it again and again. The primitives that access the window height and width are simple accessors to C variables, so they are very cheap. So I think this might be a case of premature optimization. A fixed constant is problematic because it needs to be large enough to satisfy the largest possible window. So for many windows we process too many characters, and slow down redisplay unnecessarily for the sake of those extreme cases. > > The point is that we should try to squeeze the most out of this > > narrowing idea, before we start disabling up features. Because > > disabling features is a kind of retreat, an indication that we turned > > every stone and couldn't make Emacs fast enough, so we are kinda giving > > up. And it's too early to give up, IMO. > > I agree with that idea/direction, but again I think that at least now > Emacs doesn't do worse than all other editors out there, and in fact it > does way better. If all editors turn off highlighting in such cases, that > must surely be for a good reason. Highlighting means parsing, and parsing > is infinitely more expensive than not parsing. Again, why give up without trying to fix that? > > And to me this means that you see an example of a problem I mentioned > > earlier: code from the display engine is used in commands that basically > > have nothing to do with redisplay per se, and your current > > implementation doesn't take care of those calls into the display code by > > commands like recenter, C-v, C-n, etc. I think sooner or later we will > > need to present a narrowed buffer to them as well. > > You mean, a widened buffer? No, a narrowed buffer. These commands use code from the display engine, so letting them process a widened buffer means they run slowly. > Yes, that's a question for which I still don't have a clear answer: > is it better to "whitelist" commands that will always work correctly > with a narrowed buffer or to "whitelist" commands that may require a > widened buffer? I tend to think that the latter is better. I think we need to present a narrowed buffer to display code regardless of whether it runs by redisplay or by commands like C-n or C-v or 'recenter'. > > What kind of example do you want to see? What do you mean by > > "problematic" in this context? > > I mean, an actual example of "Lisp code that expects to have access to the > entire buffer when it has no reason to expect narrowing", that is, Lisp > code that expects to have access to the entire buffer without using > (save-restriction (widen) ...). Are you saying that you don't believe in the existence of such code? Every Lisp program expects to see the same narrowing (or lack thereof) as the user sees. So anything different is a time bomb waiting to go off. > > Which is why I'm saying that it is better to restrict the display code > > via some other means, and leave the narrowing alone. After all, it is > > our code that deliberately references BEGV and ZV in the display engine, > > so using some other values shouldn't be that difficult, I think. > > Yes, I've understood that you want to do something else. No, it's the same idea, just implemented differently, and thus without some of the problems we are discussing. (But slowness of font-lock will still need a separate solution -- or the conclusion that we have no alternative but turn it off.)