From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs master + org Wrong type argument: number-or-marker-p Date: Tue, 2 Aug 2022 20:28:42 +0000 Message-ID: References: <83tu6v27yh.fsf@gnu.org> <6F871C02-AC26-4B89-B64B-E9F4ACACDBE7@acm.org> <83sfmf26b6.fsf@gnu.org> <835yja7o7j.fsf@gnu.org> <83v8ra5uee.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32823"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 02 22:29:50 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 1oIyWU-0008OH-Qp for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Aug 2022 22:29:50 +0200 Original-Received: from localhost ([::1]:36814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIyWT-0007gN-RX for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Aug 2022 16:29:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIyVU-0006aD-4Y for emacs-devel@gnu.org; Tue, 02 Aug 2022 16:28:48 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:19285 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oIyVS-0007fH-0C for emacs-devel@gnu.org; Tue, 02 Aug 2022 16:28:47 -0400 Original-Received: (qmail 50986 invoked by uid 3782); 2 Aug 2022 20:28:43 -0000 Original-Received: from acm.muc.de (p4fe15cce.dip0.t-ipconnect.de [79.225.92.206]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Aug 2022 22:28:42 +0200 Original-Received: (qmail 18615 invoked by uid 1000); 2 Aug 2022 20:28:42 -0000 Content-Disposition: inline In-Reply-To: <83v8ra5uee.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:292997 Archived-At: Hello, Eli. On Tue, Aug 02, 2022 at 22:15:37 +0300, Eli Zaretskii wrote: > > Date: Tue, 2 Aug 2022 18:59:07 +0000 > > Cc: gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, > > silent2600@gmail.com, emacs-devel@gnu.org > > From: Alan Mackenzie > > > This happens only in buffers with very long lines, where we want to > > > prevent Lisp programs called from low-level facilities, like > > > redisplay, to scan the entire buffer. > > So Lisp programs will "only" fail to work in buffers with long lines. I > > protest at this. > 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. Is that not a failure? > In fact, we have yet to see a single serious failure due to these > measures. In general, the restriction is large enough to satisfy any > reasonable processing, so it shouldn't matter unless the Lisp program > misbehaves. > > There surely could have been a solution to whatever > > the problem was that respected the integrity of the Lisp machine. > Theoretically, yes. But in practice, Emacs had this problem since 22 > years ago, and no solution presented itself. > > 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. This is such a horrible artifact that it won't get done most of the time. > > 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. > > Ignoring what a programmer programmed cannot be a good strategy. > It isn't ignored, just restricted: There are no safety fences of any sort. The meaning of a program using w and n-t-r is no longer determinate. > 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. > > 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. 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. Anyhow, I wanted to protest and I have done so. The arguments between the two of us here about widen and n-t-r are clearly not going anywhere, so I don't intend to continue them. I won't feel put out if you don't want to answer them. -- Alan Mackenzie (Nuremberg, Germany).