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: emacs master + org Wrong type argument: number-or-marker-p Date: Thu, 4 Aug 2022 10:18:21 +0000 Message-ID: References: <87edxyc5ds.fsf@yahoo.com> <83iln95yd7.fsf@gnu.org> <83o7x04kul.fsf@gnu.org> <87tu6sa5uf.fsf@yahoo.com> <83czdg4h7p.fsf@gnu.org> <87k07oa2ie.fsf@yahoo.com> <837d3o4eyn.fsf@gnu.org> <87v8r88kna.fsf@yahoo.com> <831qtw4btm.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="1554"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , monnier@iro.umontreal.ca, gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 12:27:07 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 1oJY4I-0000F8-Sg for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 12:27:06 +0200 Original-Received: from localhost ([::1]:60484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJY3z-0002ly-8V for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 06:26:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJXwB-0004VX-Fz for emacs-devel@gnu.org; Thu, 04 Aug 2022 06:18:48 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:22845 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oJXw9-0004sv-8v for emacs-devel@gnu.org; Thu, 04 Aug 2022 06:18:43 -0400 Original-Received: (qmail 42438 invoked by uid 3782); 4 Aug 2022 10:18:25 -0000 Original-Received: from acm.muc.de (p4fe15d23.dip0.t-ipconnect.de [79.225.93.35]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 04 Aug 2022 12:18:25 +0200 Original-Received: (qmail 7317 invoked by uid 1000); 4 Aug 2022 10:18:21 -0000 Content-Disposition: inline In-Reply-To: <831qtw4btm.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:293049 Archived-At: Hello, Eli. On Thu, Aug 04, 2022 at 12:06:45 +0300, Eli Zaretskii wrote: > > From: Po Lu > > Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, > > mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, > > emacs-devel@gnu.org > > Date: Thu, 04 Aug 2022 16:42:33 +0800 > > Eli Zaretskii writes: > > And what if someone wants to write a fontification function whose > > results depend, for example, on a single character at a known position > > outside of the accessible region? That cannot result in a freeze > I cannot reason about something as abstract and theoretical. CC Mode is such a mode, though it depends on more than just a single character outside the accessible region. [ .... ] > > I'm just trying to demonstrate what will happen once the forced > > narrowing starts to interfere with the operation of various pieces of > > third party code, which might possibly be discovered some time after > > Emacs 29 is released. Long-running fontification was not a > > significant source of complaints for their developers in the past, > > and things are likely to remain that way. > Users did and do complain about locked-up Emacs when they try to edit > files with long lines. They just didn't realize one of the reasons > was font-lock (or syntax-ppss), so they didn't complain specifically > about that. But every complaint you see about these situations is > basically a complaint about font-lock and its syntax-parsing parts. Has anybody asked the question why is font-lock so slow on these long lines? The answer is surely not the use of widen and narrow-to-region. A piece of text takes exactly as long to fontify when its buffer is narrowed as when it is not. I think (though I have not analysed it any further) the cause of this slowness is font-lock fontifying from BOL to EOL. That's an awful lot of fontification if we have long lines. If this is the case, a better solution to the problem would be to restrict the font-locked region to, say, the visible line. Or to the window. Or something like that. The current "solution" breaks things, because it doesn't fix what is broken and fixes what isn't broken. In particular, it breaks CC Mode when there are long lines in a buffer. > Anyway, this discussion doesn't lead anywhere. We have decided to try > this way of solving a long-standing problem in Emacs, and no amount of > talking will cause us to change that decision. Only code that makes > font-lock and syntax.c significantly faster, and/or reports about > specific issues (as opposed to general semi-philosophical concerns) > caused by these changes, can affect both the implementation of these > changes and our future decisions about its defaults. I don't want to be provocative, but having opcodes that only work most of the time rather than all of the time isn't a mere semi-philosophical concern. -- Alan Mackenzie (Nuremberg, Germany).