From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: New optimisations for long raw strings in C++ Mode. Date: Thu, 11 Aug 2022 16:54:47 +0000 Message-ID: References: <83wnbhtlzb.fsf@gnu.org> <703c2351d96919276449@heytings.org> <83o7wsqlcm.fsf@gnu.org> <83edxoqcnl.fsf@gnu.org> <83a68cqbm0.fsf@gnu.org> <834jykq9m6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32401"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 11 18:56:45 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oMBUC-0008DR-Rh for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Aug 2022 18:56:44 +0200 Original-Received: from localhost ([::1]:37620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMBUB-0000WG-Eu for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Aug 2022 12:56:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMBSZ-0006Kj-U4 for emacs-devel@gnu.org; Thu, 11 Aug 2022 12:55:05 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16387 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oMBSX-0005kA-4X for emacs-devel@gnu.org; Thu, 11 Aug 2022 12:55:03 -0400 Original-Received: (qmail 36511 invoked by uid 3782); 11 Aug 2022 16:54:49 -0000 Original-Received: from acm.muc.de (p4fe157d1.dip0.t-ipconnect.de [79.225.87.209]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 11 Aug 2022 18:54:48 +0200 Original-Received: (qmail 6386 invoked by uid 1000); 11 Aug 2022 16:54:47 -0000 Content-Disposition: inline In-Reply-To: <834jykq9m6.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293377 Archived-At: Hello, Eli. On Wed, Aug 10, 2022 at 20:41:37 +0300, Eli Zaretskii wrote: > > Date: Wed, 10 Aug 2022 17:32:46 +0000 > > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > You seem to disagree with a major idea of the design of the Emacs > > > > > display engine. > > > > I don't think I do. I think you mean the idea of lazy fontification, > > > > though you haven't been specific. > > > No, I mean the idea that redisplay processes only a small amount of > > > buffer text around the window. > > I don't think such an idea is coherent, due to the lack of precision of > > the word "processes". I understand that redisplay _fontifies_ only a > > small amount of buffer text. However, it can get better results if it is > > free to _look_ at text anywhere in the buffer. > Think about the _idea_ of that: we want to process as little as > absolutely necessary for display. It follows that every code we > invoke as part of that job should strive to do the same. I suppose the problem here is differing notions of "absolute necessity". > > You seem to be conflating "fontifying" with "looking at". I don't think > > that's helpful. > I'm not talking about "looking at", I'm taking about processing. > fontification-functions rarely go to far places because they just want > to "look", they go there because they want to process text there, > possibly process all the text from there to window start. OK, I think I see what you mean, now. But I still think it's useful to make a distinction between looking at (for example, the 17 ns per character that parse-partial-sexp takes) and something like the fontification of a C declaration by c-font-lock-declarations, which takes much, much longer. > > > > This is absolutely necessary correctly to fontify (long) strings and > > > > comments, for example. > > > Only if you assume the most simplistic processing. > > If you open a file in its middle (e.g., by desktop), and there's an open > > block comment there, you've got to look arbitrarily far back to detect > > that state. > Really? Then please tell me how is it that we the humans can detect > incorrect fontifications even when shown partial strings and comments? I can't really see how that question follows on from the premiss, but human brains are wired to detect patterns at a single glance in a way that computers aren't, at least not yet. > We know that fontifications are incorrect, and where strings or > comments start or end immediately, just after a single glance. We > never need to go to BOB to find that out. Before the days of font-locking in editors, a standard problem was when a comment didn't end where the user thought it did, for lack of a comment ender. There was a particular problem in Pascal (whose precise details aren't that important) where an unclosed comment on the THEN branch of an IF statement would swallow up the ELSE branch completely, leaving no visible trace or syntactic error. It's worth while being careful about strings and comments. -- Alan Mackenzie (Nuremberg, Germany).