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.devel Subject: Re: emacs master + org Wrong type argument: number-or-marker-p Date: Thu, 04 Aug 2022 16:18:40 +0300 Message-ID: <83mtck2llb.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20021"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 15:22:37 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 1oJao8-00050g-Ac for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 15:22:36 +0200 Original-Received: from localhost ([::1]:58936 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJao7-00072W-8x for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 09:22:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJakP-0003le-Tv for emacs-devel@gnu.org; Thu, 04 Aug 2022 09:18:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40454) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJakO-0002cC-Uw; Thu, 04 Aug 2022 09:18:44 -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=Q8UtbuH5T5xqz4L4xBM3sT5nECd70t5SFhortjz5o1w=; b=TEYCERb8c7/R AY00M+zzvLLqiazYy/p2B+7LTBatBmKBCyNpFwIlVORVWbZDJdExXj7aFuhHQ5ELTLB+3FkKaep2j 38wNdVwaZTQfwfXP2LP3iwArks0C4/W/XQi3EtQYDpGMVuaIxZ90i7YNizN5tDDGUNipoikocPIQX yws6uC7WRuwC0Fv6TzppcWy4bLhRJ+cI9f7UHX4dt3lGFE7LnWr3gA1nfeZozy0rczYquOyAsTkjd o7MI5HPyceMRglI7pCLbHjZnqdzXearLVAYNS9uYDKEaOt/4rV4NaJfPI4SQ3eJVmCWkwC1LQH3W+ vLmflntrxEBK4h4Fjy+7CA==; Original-Received: from [87.69.77.57] (port=1551 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 1oJakO-0004XW-Em; Thu, 04 Aug 2022 09:18:44 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 4 Aug 2022 10:18:21 +0000) 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:293061 Archived-At: > Date: Thu, 4 Aug 2022 10:18:21 +0000 > Cc: Po Lu , monnier@iro.umontreal.ca, > gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, > silent2600@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > > > 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. And what catastrophic results does the current master produce with CC Mode, when you edit files with very long lines, due to this narrowing? > > 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. Of course. But the problem is that font-lock was found to examine much larger portions of the buffer than the ones to which we now restrict it in those cases. And the speedup is evident. What does that tell you? > 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. That's what we do: we restrict it to somewhat more than fits in the window. But the files in questions have lines that are much longer than 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. No, the current solution sacrifices some of the font-lock correctness to give us a usable Emacs. I say it's a justified tradeoff. > > 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. They work all the time when there are no long lines. When there are long lines, they work slightly less correctly, and the lack of correctness is only visible in the fontifications. Hardly a disaster, if you keep in mind that one of the previously recommended solutions was to turn on so-long-mode, which turns off font-lock (to tell nothing of the not-so-distant past, when Emacs didn't have font-lock at all). IOW, it's a tradeoff: we give up some of the font-lock correctness, and in return gain a usable Emacs.