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: Tue, 9 Aug 2022 21:43:28 +0000 Message-ID: References: <87wnbkyuhe.fsf@gnus.org> <83sfm8vxht.fsf@gnu.org> <87k07hxwe9.fsf@gnus.org> <87fsi5xw9l.fsf@gnus.org> <83wnbhtlzb.fsf@gnu.org> <703c2351d96919276449@heytings.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="38061"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 09 23:44:23 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 1oLX1S-0009lP-7U for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 23:44:22 +0200 Original-Received: from localhost ([::1]:50114 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLX1R-00024e-BO for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 17:44:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLX0f-0001Le-UZ for emacs-devel@gnu.org; Tue, 09 Aug 2022 17:43:33 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61902 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oLX0d-0003Tu-PC for emacs-devel@gnu.org; Tue, 09 Aug 2022 17:43:33 -0400 Original-Received: (qmail 14505 invoked by uid 3782); 9 Aug 2022 21:43:29 -0000 Original-Received: from acm.muc.de (p4fe156e6.dip0.t-ipconnect.de [79.225.86.230]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 09 Aug 2022 23:43:29 +0200 Original-Received: (qmail 10636 invoked by uid 1000); 9 Aug 2022 21:43:28 -0000 Content-Disposition: inline In-Reply-To: <703c2351d96919276449@heytings.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=unavailable 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:293335 Archived-At: Hello, Gregory. On Tue, Aug 09, 2022 at 20:39:51 +0000, Gregory Heytings wrote: > >>> But opening the resulting file with "emacs -Q" and then doing a `M->' > >>> now hangs Emacs, which it didn't use to do, I think? > >> If you do (setq long-line-threshold nil), M-> is fast. Only when you > >> omit it does Emacs hang. Hmm. It's meant to be the other way around, > >> isn't it? ;-) > > Yes. I'm guessing there's some additional bug there. > As has been discussed, CC Mode is, sadly, by design, incompatible with the > new feature ..... Er, actually, CC Mode has been around a tad longer than the new feature. It would be more accurate to state that the new feature was, by design, incompatible with existing software. The new feature, by design, breaks long-standing contracts in Emacs, namely that `widen', etc., work. Of course, testing could have shown up this incompatibility at an early stage, perhaps even leading to a solution. A pity we didn't have more thorough testing. So, what do you intend to do about this incompatibility you have introduced? Anything? > .... (and I wonder what the ";-)" above is supposed to convey). The irony of a supposed optimisation causing software to hang. > It insists on accessing the whole buffer, .... There's no need to anthropomorphise. A major mode accesses its buffer. What will we have next! > .... and doesn't downgrade gracefully when it can't. Yeah, it depends on defined functionality working. If only its designers had been clever enough 20 years ago to foresee that parts of Emacs would stop working as documented ..... > In this case, with emacs -Q, after M->, (jit-lock-fontify-now 999600 > 1001100) is called, which calls (c-font-lock-fontify-region 999600 > 1000034), which does (widen), and calls > (font-lock-default-fontify-region 991200 1000034) because these > (991200 and 1000034) are the bounds of the locked narrowing. For some > reason (which I don't have the patience to track down), because that > (widen), which shouldn't be there in the first place,.... Yeah, it would be convenient for you if everybody followed your (controversial) desires, rather than what's advertised in the Elisp manual. However, you knew before constructing your new feature that major modes use widen, and went ahead and broke it anyway. Still, I suppose having rapid processing of monster buffers is more important than longstanding software continuing to work, so that's all right, then. > .... doesn't do what the function expects it to do, > font-lock-default-fontify-region never ends. What do you intend to do about this? Anything? -- Alan Mackenzie (Nuremberg, Germany).