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 10:10:18 +0300 Message-ID: <83czdg4h7p.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> <83o7x04kul.fsf@gnu.org> <87tu6sa5uf.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14428"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 09:12:26 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 1oJV1u-0003Zw-JU for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 09:12:26 +0200 Original-Received: from localhost ([::1]:35662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJV1t-0007do-H1 for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 03:12:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJUzy-0006J7-HR for emacs-devel@gnu.org; Thu, 04 Aug 2022 03:10:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJUzv-0000UN-TW; Thu, 04 Aug 2022 03:10:24 -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=SLkSNdDbwWCqNma8QKuRnB8acIu+NyAdkS25zZuQNwY=; b=S8eASN0vRstV dh9Dz/qMPOAC90tywIQElpM1ELHyhtsDnCDs1uAQYiuxaDYn4JvrMrr54eLsl2xyQN8TUVe8c/Vd9 p8ftJA9Y7fdjA6BvuVUuXTB0/HeV85bExqo8fKlweQ8PHuFM/m808TSqsOPF4swLXE3x4jx2I/bLE CEyMh5givyk94cS46jk/YjdDN3tpw5zIodfS/y5v4UPXKRQja+YxzU1U0mM1a2UAGL+mf9hQCJTnY K5yRyQdTSN/H+ssejlJoHzCzuSdJbsA5EDpTtLuujsEX/o5sdGtN49PGvqAwKRJriWW1WsSS3ORkv MsHToxL9LlC3f7Iyku9tyQ==; Original-Received: from [87.69.77.57] (port=2719 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 1oJUzv-0003w7-0u; Thu, 04 Aug 2022 03:10:23 -0400 In-Reply-To: <87tu6sa5uf.fsf@yahoo.com> (message from Po Lu on Thu, 04 Aug 2022 14:19:20 +0800) 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:293043 Archived-At: > From: Po Lu > Cc: Stefan Monnier , acm@muc.de, > gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, > silent2600@gmail.com, emacs-devel@gnu.org > Date: Thu, 04 Aug 2022 14:19:20 +0800 > > Eli Zaretskii writes: > > > What will we do with the "rare" exceptions, such as CC Mode, for > > example? > > Fix them, individually? Fine by me. People are encouraged to work on that ASAP. But we'd like to have a reasonably performant Emacs 29 when editing long lines without waiting for that pipe dream to come true. If and when it does come true, we can reset the long-line-threshold to nil by default, even if it happens before Emacs 29 is released. > > 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? > > We don't have make font lock avoid widening -- what I was proposing was > to ensure that font lock, CC Mode, and any other exceptions that might > come up only widen to the "locked" restriction, without changing the > behavior of narrow-to-region and friends. We don't know how to do that, as was already explained and demonstrated here. Modes do what they want, and in some cases we have hard time even convincing the mode developers that they should try to avoid doing that.