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 08:51:46 +0300 Message-ID: <83o7x04kul.fsf@gnu.org> References: <83tu6v27yh.fsf@gnu.org> <6F871C02-AC26-4B89-B64B-E9F4ACACDBE7@acm.org> <83sfmf26b6.fsf@gnu.org> <835yja7o7j.fsf@gnu.org> <83v8ra5uee.fsf@gnu.org> <87wnbqcebn.fsf@yahoo.com> <83o7x259wg.fsf@gnu.org> <87edxyc5ds.fsf@yahoo.com> <83iln95yd7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, acm@muc.de, gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 07:56:33 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 1oJTqS-00030y-5h for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 07:56:32 +0200 Original-Received: from localhost ([::1]:44844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJTqQ-0005sW-U4 for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 01:56:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJTm0-0004Bt-5o for emacs-devel@gnu.org; Thu, 04 Aug 2022 01:51:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34530) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJTlw-0005f9-8V; Thu, 04 Aug 2022 01:51:53 -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=6hOmuU5uF3Sfq5egpd7F6QiBwr/+Xh7d6x4v9GVA5g0=; b=MI92S5vBkU61 BzJ4Nyds9VWJMtWY6bPiSeZgksGT3h45YPdnYcXXyIPwJPla63ifSeVvNxavSA12eRlTZc4gJUdo3 JziyJMKljfO6ItPora4/0PYOot/gyRSs+tqsU+4etTghN0FHYPsW9lTx2WU2MxOlarhheh+dZKPxn A7OXFW6A5PfKw7P/tqHAAvQnsk07/EyjRlq6agLb9GvnPpMFl6NP2ug3Qg17iDMdnuApeB0AoMNox GYoNTH3X/TetOLdCF7uObhTupOHKJn+zWosUV/2a6OfkcoM2kZ0/iMPb4pfWz0T8EuKyurNgF9U4J RFxk+XJBB3XcR6lNvVkyDA==; Original-Received: from [87.69.77.57] (port=1908 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 1oJTlv-0006pu-Go; Thu, 04 Aug 2022 01:51:52 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 03 Aug 2022 16:47:17 -0400) 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:293040 Archived-At: > From: Stefan Monnier > Cc: Po Lu , acm@muc.de, gregory@heytings.org, > mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, > emacs-devel@gnu.org > Date: Wed, 03 Aug 2022 16:47:17 -0400 > > >> Then wouldn't it be better to fix the font-locking code to not widen > >> outside bounds explictly specified by redisplay, instead of making > >> `widen' and `narrow-to-region' in effect inoperable in those > >> circumstances? > > How would that work in practice? Font-locking code uses functions and > > regexps provided by the major modes, so it cannot by itself prevent > > widening. > > I don't understand what you're talking about. > > AFAIK in 99% of the cases, font-lock.el itself widens, then uses the > regexps (which can't widen) and the functions provided by the major mode > almost none of which (with rare exceptions, of course, most of them > historical) will widen since font-lock already did it for them (and > since widening will lead to bugs when used within something like > mmm-mode or mhtml-mode). What will we do with the "rare" exceptions, such as CC Mode, for example? And what will we do with (I expect) the much larger group which becomes broken when font-lock stops widening, and their assumptions about being always able to access any buffer position become false? IOW, I'd love to see the brave new world where font-lock doesn't widen and none of the major modes we care about do, and fontifications still work reasonably well. Then we can revisit the strategy of handling long lines, and perhaps change the defaults as result. But for now, this is purely academic, with too many "ifs" and "whens" and too little actual development in that direction.