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: Wed, 03 Aug 2022 14:50:35 +0300 Message-ID: <83mtcl5ywk.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33426"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Wed Aug 03 13:53:51 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 1oJCwf-0008R7-Ei for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 13:53:49 +0200 Original-Received: from localhost ([::1]:50170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJCwe-0007J3-Fd for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 07:53:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJCtl-00069U-5P for emacs-devel@gnu.org; Wed, 03 Aug 2022 07:50:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40924) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJCtj-00066y-Aw; Wed, 03 Aug 2022 07:50:47 -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=MlUUZC7M1S5SH05yi7YrFum3nHMKXSElp051zEiI4mE=; b=QrnyCgJPTmVl kgFyhOJJuTTNdd1Aa7PeWdr5xluTTDECxeLs6FMLYmLvK1gS3511HIYnwB2gYY0FP2coYJdXwujPN 2Y3CXRUFKvfmtMIvEApHaudLCBgJz8cfPigJWJaSwohNhlyGrk8HmTzPbVrHwrmeUYENrtamcsPBm w3QDIyCgo2NdaGNFHc7UDpiyoWZjDFJ8cFXVZD25j+3DhIEB6i90EePt0JNvLrzs2v3u+hLgUffA2 x5jPAogFZfYd/cAfvaugOBbJUkxWAvmfwqSh+hCwlB3mXJd11KrES15p3FPGCRx9uEkssLiI8IYyI tFJXt7gG6nHshgph/aCc/A==; Original-Received: from [87.69.77.57] (port=3120 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 1oJCte-0004P1-VI; Wed, 03 Aug 2022 07:50:47 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 2 Aug 2022 20:28:42 +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:293012 Archived-At: > Date: Tue, 2 Aug 2022 20:28:42 +0000 > Cc: gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, > silent2600@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > > Not any Lisp programs, only those invoked from those hooks. > > > And they won't necessarily fail. > > No, they'll continue in a state different from that conceived by their > creator. Not necessarily. Only if previously they forcefully widened the buffer and looked beyond the restriction. > Is that not a failure? See above: not necessarily. > > > There is not even a return code to say that a byte-code instruction > > > has failed to work. > > > A program can always test point-min and point-max. > > A rigorous program MUST now test these. Only if it MUST misbehave. > > > Surely there should be an error signalled if such happens, since the > > > program is broken after ignoring an instruction. > > > It isn't broken, though. > > I disagree fundamentally. CC Mode, for example, uses widen and > narrow-to-region all over the place, and surely other modes will too. > When the opcodes break, so will these modes. CC Mode is extremely unlikely to be in effect in files with such long lines. So you, as the CC Mode developer, can relax: these changes are not relevant to CC Mode. > > we don't let such programs run amok high and low in these extra-long > > lines. > > Using widen and narrow-to-region is hardly running amok. It is, if the Lisp program then goes on to examine all the characters from BOB to point. It also is if the Lisp program insists to start from the beginning of the line, no matter how far back that is. > > > I protest also that this wasn't discussed openly on emacs-devel. > > > It is being discussed, here and on the bug tracker, for about a month > > now. > > That's a month in which the discussion was open only to somebody who > reads every post in the bug list, such as yourself, or who came upon the > discussion by chance. Others, such as me, were unaware of it. It looks > like the decision to change the byte code interpreter has already been > taken, and I had no chance to participate in that process. The byte code interpreter was yesterday changed back, so there's no change there. > Is it really right that fundamental changes to Emacs get discussed only > on the bug list, or in secret[*] on emacs-devel? [*]I.e. when the > subject line is not explicit. The Subject lines are not always explicit enough, that is true, but there's nothing here specific to the discussion at hand, as it happens all the time here. And yes, if you don't want to miss important changes, you need wither (a) read everything on the lists, or (b) track the committed changes (e.g., via emacs-diffs@gnu.org), or both. I see no way around that, unless someone volunteers to set up some kind of notification service.