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: Mon, 1 Aug 2022 20:05:44 +0000 Message-ID: References: <8335eg2ao9.fsf@gnu.org> <875yjbexde.fsf@posteo.net> <83zggn2a0c.fsf@gnu.org> <03AF0800-5252-429C-86BC-85DF9DF449F9@acm.org> <83tu6v27yh.fsf@gnu.org> <6F871C02-AC26-4B89-B64B-E9F4ACACDBE7@acm.org> <83sfmf26b6.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="7246"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= , Eli Zaretskii , philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 01 22:07:05 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 1oIbgv-0001fS-7a for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Aug 2022 22:07:05 +0200 Original-Received: from localhost ([::1]:51878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIbgt-0007CA-GA for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Aug 2022 16:07:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43804) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIbfj-0006Vy-QL for emacs-devel@gnu.org; Mon, 01 Aug 2022 16:05:51 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:37510 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oIbfg-0006en-Vm for emacs-devel@gnu.org; Mon, 01 Aug 2022 16:05:51 -0400 Original-Received: (qmail 21942 invoked by uid 3782); 1 Aug 2022 20:05:46 -0000 Original-Received: from acm.muc.de (p4fe15d10.dip0.t-ipconnect.de [79.225.93.16]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 01 Aug 2022 22:05:45 +0200 Original-Received: (qmail 7863 invoked by uid 1000); 1 Aug 2022 20:05:44 -0000 Content-Disposition: inline In-Reply-To: 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=ham 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:292965 Archived-At: On Mon, Aug 01, 2022 at 19:16:44 +0000, Gregory Heytings wrote: > > No, functions must be balanced with respect to the specbind stack. The > > bytecode machinery assumes this to be the case. > Thanks for the clarification, I'll keep that in mind in the future. > > So please revert all changes relating to the new narrow-to-region > > argument and submit a new patch. It's better than somehow trying to > > patch up the current unworkable approach. > That won't be necessary, it was actually easy to fix. Now done on master, > and we are back to the statu quo ante with respect to byte compilation. > Of course another 'make boostrap' is necessary. I see in commit 9d8a6c82838f2f24e76a67379b02956aa668d7cf Author: Gregory Heytings Date: Mon Aug 1 19:11:01 2022 +0000 the following text: +Note that, in rare circumstances, Emacs may decide to leave, for +performance reasons, the accessible portion of the buffer unchanged +after a call to @code{narrow-to-region}. You cannot do this. narrow-to-region and widen aren't nice-to-have optional extras, they are essential parts of program functionality. If you stop them working properly, programs will break. It is a bit like the Lisp machine randomly failing to perform some car operations. If you must do something like this, why don't you throw an error when an "invalid" narrow-to-region or widen is attempted? This would at least allow the programmer to do some debugging. Would it also be possible to add in some commentry motivating this unusual action? All I can see from looking at the source (xdisp.c) is that it probably has something to do with long lines. -- Alan Mackenzie (Nuremberg, Germany).