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 19:37:42 +0300 Message-ID: <83edxw2cdl.fsf@gnu.org> References: <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> <83mtck2llb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20974"; 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 18:40:10 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 1oJdtJ-0005JR-81 for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 18:40:09 +0200 Original-Received: from localhost ([::1]:40968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJdtI-0007wF-Ap for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 12:40:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJdr2-0005CM-DQ for emacs-devel@gnu.org; Thu, 04 Aug 2022 12:37:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45316) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJdr0-0001uj-GF; Thu, 04 Aug 2022 12:37:46 -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=TV7Zj9SKFlNzCwCuMw05JdMCofvPgnUHdR7yOK7DOXk=; b=esLoSJigY7dL uygpkLtGihWxPJ4KUzgdma7VwzL0SgYTbbO1p5PamU3/mM1oTMN00P+PVR68Nox16ZjNvwLAmuGug 6l2fEA5eZSr2pUW3j0Dos9i7raNvplHtEUUlYKWGyxNDkfD9GIFUxl0SV4lZ7U7F/VURqkejiy9Uy wdKL9Y0ImFu54nQ3a3PX+23/MfHQ1SGjBLc5MAPDEKqL5aS/ympnnKqc3eneqfxcUCj/zgAfTkU2x 6iMgaRxWW7DAtOhD5KCEnf0yPndXiUD8k+MK2roV/pSK8rTNvNwpACHeSm5pQe/Ong7pzVplRqKV/ qDPE1DEll8Yst7jnagAPyg==; Original-Received: from [87.69.77.57] (port=1949 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 1oJdqz-0005jv-Ti; Thu, 04 Aug 2022 12:37:46 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 4 Aug 2022 16:07:48 +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:293077 Archived-At: > Date: Thu, 4 Aug 2022 16:07:48 +0000 > Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, gregory@heytings.org, > mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, > emacs-devel@gnu.org > From: Alan Mackenzie > > > 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? > > That you can speed things up by omitting part of the work. Possibly that > font-lock is insufficiently flexible in what it offers major modes. And how would you propose to solve that, given that it remains unsolved for at least two decades? > I meant doing this in a way which doesn't introduce bugs. Something like > amending/replacing font-lock-extend-region-wholelines, for example. Feel free to work on this. If the results are better, we will certainly prefer using it, and will then have to revisit the changes we are discussing here, and decide whether they are still needed. But we are not there yet, and it sounds wrong to me to prevent our users from having a usable Emacs when editing these files just because our ideal solutions are not yet available, when less ideal solutions yield satisfactory results. > > No, the current solution sacrifices some of the font-lock correctness > > .... > > "Sacrificing correctness" sounds like a euphemism for tolerating bugs. Minor bugs. Very minor bugs. > > .... to give us a usable Emacs. I say it's a justified tradeoff. > > Better would be to get a usable Emacs without introducing bugs. Yes, we all love cheap and perfect solutions, don't we? But there are no such solutions in this case, so we need to choose among not-so-cheap and not-so-perfect ones instead. > Now it's being sacrificed, even if only in an edge case, with barely > a second thought - along with an unknown number of other packages. That's unfair, to say the least. A lot of thought and discussions went into these changes, even if you didn't notice them. To say nothing about the development and testing efforts. > > > 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. > > They don't work all the time, since sometimes there are long lines. That's the same thing. You just see the empty 1/100th of the glass. > > When there are long lines, they work slightly less correctly, .... > > Correctness doesn't admit of degrees. Something is either correct, or > it's incorrect. Then CC Mode is incorrect and broken, because it at times produces wrong fontification and wrong indentation. Let's throw it out. > `widen' doesn't work at all in the pertinent circumstances. Then make your mode avoid widening in those circumstances. > > .... and the lack of correctness is only visible in the fontifications. > > That hasn't been shown. Show us any other problems, and then let's talk. > Arbitrary Lisp can be executed through fontification-functions and > all the hooks in font-lock.el and jit-lock.el. Arbitrary Lisp can still be executed, it should just avoid going far away from the window's display area when the buffer has very long lines. In particular, it should not begin from the beginning of a line, nor insist on examining the entire line from BOL to EOL. > > 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). > > Do these long lines occur in modes where fontification is important? I > don't know as I haven't seen any test files. The Emacs project decided long ago that fontifications are important in all modes. That's why we have font-lock turned on by default; it wasn't like that once upon a time. But if you or someone prefers no fontifications to fontifications that are sometimes, rarely, incorrect, you can always turn off font-lock; the changes we are discussing didn't take away that possibility.