From unknown Mon Jun 16 23:47:18 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#48100 <48100@debbugs.gnu.org> To: bug#48100 <48100@debbugs.gnu.org> Subject: Status: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Reply-To: bug#48100 <48100@debbugs.gnu.org> Date: Tue, 17 Jun 2025 06:47:18 +0000 retitle 48100 28.0.50; inserting too many lines into a fresh cpp file break= s the buffer reassign 48100 emacs submitter 48100 Paul Nelson severity 48100 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 29 09:23:59 2021 Received: (at submit) by debbugs.gnu.org; 29 Apr 2021 13:23:59 +0000 Received: from localhost ([127.0.0.1]:55114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc6e6-0006Xr-Ot for submit@debbugs.gnu.org; Thu, 29 Apr 2021 09:23:59 -0400 Received: from lists.gnu.org ([209.51.188.17]:49996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc1fJ-0004Vs-RB for submit@debbugs.gnu.org; Thu, 29 Apr 2021 04:04:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45392) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lc1fJ-0002WE-Lb for bug-gnu-emacs@gnu.org; Thu, 29 Apr 2021 04:04:53 -0400 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]:41881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lc1fG-0001Hf-OD for bug-gnu-emacs@gnu.org; Thu, 29 Apr 2021 04:04:53 -0400 Received: by mail-pf1-x436.google.com with SMTP id v191so3756386pfc.8 for ; Thu, 29 Apr 2021 01:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=D/MqEazEXlJnxMd+QJNXvbC3+W8+jyjm+U9TJEKelvA=; b=DTPOehvhOGrNdW+x/VHfF82VFdifN3aXAjRlqL4KCpp8R53Z/K9d6n675IfeW5lqPI chbF2AHq11lgK8yMClilHYA4ATt/k4oSduAWVwfblpH0SEsX6nsLkSezZlrVK/36hrBP MdhAYyZMgoexbztFVdYKkUbh+b2+GBfuSK9gjaEMX9G9dR774/nz6LKIIjKeenMCCFxE Ps90y5lI+GZ/D5VgDpU6MN/c0C2AbVQSV/p8UZJTA6TEylxKxOshPKUCOlxjNS4nWwGJ v/qrAZ5W650scPkDXn4/rljrvHs1SPgOFN34zHQm7Gosbqngrta5mjip1MmkAOx+B+uZ P40w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D/MqEazEXlJnxMd+QJNXvbC3+W8+jyjm+U9TJEKelvA=; b=BJUpgEpu+GQ1pBpOR2K1Js2chliQSB8r4aa65DAspqQL3D8M4voBQQzzGjqR+Tz6QJ 8cn1TRIOZ9ujgBpphjzCLuEtUmjwQfoCYOUBw9shCkXcCmv3yKjreCizHf2orWQpRfOt hx2yAfOYO1RlFdKyD7WxzdUjA8+viv81Ef6te/DPHfQ2uD0V5EGflHwqWJuVLY+leXO3 9/dCdtGvR76/jUEe/fgX2N6HJ826MT0VnTfRL07+fIHK7d/OIX0Jlpdd8AuzpgyX+lvl 661vPcUrw6pud9LwOle3/GcLsZPFZ4eDnfFHPKts9cbCEJcQT1CRcflyT1Cqne9LW9xB MiTg== X-Gm-Message-State: AOAM532Gxi7WD86yEuYFdq7RIQfiBa+12cBNgdVEQf7X99KjSTYttWZy OBxQpCijvG8xxpYsHGj6nhqFUYjKBFc6opSwHIfNJkV21JQ= X-Google-Smtp-Source: ABdhPJxBc4lDRJgCulHFSVJQGxWFnr/Vkpo7a9jY/u1r+qYKTte6SgWnpLMmq0Yj3SilDk6E4+ursV3Aiz0peuFlEKA= X-Received: by 2002:a65:4d49:: with SMTP id j9mr30333598pgt.113.1619683487347; Thu, 29 Apr 2021 01:04:47 -0700 (PDT) MIME-Version: 1.0 From: Paul Nelson Date: Thu, 29 Apr 2021 10:04:36 +0200 Message-ID: Subject: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000e9782c05c117f205" Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=ultrono@gmail.com; helo=mail-pf1-x436.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 29 Apr 2021 09:23:58 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000e9782c05c117f205 Content-Type: text/plain; charset="UTF-8" Inserting a sufficiently large chunk of text into a fresh cpp file breaks syntax highlighting and causes the buffer to enter a semi-permanent broken state. Moreover, the offending function "c-guess-basic-syntax" seems to break edebug instrumentation. In more detail: Start from emacs -Q. Insert sufficiently many lines of C++ code in a temporary buffer. A slightly contrived example: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include Copy these lines to the kill ring. Create a new file "test.cpp", and paste what was copied. The first error is that syntax highlighting stops after a certain number of lines (in the above example, just before the final line). The same problem arises if such lines are inserted via abbrev-mode. This is the intended use case. No problem if such lines are copy/pasted in small enough chunks. The problem *appears* to go away if one cuts and then pastes the offending lines, but the buffer remains in a broken state. For instance, attempting to insert a couple newlines followed by int main( gives the following error: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) c-guess-basic-syntax() c-indent-line() indent-according-to-mode() c-electric-paren(nil) funcall-interactively(c-electric-paren nil) command-execute(c-electric-paren) Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a long and complicated backtrace that starts with: Debugger entered--Lisp error: (invalid-read-syntax "Expected" "lambda") edebug-syntax-error("Expected" "lambda") --- In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H524)) of 2021-04-26 built on Pauls-MBP-2 Repository revision: 9d34fd8b33c55768190d41239931120e3fc9717f Repository branch: master Windowing system distributor 'Apple', version 10.3.1894 System Description: Mac OS X 10.15.7 Configured using: 'configure --with-native-compilation' Configured features: ACL DBUS GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB Important settings: value of $LC_CTYPE: UTF-8 value of $LANG: en_CH.UTF-8 locale-coding-system: utf-8-unix Major mode: C++//l Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs password-cache json map text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils novice comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv bytecomp byte-compile cconv cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind kqueue cocoa ns lcms2 multi-tty make-network-process nativecomp emacs) Memory information: ((conses 16 126796 8572) (symbols 48 11546 0) (strings 32 31421 1656) (string-bytes 1 1165707) (vectors 16 18464) (vector-slots 8 333103 10770) (floats 8 30 33) (intervals 56 540 0) (buffers 992 14)) --000000000000e9782c05c117f205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inserting a sufficiently large chunk of text into a fresh = cpp file
breaks syntax highlighting and causes the buffer to enter a
= semi-permanent broken state.=C2=A0 Moreover, the offending function
&qu= ot;c-guess-basic-syntax" seems to break edebug instrumentation.
<= div>
In more detail:

Start from emacs -Q.=C2=A0 Insert= sufficiently many lines of C++ code in a
temporary buffer.=C2=A0 A slig= htly contrived example:

#include <cstdio>
#include <cstd= lib>
#include <cstring>
#include <climits>
#include= <cfloat>
#include <vector>
#include <cmath>
#in= clude <set>
#include <list>
#include <map>
#incl= ude <stack>
#include <queue>
#include <iostream>#include <sstream>
#include <fstream>
#include <algor= ithm>
#include <numeric>
#include <functional>
#inc= lude <cstdio>
#include <cstdlib>
#include <cstring>=
#include <climits>
#include <cfloat>
#include <vec= tor>
#include <cmath>
#include <set>
#include <l= ist>
#include <map>
#include <stack>

Copy these= lines to the kill ring.=C2=A0 Create a new file "test.cpp", and<= br>paste what was copied.

The first error is that = syntax highlighting stops after a certain
number of lines (in the above = example, just before the final line).

The same problem arises if suc= h lines are inserted via abbrev-mode.
This is the intended use case.
=
No problem if such lines are copy/pasted in small enough chunks.
The problem *appears* to go away if one cuts and then pastes the
offend= ing lines, but the buffer remains in a broken state.=C2=A0 For
instance,= attempting to insert a couple newlines followed by
=C2=A0 int ma= in(
gives the following error:

Debugger entered--Lisp error: (wro= ng-type-argument number-or-marker-p nil)
=C2=A0 c-guess-basic-syntax()=C2=A0 c-indent-line()
=C2=A0 indent-according-to-mode()
=C2=A0 c-e= lectric-paren(nil)
=C2=A0 funcall-interactively(c-electric-paren nil)=C2=A0 command-execute(c-electric-paren)

Incidentally, "C-u C-= M-x" applied to c-guess-basic-syntax gives a long and complicated back= trace that starts with:

Debugger entered--Lisp error: (invalid-read-= syntax "Expected" "lambda")
=C2=A0 edebug-syntax-err= or("Expected" "lambda")

---


In GNU Em= acs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version = 10.15.7 (Build 19H524))
=C2=A0of 2021-04-26 built on Pauls-MBP-2
Repo= sitory revision: 9d34fd8b33c55768190d41239931120e3fc9717f
Repository bra= nch: master
Windowing system distributor 'Apple', version 10.3.1= 894
System Description: =C2=A0Mac OS X 10.15.7

Configured using:<= br>=C2=A0'configure --with-native-compilation'

Configured fe= atures:
ACL DBUS GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIF= Y KQUEUE
NS PDUMPER PNG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB
Important settings:
=C2=A0 value of $LC_CTYPE: UTF-8
=C2=A0 value of= $LANG: en_CH.UTF-8
=C2=A0 locale-coding-system: utf-8-unix

Major= mode: C++//l

Minor modes in effect:
=C2=A0 tooltip-mode: t
= =C2=A0 global-eldoc-mode: t
=C2=A0 electric-indent-mode: t
=C2=A0 mou= se-wheel-mode: t
=C2=A0 tool-bar-mode: t
=C2=A0 menu-bar-mode: t
= =C2=A0 file-name-shadow-mode: t
=C2=A0 global-font-lock-mode: t
=C2= =A0 font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composi= tion-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-m= ode: t
=C2=A0 line-number-mode: t
=C2=A0 transient-mark-mode: t
= =C2=A0 abbrev-mode: t

Load-path shadows:
None found.

Featu= res:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loadde= fs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmai= l-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache js= on map text-property-search time-date mm-decode
mm-bodies mm-encode mail= -parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 = ietf-drums mm-util mail-prsvr mail-utils novice
comp comp-cstr warnings = subr-x rx cl-seq cl-macs cl-extra help-mode seq
byte-opt gv bytecomp byt= e-compile cconv cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-= align cc-engine cc-vars cc-defs
cl-loaddefs cl-lib iso-transl tooltip el= doc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns= -win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset= image regexp-opt fringe
tabulated-list replace newcomment text-mode eli= sp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow i= search easymenu
timer select scroll-bar mouse jit-lock font-lock syntax = font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-= 8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eu= cjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indi= an
cyrillic chinese composite charscript charprop case-table epa-hookjka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
lo= addefs faces cus-face macroexp files window text-properties overlay
sha1= md5 base64 format env code-pages mule custom widget
hashtable-print-rea= dable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-ne= twork-process nativecomp emacs)

Memory information:
((conses 16 1= 26796 8572)
=C2=A0(symbols 48 11546 0)
=C2=A0(strings 32 31421 1656)<= br>=C2=A0(string-bytes 1 1165707)
=C2=A0(vectors 16 18464)
=C2=A0(vec= tor-slots 8 333103 10770)
=C2=A0(floats 8 30 33)
=C2=A0(intervals 56 = 540 0)
=C2=A0(buffers 992 14))
--000000000000e9782c05c117f205-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 03:58:37 2021 Received: (at 48100) by debbugs.gnu.org; 2 May 2021 07:58:38 +0000 Received: from localhost ([127.0.0.1]:41311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld6zt-0003e3-Mi for submit@debbugs.gnu.org; Sun, 02 May 2021 03:58:37 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld6zr-0003dw-BF for 48100@debbugs.gnu.org; Sun, 02 May 2021 03:58:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BVfu/ceNjT/qGUf65IG5QaHfYPN82ZMM8tZuBfTZ+J8=; b=sh6Ju8s4KOZqVuUCDCxS/08xMm 3+sJ30lDVFFLroD+mXnfyVFYNxrZ/Km4bdUMWoOmgh5rqYOVP6hQBm1chOhAd2pxcDQKHWxk183S9 lgD/3U2gXtpzy1s22Idz68ZSOEubr0GvT8M/oizBYu/YCLSeEFtswLanu96RjdBJyqc0=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ld6zi-00046X-VH; Sun, 02 May 2021 09:58:29 +0200 From: Lars Ingebrigtsen To: Paul Nelson Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer References: X-Now-Playing: Zola Jesus's _New Amsterdam_: "XXX" Date: Sun, 02 May 2021 09:58:26 +0200 In-Reply-To: (Paul Nelson's message of "Thu, 29 Apr 2021 10:04:36 +0200") Message-ID: <874kflk1nh.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Nelson writes: > Start from emacs -Q. Insert sufficiently many lines of C++ code in a > temporary buffer. A slightly contrived example: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: Alan Mackenzie , 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Paul Nelson writes: > Start from emacs -Q. Insert sufficiently many lines of C++ code in a > temporary buffer. A slightly contrived example: [...] > Copy these lines to the kill ring. Create a new file "test.cpp", and > paste what was copied. > > The first error is that syntax highlighting stops after a certain > number of lines (in the above example, just before the final line). I tried this in Emacs 28, and I could not reproduce the reported behaviour -- this works fine for me. > Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a long and > complicated backtrace that starts with: > > Debugger entered--Lisp error: (invalid-read-syntax "Expected" "lambda") > edebug-syntax-error("Expected" "lambda") I can reproduce this, though, so I've added Alan to the CCs. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 08:24:31 2021 Received: (at 48100) by debbugs.gnu.org; 2 May 2021 12:24:31 +0000 Received: from localhost ([127.0.0.1]:42530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldB9D-0006g8-EI for submit@debbugs.gnu.org; Sun, 02 May 2021 08:24:31 -0400 Received: from colin.muc.de ([193.149.48.1]:37352 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ldB9B-0006g2-M6 for 48100@debbugs.gnu.org; Sun, 02 May 2021 08:24:30 -0400 Received: (qmail 67784 invoked by uid 3782); 2 May 2021 12:24:23 -0000 Received: from acm.muc.de (p4fe153df.dip0.t-ipconnect.de [79.225.83.223]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 02 May 2021 14:24:22 +0200 Received: (qmail 19040 invoked by uid 1000); 2 May 2021 12:24:22 -0000 Date: Sun, 2 May 2021 12:24:22 +0000 To: Paul Nelson , Lars Ingebrigtsen Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: acm@muc.de, 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Paul and Lars. On Thu, Apr 29, 2021 at 10:04:36 +0200, Paul Nelson wrote: > Inserting a sufficiently large chunk of text into a fresh cpp file > breaks syntax highlighting and causes the buffer to enter a > semi-permanent broken state. Moreover, the offending function > "c-guess-basic-syntax" seems to break edebug instrumentation. Thanks for taking the trouble to report these bugs. > In more detail: > Start from emacs -Q. Insert sufficiently many lines of C++ code in a > temporary buffer. A slightly contrived example: > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > Copy these lines to the kill ring. Create a new file "test.cpp", and > paste what was copied. I'm assuming here that by "paste" you mean type C-y. > The first error is that syntax highlighting stops after a certain > number of lines (in the above example, just before the final line). I can't reproduce this, that's on GNU/Linux, neither in a tty nor in X-Windows. However, it looks like on your machine Emacs is fontifying one single 500-byte chunk (which is rounded up to the next EOL) and then neglecting the rest of the lines input (i.e. the final line with ). > The same problem arises if such lines are inserted via abbrev-mode. > This is the intended use case. > No problem if such lines are copy/pasted in small enough chunks. > The problem *appears* to go away if one cuts and then pastes the > offending lines, but the buffer remains in a broken state. For > instance, attempting to insert a couple newlines followed by > int main( > gives the following error: > Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) > c-guess-basic-syntax() > c-indent-line() > indent-according-to-mode() > c-electric-paren(nil) > funcall-interactively(c-electric-paren nil) > command-execute(c-electric-paren) I can't reproduce that either, I'm afraid. At least, not yet. > Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a long and > complicated backtrace that starts with: > Debugger entered--Lisp error: (invalid-read-syntax "Expected" "lambda") > edebug-syntax-error("Expected" "lambda") That, I can reproduce. After a bit of experimentation, it would appear that this is due to the lack of an edebug-spec for the macro c-save-buffer-state. To confirm this in the most basic manner, type M-: (def-edebug-spec c-save-buffer-state let*) , after which C-u C-M-x works on c-guess-basic-syntax. More practically, this situation can be worked around with M-x load-library RET cc-mode RET , which loads cc-defs.elc, which contains the pertinent edebug-spec. I don't understand how that edebug-spec in cc-defs.elc is not loaded anyway, given the you're already using CC Mode. Perhaps that will become clearer in the next few days. > In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60 > Version 10.15.7 (Build 19H524)) > of 2021-04-26 built on Pauls-MBP-2 > Repository revision: 9d34fd8b33c55768190d41239931120e3fc9717f > Repository branch: master > Windowing system distributor 'Apple', version 10.3.1894 > System Description: Mac OS X 10.15.7 > Configured using: > 'configure --with-native-compilation' [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 09:33:43 2021 Received: (at 48100) by debbugs.gnu.org; 2 May 2021 13:33:43 +0000 Received: from localhost ([127.0.0.1]:42844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldCEB-0003A2-DB for submit@debbugs.gnu.org; Sun, 02 May 2021 09:33:43 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:52761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldCE6-00039r-MI for 48100@debbugs.gnu.org; Sun, 02 May 2021 09:33:42 -0400 Received: by mail-wm1-f49.google.com with SMTP id g65so1754543wmg.2 for <48100@debbugs.gnu.org>; Sun, 02 May 2021 06:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XwWsaSNvJZawb1Wuj6NsQThrwHIMTHh49C8TKV5XKdI=; b=HIJYVr+n6SCEmY7LdDVGURHOHDeIQFAL2Hk0z8vq1KuIOjjVRYHC5zo3PjXmaqVH4f MzSxVhq68R2ivQ+j9TPpBIsP/Ro2cIhtJ2qAz5kVXvwhNsuxtjRGQ/DLbRStzYe+XEsN U9lecfMDApR2BE1gsS81h10WoJ0h5QeedSL0zdpOcipqGNQF3D/0bM9zLz6oLCY6djw4 uMQYupAW7B39zD9Fhx4ETCzrEbVPZHsY+NtQ8J7fmt/JhMvX32jesnZyjgkOWDlzvJc2 V+c6++Z1v3uaH3o1eGHyA8wcsocg1n9S3QDds1po7J0J4xXh0eMnsIEfdOqA7zEK3AKf n6pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XwWsaSNvJZawb1Wuj6NsQThrwHIMTHh49C8TKV5XKdI=; b=HAhegpxrpxDa+zsmcbudU/lhyQki0Q98XK0nF9P5EPSpiEcKN5ePL9zztYpzL5ax+N QS2uYkSyD8HNqywi2JxVK9epctxsKo9xnqeC7cap7DtkQR+XBJdsqXvJ631z1KoPp6/G s4WAZfdzlZsTauEO4a7fXiHAsxPlVL6+n+kyPjPuvidZq6fz8ndhaOcSqnVFTAI15fk2 ULIKY6bvwGSfFAwoe1DWpAAv/QxuUVfNf8ByLF+Be3BE4r8Jq1ew81oOTYbp8X4z9fq7 81n1cERikDzFz4x6MnumohZhHH16cPScPQSsS1XtaBtDAXm9gyTQQaTxDRWydQFGmDaS /o0A== X-Gm-Message-State: AOAM532gQrRERnzQsVtKt2wvZbhSu9R0XDGeWxf7bhIy86xoa8eDVJHt WNupaKPGoumm9CkPQ01swQvB1Q== X-Google-Smtp-Source: ABdhPJwK5VrJ88AaSbJv1cRuNzptKiO1zPuPBn+TM0D0MqV+Fu4aV1H+YQGNpyvDHQo7pNhHFwtpeQ== X-Received: by 2002:a1c:ed0d:: with SMTP id l13mr27135856wmh.78.1619962412776; Sun, 02 May 2021 06:33:32 -0700 (PDT) Received: from localhost ([64.43.145.37]) by smtp.gmail.com with ESMTPSA id i20sm17825644wmq.29.2021.05.02.06.33.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 May 2021 06:33:31 -0700 (PDT) From: "Basil L. Contovounesios" To: Alan Mackenzie Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer References: Date: Sun, 02 May 2021 14:33:29 +0100 In-Reply-To: (Alan Mackenzie's message of "Sun, 2 May 2021 12:24:22 +0000") Message-ID: <87a6pd45w6.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: Lars Ingebrigtsen , 48100@debbugs.gnu.org, Paul Nelson X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: >> Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a long and >> complicated backtrace that starts with: > >> Debugger entered--Lisp error: (invalid-read-syntax "Expected" "lambda") >> edebug-syntax-error("Expected" "lambda") > > That, I can reproduce. After a bit of experimentation, it would appear > that this is due to the lack of an edebug-spec for the macro > c-save-buffer-state. Or rather, a recent change in its Edebug spec. > To confirm this in the most basic manner, type > > M-: (def-edebug-spec c-save-buffer-state let*) Until recently, the Edebug spec of c-save-buffer-state was set twice: once by its declare form (as 't'), and later by def-edebug-spec (as 'let*'). The latter was recently removed: CC Mode: Put debug specs inside declare forms. Add missing debug specs. 31f8ae53be 2021-04-15 10:11:20 +0000 https://git.sv.gnu.org/cgit/emacs.git/commit/?id=31f8ae53beb9bada58750160c1bf7f867ecd442e This suggests that the remaining declare form is at fault. Thanks, -- Basil From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 11:01:16 2021 Received: (at 48100) by debbugs.gnu.org; 2 May 2021 15:01:16 +0000 Received: from localhost ([127.0.0.1]:43209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldDau-0003uT-1I for submit@debbugs.gnu.org; Sun, 02 May 2021 11:01:16 -0400 Received: from colin.muc.de ([193.149.48.1]:41238 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ldDar-0003uN-H0 for 48100@debbugs.gnu.org; Sun, 02 May 2021 11:01:15 -0400 Received: (qmail 71239 invoked by uid 3782); 2 May 2021 15:01:06 -0000 Received: from acm.muc.de (p4fe153df.dip0.t-ipconnect.de [79.225.83.223]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 02 May 2021 17:01:06 +0200 Received: (qmail 4603 invoked by uid 1000); 2 May 2021 15:01:05 -0000 Date: Sun, 2 May 2021 15:01:05 +0000 To: "Basil L. Contovounesios" Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Message-ID: References: <87a6pd45w6.fsf@tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a6pd45w6.fsf@tcd.ie> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: Lars Ingebrigtsen , 48100@debbugs.gnu.org, Paul Nelson X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Basil. On Sun, May 02, 2021 at 14:33:29 +0100, Basil L. Contovounesios wrote: > Alan Mackenzie writes: > >> Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a long and > >> complicated backtrace that starts with: > >> Debugger entered--Lisp error: (invalid-read-syntax "Expected" "lambda") > >> edebug-syntax-error("Expected" "lambda") > > That, I can reproduce. After a bit of experimentation, it would appear > > that this is due to the lack of an edebug-spec for the macro > > c-save-buffer-state. > Or rather, a recent change in its Edebug spec. > > To confirm this in the most basic manner, type > > M-: (def-edebug-spec c-save-buffer-state let*) > Until recently, the Edebug spec of c-save-buffer-state was set twice: > once by its declare form (as 't'), and later by def-edebug-spec (as > 'let*'). The latter was recently removed: > CC Mode: Put debug specs inside declare forms. Add missing debug specs. > 31f8ae53be 2021-04-15 10:11:20 +0000 > https://git.sv.gnu.org/cgit/emacs.git/commit/?id=31f8ae53beb9bada58750160c1bf7f867ecd442e > This suggests that the remaining declare form is at fault. Thank you indeed for clearing this up. The standalone CC Mode version was actually OK here, which made it harder to find. I think I'm still right about not being able to instrument c-guess-basic-syntax and friends until the correct debug spec has been loaded. But who's going to be doing that, anyway? I will correct this bug soon. Thank you again. > Thanks, > -- > Basil -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed May 05 03:40:04 2021 Received: (at 48100) by debbugs.gnu.org; 5 May 2021 07:40:04 +0000 Received: from localhost ([127.0.0.1]:58313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leC8Y-0004jm-A3 for submit@debbugs.gnu.org; Wed, 05 May 2021 03:40:04 -0400 Received: from mail-pj1-f49.google.com ([209.85.216.49]:50978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1le7nN-0005pT-SQ for 48100@debbugs.gnu.org; Tue, 04 May 2021 23:01:54 -0400 Received: by mail-pj1-f49.google.com with SMTP id md17so62021pjb.0 for <48100@debbugs.gnu.org>; Tue, 04 May 2021 20:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cZxjmeJ6tFyPhxs1nwTVYTOTCkS2rRiFyxhVCo1hk+8=; b=W4q4B4/CjmfofS0sRTthNDjlRJlC6jsh8PSYl3Fa8VjHClzTAwIBPdL5L6j/SUiXGB 1tNJgRcRMpF2zVKIsX3FmNXZ/yUYTM6iEfNuffoz9ROBlUbHEa/nLitXlNEZ1znXzbgi PW+nWOVbtweKKA/lmvOkD8WlnhS3YvPAHHM1k8GoNRes+UVT1u6MQwll1HTYbkcWihUQ mSTtSTuIpUnptDNzxCT9alA6C4H/iA1tdoIr4aySg1oimpU0g78+0IRQbnryWlQmlUU0 aTmcN8Y2kAy9bRhlYvom55lp70gVqlK3vE+wCsvLXgSSl927Rr9NJqSH0WRNarE8UTWe a8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cZxjmeJ6tFyPhxs1nwTVYTOTCkS2rRiFyxhVCo1hk+8=; b=kbXAz8kLd6qP1urDZU0yAhXjIhqXihH++HVE4YevrWenNa4V8hA5oD/1zoLaBkkgWJ sG5AYpWnQGjeIBHzr7mJ3P9e5pRRul8J727Zoo/Y1VBArN1SvaGTFayggzb0MwxwmI2e bwoccUV36TIu3ntx8lapN3YVNlqCI9Ra03GPtcTorV/0N2eHtesWSSWM1dKVbNLnOILM NTYt8AbbjgcuKwfQ8OOSY5mV3K8fKDTJ0Digvrind5uWxasTZcZyKkxMcauIiHTOsKRm ch9XoLbVbdH2itrsxTzeSaMcJtT5kBUpgeK7Y8UPJQ79DEv4UTKE5IRXY6VZwM3MyWx8 VZVA== X-Gm-Message-State: AOAM531pFQCKgg0Gj3rYN0E9umr7fAgqLYKT2OJewzXFwlyvBsLNZuNJ xkRhuGBMpb0SXfClq7HP6tBouqg0QU8GJVEra/0= X-Google-Smtp-Source: ABdhPJwZQNTTuD7EDsW6pe1JF9VBGysz05MTqoo8JYOGQJDylfKzG5RKEJSj7M2Lnbccf7eeSH0CaOTWWypagsGwkUQ= X-Received: by 2002:a17:90b:347:: with SMTP id fh7mr8946857pjb.183.1620183707733; Tue, 04 May 2021 20:01:47 -0700 (PDT) MIME-Version: 1.0 References: <87a6pd45w6.fsf@tcd.ie> In-Reply-To: From: Paul Nelson Date: Wed, 5 May 2021 05:01:36 +0200 Message-ID: Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer To: Alan Mackenzie Content-Type: multipart/alternative; boundary="0000000000005ed33f05c18c6ad7" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 X-Mailman-Approved-At: Wed, 05 May 2021 03:40:01 -0400 Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000005ed33f05c18c6ad7 Content-Type: text/plain; charset="UTF-8" Hi all, Thanks for your responses. Alan's suggestion "M-: (def-edebug-spec c-save-buffer-state let*)" allowed me to debug the original issue in more detail. In summary, the issue goes away entirely if I simply C-M-x the function c-determine-limit-no-macro before doing anything. What baffles me is why that function should behave differently after C-M-x'ing (perhaps something to do with emacs compilation, which I'm not so familiar with). Before diving into the details, let me note that the issue does not appear to be an isolated peculiarity related to inserting large chunks of code -- the same bug has shown up repeatedly the past few days in more "organic" situations involving normal C++ code. The example noted in my original report remains the simplest reproducible one that I've found. The part of c-guess-basic-syntax that generates the error ("Wrong type argument: number-or-marker-p, nil") is the following: ;; CASE 5B: After a function header but before the body (or ;; the ending semicolon if there's no body). ((save-excursion (when (setq placeholder (c-just-after-func-arglist-p (max lim (c-determine-limit 500)))) (setq tmp-pos (point)))) (cond The issue is that (c-determine-limit 500) returns nil, which is an invalid argument to ~max~. When I instrument and step through the offending invocation of c-determine-limit, the execution passes through the second branch of the final ~cond~ clause, which reads as follows: ((>= count how-far-back) (c-determine-limit-no-macro (+ (car elt) (- count how-far-back)) org-start)) Stepping through the above code block in edebug using SPC, the function c-determine-limit-no-macro returns ~nil~, which then propagates as the return value of c-determine-limit. The problem boils down to: why does c-determine-limit-no-macro return ~nil~? The arguments passed to the function c-determine-limit-no-macro in the offending invocation are non-nil. That function is simple enough to analyze with the naked eye, and it seems logically impossible for it to return nil on non-nil arguments. When I tried debugging it, the issue went away entirely -- after instrumentation, c-determine-limit-no-macro returns a numerical value, as it should, which propagates to a numerical return value of c-determine-limit, and hence to an error-free execution of c-guess-basic-syntax. This is all with emacs -Q and tested repeatedly across fresh startups of emacs. I then tried simply C-M-x'ing c-determine-limit-no-macro on startup, and the original issue went away. As a "fix", I've simply copied the definition of c-determine-limit-no-macro to my init file. I'd still be happy to understand better what's going on. Thanks, best, Paul On Sun, May 2, 2021 at 5:01 PM Alan Mackenzie wrote: > Hello, Basil. > > On Sun, May 02, 2021 at 14:33:29 +0100, Basil L. Contovounesios wrote: > > Alan Mackenzie writes: > > > >> Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a > long and > > >> complicated backtrace that starts with: > > > >> Debugger entered--Lisp error: (invalid-read-syntax "Expected" > "lambda") > > >> edebug-syntax-error("Expected" "lambda") > > > > That, I can reproduce. After a bit of experimentation, it would appear > > > that this is due to the lack of an edebug-spec for the macro > > > c-save-buffer-state. > > > Or rather, a recent change in its Edebug spec. > > > > To confirm this in the most basic manner, type > > > > M-: (def-edebug-spec c-save-buffer-state let*) > > > Until recently, the Edebug spec of c-save-buffer-state was set twice: > > once by its declare form (as 't'), and later by def-edebug-spec (as > > 'let*'). The latter was recently removed: > > > CC Mode: Put debug specs inside declare forms. Add missing debug specs. > > 31f8ae53be 2021-04-15 10:11:20 +0000 > > > https://git.sv.gnu.org/cgit/emacs.git/commit/?id=31f8ae53beb9bada58750160c1bf7f867ecd442e > > > This suggests that the remaining declare form is at fault. > > Thank you indeed for clearing this up. The standalone CC Mode version > was actually OK here, which made it harder to find. > > I think I'm still right about not being able to instrument > c-guess-basic-syntax and friends until the correct debug spec has been > loaded. But who's going to be doing that, anyway? > > I will correct this bug soon. > > Thank you again. > > > Thanks, > > > -- > > Basil > > -- > Alan Mackenzie (Nuremberg, Germany). > --0000000000005ed33f05c18c6ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for your responses.=C2=A0 Alan's= suggestion "M-: (def-edebug-spec c-save-buffer-state let*)" allo= wed me to debug the original issue in more detail.

In summary, the i= ssue goes away entirely if I simply C-M-x the function c-determine-limit-no= -macro before doing anything.=C2=A0 What baffles me is why that function sh= ould behave differently after C-M-x'ing (perhaps something to do with e= macs compilation, which I'm not so familiar with).

Before diving= into the details, let me note that the issue does not appear to be an isol= ated peculiarity related to inserting large chunks of code -- the same bug = has shown up repeatedly the past few days in more "organic" situa= tions involving normal C++ code.=C2=A0 The example noted in my original rep= ort remains the simplest reproducible one that I've found.

The p= art of c-guess-basic-syntax that generates the error ("Wrong type argu= ment: number-or-marker-p, nil") is the following:

=C2=A0 ;; CAS= E 5B: After a function header but before the body (or
;; the ending semi= colon if there's no body).
((save-excursion
=C2=A0 =C2=A0(when (s= etq placeholder (c-just-after-func-arglist-p
=C2=A0 =C2=A0 (max lim (c-d= etermine-limit 500))))
=C2=A0 =C2=A0 =C2=A0(setq tmp-pos (point))))
= =C2=A0(cond

The issue is that (c-determine-limit 500) returns nil, w= hich is an invalid argument to ~max~.

When I instrument and step thr= ough the offending invocation of c-determine-limit, the execution passes th= rough the second branch of the final ~cond~ clause, which reads as follows:=

((>=3D count how-far-back)
=C2=A0(c-determine-limit-no-macro<= br>=C2=A0(+ (car elt) (- count how-far-back))
=C2=A0org-start))

S= tepping through the above code block in edebug using SPC, the function c-de= termine-limit-no-macro returns ~nil~, which then propagates as the return v= alue of c-determine-limit.=C2=A0 The problem boils down to: why does c-dete= rmine-limit-no-macro return ~nil~?

The arguments passed to the funct= ion c-determine-limit-no-macro in the offending invocation are non-nil.=C2= =A0 That function is simple enough to analyze with the naked eye, and it se= ems logically impossible for it to return nil on non-nil arguments.=C2=A0 W= hen I tried debugging it, the issue went away entirely -- after instrumenta= tion, c-determine-limit-no-macro returns a numerical value, as it should, w= hich propagates to a numerical return value of c-determine-limit, and hence= to an error-free execution of c-guess-basic-syntax.=C2=A0 This is all with= emacs -Q and tested repeatedly across fresh startups of emacs.=C2=A0 I the= n tried simply C-M-x'ing c-determine-limit-no-macro on startup, and the= original issue went away.

As a "fix", I've simply cop= ied the definition of c-determine-limit-no-macro to my init file.=C2=A0 I&#= 39;d still be happy to understand better what's going on.

Thanks= , best,

Paul


On Sun, May 2, 2021 = at 5:01 PM Alan Mackenzie <acm@muc.de&= gt; wrote:
Hello= , Basil.

On Sun, May 02, 2021 at 14:33:29 +0100, Basil L. Contovounesios wrote:
> Alan Mackenzie <acm= @muc.de> writes:

> >> Incidentally, "C-u C-M-x" applied to c-guess-basic-= syntax gives a long and
> >> complicated backtrace that starts with:

> >> Debugger entered--Lisp error: (invalid-read-syntax "Expe= cted" "lambda")
> >>=C2=A0 =C2=A0edebug-syntax-error("Expected" "la= mbda")

> > That, I can reproduce.=C2=A0 After a bit of experimentation, it w= ould appear
> > that this is due to the lack of an edebug-spec for the macro
> > c-save-buffer-state.

> Or rather, a recent change in its Edebug spec.

> > To confirm this in the most basic manner, type

> >=C2=A0 =C2=A0 M-: (def-edebug-spec c-save-buffer-state let*)

> Until recently, the Edebug spec of c-save-buffer-state was set twice:<= br> > once by its declare form (as 't'), and later by def-edebug-spe= c (as
> 'let*').=C2=A0 The latter was recently removed:

> CC Mode: Put debug specs inside declare forms.=C2=A0 Add missing debug= specs.
> 31f8ae53be 2021-04-15 10:11:20 +0000
> http= s://git.sv.gnu.org/cgit/emacs.git/commit/?id=3D31f8ae53beb9bada58750160c1bf= 7f867ecd442e

> This suggests that the remaining declare form is at fault.

Thank you indeed for clearing this up.=C2=A0 The standalone CC Mode version=
was actually OK here, which made it harder to find.

I think I'm still right about not being able to instrument
c-guess-basic-syntax and friends until the correct debug spec has been
loaded.=C2=A0 But who's going to be doing that, anyway?

I will correct this bug soon.

Thank you again.

> Thanks,

> --
> Basil

--
Alan Mackenzie (Nuremberg, Germany).
--0000000000005ed33f05c18c6ad7-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 05 05:26:20 2021 Received: (at 48100) by debbugs.gnu.org; 5 May 2021 09:26:20 +0000 Received: from localhost ([127.0.0.1]:58973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leDnP-0006vo-Q0 for submit@debbugs.gnu.org; Wed, 05 May 2021 05:26:19 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leDnN-0006vi-Pv for 48100@debbugs.gnu.org; Wed, 05 May 2021 05:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tSbJENf/pTl3FzBPxK0NmRecsPAYLGvPggL/beqqA8c=; b=Wt+EwjUGhfExCZUa9vj02+6Ru3 0OJc/3xzafl3x0efzUuLy3GjDSQjrz8axTLXjNLzyie3Ob6n1tlKiABeyQo81wpOyo61WVCzgz/DO y5VfQQptxaqxprmDvHKd3XgSTERuXOuH3IJUB3M8eTATEmeG7zr7nTn/G6bKfMYKZdzQ=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1leDnF-00074x-9f; Wed, 05 May 2021 11:26:11 +0200 From: Lars Ingebrigtsen To: Paul Nelson Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer References: <87a6pd45w6.fsf@tcd.ie> X-Now-Playing: Nico's _Fata Morgana_: "The Hanging Gardens Of Semiramis" Date: Wed, 05 May 2021 11:26:08 +0200 In-Reply-To: (Paul Nelson's message of "Wed, 5 May 2021 05:01:36 +0200") Message-ID: <87im3x7cr3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Nelson writes: > I then tried simply C-M-x'ing c-determine-limit-no-macro on startup, > and the original issue went away. It sound like your Emacs might be miscompiled. Have you tried doing a "make bootstrap"? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: "Basil L. Contovounesios" , Alan Mackenzie , 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Paul Nelson writes: > I then tried simply C-M-x'ing c-determine-limit-no-macro on startup, > and the original issue went away. It sound like your Emacs might be miscompiled. Have you tried doing a "make bootstrap"? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed May 05 06:18:51 2021 Received: (at 48100) by debbugs.gnu.org; 5 May 2021 10:18:51 +0000 Received: from localhost ([127.0.0.1]:59226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leEcF-0007YF-BR for submit@debbugs.gnu.org; Wed, 05 May 2021 06:18:51 -0400 Received: from colin.muc.de ([193.149.48.1]:29895 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1leEcC-0007Y8-1x for 48100@debbugs.gnu.org; Wed, 05 May 2021 06:18:49 -0400 Received: (qmail 35001 invoked by uid 3782); 5 May 2021 10:18:41 -0000 Received: from acm.muc.de (p4fe15dc9.dip0.t-ipconnect.de [79.225.93.201]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 05 May 2021 12:18:40 +0200 Received: (qmail 5232 invoked by uid 1000); 5 May 2021 10:18:40 -0000 Date: Wed, 5 May 2021 10:18:40 +0000 To: Paul Nelson Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Message-ID: References: <87a6pd45w6.fsf@tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Paul. On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote: > Hi all, > Thanks for your responses. Alan's suggestion "M-: (def-edebug-spec > c-save-buffer-state let*)" allowed me to debug the original issue in more > detail. > In summary, the issue goes away entirely if I simply C-M-x the function > c-determine-limit-no-macro before doing anything. What baffles me is why > that function should behave differently after C-M-x'ing (perhaps something > to do with emacs compilation, which I'm not so familiar with). I'm glad you put so much work into debugging this. What you have probably done is found bug #48061 again, which saves me a lot of work. Thanks! ;-) In that bug, the native compiler mis-compiled c-determine-limit-no-macro such that it sometimes returned an invalid value nil. This looks like exactly what we are seeing now. Bug #48061 was fixed and closed on Wednesday 28th April, a week ago. Could I ask you, please, to update your Emacs (if you haven't already done so) and rebuild it. With any luck, the current bug will have been fixed. I'm leaving the rest of your last post here, just in case we don't yet have a fix. Would you please let us know how your latest test goes. Thanks! > Before diving into the details, let me note that the issue does not appear > to be an isolated peculiarity related to inserting large chunks of code -- > the same bug has shown up repeatedly the past few days in more "organic" > situations involving normal C++ code. The example noted in my original > report remains the simplest reproducible one that I've found. > The part of c-guess-basic-syntax that generates the error ("Wrong type > argument: number-or-marker-p, nil") is the following: > ;; CASE 5B: After a function header but before the body (or > ;; the ending semicolon if there's no body). > ((save-excursion > (when (setq placeholder (c-just-after-func-arglist-p > (max lim (c-determine-limit 500)))) > (setq tmp-pos (point)))) > (cond > The issue is that (c-determine-limit 500) returns nil, which is an invalid > argument to ~max~. > When I instrument and step through the offending invocation of > c-determine-limit, the execution passes through the second branch of the > final ~cond~ clause, which reads as follows: > ((>= count how-far-back) > (c-determine-limit-no-macro > (+ (car elt) (- count how-far-back)) > org-start)) > Stepping through the above code block in edebug using SPC, the function > c-determine-limit-no-macro returns ~nil~, which then propagates as the > return value of c-determine-limit. The problem boils down to: why does > c-determine-limit-no-macro return ~nil~? > The arguments passed to the function c-determine-limit-no-macro in the > offending invocation are non-nil. That function is simple enough to > analyze with the naked eye, and it seems logically impossible for it to > return nil on non-nil arguments. When I tried debugging it, the issue went > away entirely -- after instrumentation, c-determine-limit-no-macro returns > a numerical value, as it should, which propagates to a numerical return > value of c-determine-limit, and hence to an error-free execution of > c-guess-basic-syntax. This is all with emacs -Q and tested repeatedly > across fresh startups of emacs. I then tried simply C-M-x'ing > c-determine-limit-no-macro on startup, and the original issue went away. > As a "fix", I've simply copied the definition of c-determine-limit-no-macro > to my init file. I'd still be happy to understand better what's going on. > Thanks, best, > Paul -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu May 06 11:04:15 2021 Received: (at 48100) by debbugs.gnu.org; 6 May 2021 15:04:15 +0000 Received: from localhost ([127.0.0.1]:37959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lefXy-0001cs-GM for submit@debbugs.gnu.org; Thu, 06 May 2021 11:04:15 -0400 Received: from mail-pl1-f174.google.com ([209.85.214.174]:42968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lebDB-0006SP-AA for 48100@debbugs.gnu.org; Thu, 06 May 2021 06:26:30 -0400 Received: by mail-pl1-f174.google.com with SMTP id v13so3147576ple.9 for <48100@debbugs.gnu.org>; Thu, 06 May 2021 03:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MBZd+jWnkqgAro9aNTAEJvuZ6DutRODheAjw707dg1M=; b=sYvmObGiET1p1lBkKj3yjkkN+dXVPUzG0sjyHDsykLqygU2258ld440xizZ/7kyMzY pkXIBAQ1kfG2GY62l/YB46b7pvuUDMndXy3JyUK0QOvdSOZn2OThW2GHucYc5fPJj9+2 TWY9/WM/Js/4DfEMvgr4EU4g5OZ611Mk/WlU639OE5kVdTDp4+zBneyDm4YGbycGYkM9 C0CVNcurvCz3l85XhFpqsrd//p+6KBPd6PLK/R2RPnYLubNjOwGcuvAQfzs3MPZ5Ak6s knzS1mbjDYlpBZEMtdU3Gcf8LZjeJ7qPHzq1gD8h9AFCvTxepNJb4gLy+lQWztkLHKKK SmiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MBZd+jWnkqgAro9aNTAEJvuZ6DutRODheAjw707dg1M=; b=IUMbr19oU42fot4D6iuXr2I4/J44zj8QXJ6COWu1ym1fpSVqxYKm9nxfY81Wi2+zRf OY1FLiKLE1005MoswlF071ng9220VcVwQ5vRqf4uV8Apu6OdRu3UetE1byWcoei1L38z eAgx0XZMxx9KofOZvGisMENo9GUVSDOSWwWh3rSum314OmKvJcezCeoWPVLISYY6Dsyj vc8BCBfHgnYMu23hVNnECFkKt0+AVLG8XjIjVl/hzkWCOvYXOFjHVQE4q9YG7nroSGuC R7VMLJFiv5eeFrz4tdrj0MQc/oNcmMRrhK6ct5SwHNiBfW0PaLUa0/E4mfgoGkOhIKMM LWYg== X-Gm-Message-State: AOAM531OyZrQHVJBmsBE5F9xtIzNX/vPc/wssnhuOHRT0oCJxHzC7oja V0oHshyxyZFLLh29ntKRZY9wp2S23Hdjnm3z4C4= X-Google-Smtp-Source: ABdhPJwGvjpFCrMLKW3uHFnPWAF2UIhDbOmiz9Fz0JDwxP8rmi5jh91GpD1pfaoWxi5V38P3ZGhLqzNinbqoxPiwcBA= X-Received: by 2002:a17:902:ed97:b029:ee:af8e:3a0a with SMTP id e23-20020a170902ed97b02900eeaf8e3a0amr3935140plj.52.1620296783312; Thu, 06 May 2021 03:26:23 -0700 (PDT) MIME-Version: 1.0 References: <87a6pd45w6.fsf@tcd.ie> In-Reply-To: From: Paul Nelson Date: Thu, 6 May 2021 12:26:12 +0200 Message-ID: Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer To: Alan Mackenzie Content-Type: multipart/alternative; boundary="0000000000003338d405c1a6be0d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48100 X-Mailman-Approved-At: Thu, 06 May 2021 11:04:12 -0400 Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003338d405c1a6be0d Content-Type: text/plain; charset="UTF-8" Hi Alan, Looks good after updating -- seems like it was indeed a repeat of #48061. Thanks for your help! I'll report back if anything similar comes up again. Paul On Wed, May 5, 2021 at 12:18 PM Alan Mackenzie wrote: > Hello, Paul. > > On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote: > > Hi all, > > > Thanks for your responses. Alan's suggestion "M-: (def-edebug-spec > > c-save-buffer-state let*)" allowed me to debug the original issue in more > > detail. > > > In summary, the issue goes away entirely if I simply C-M-x the function > > c-determine-limit-no-macro before doing anything. What baffles me is why > > that function should behave differently after C-M-x'ing (perhaps > something > > to do with emacs compilation, which I'm not so familiar with). > > I'm glad you put so much work into debugging this. What you have > probably done is found bug #48061 again, which saves me a lot of work. > Thanks! ;-) > > In that bug, the native compiler mis-compiled c-determine-limit-no-macro > such that it sometimes returned an invalid value nil. This looks like > exactly what we are seeing now. Bug #48061 was fixed and closed on > Wednesday 28th April, a week ago. > > Could I ask you, please, to update your Emacs (if you haven't already > done so) and rebuild it. With any luck, the current bug will have been > fixed. I'm leaving the rest of your last post here, just in case we > don't yet have a fix. Would you please let us know how your latest test > goes. Thanks! > > > Before diving into the details, let me note that the issue does not > appear > > to be an isolated peculiarity related to inserting large chunks of code > -- > > the same bug has shown up repeatedly the past few days in more "organic" > > situations involving normal C++ code. The example noted in my original > > report remains the simplest reproducible one that I've found. > > > The part of c-guess-basic-syntax that generates the error ("Wrong type > > argument: number-or-marker-p, nil") is the following: > > > ;; CASE 5B: After a function header but before the body (or > > ;; the ending semicolon if there's no body). > > ((save-excursion > > (when (setq placeholder (c-just-after-func-arglist-p > > (max lim (c-determine-limit 500)))) > > (setq tmp-pos (point)))) > > (cond > > > The issue is that (c-determine-limit 500) returns nil, which is an > invalid > > argument to ~max~. > > > When I instrument and step through the offending invocation of > > c-determine-limit, the execution passes through the second branch of the > > final ~cond~ clause, which reads as follows: > > > ((>= count how-far-back) > > (c-determine-limit-no-macro > > (+ (car elt) (- count how-far-back)) > > org-start)) > > > Stepping through the above code block in edebug using SPC, the function > > c-determine-limit-no-macro returns ~nil~, which then propagates as the > > return value of c-determine-limit. The problem boils down to: why does > > c-determine-limit-no-macro return ~nil~? > > > The arguments passed to the function c-determine-limit-no-macro in the > > offending invocation are non-nil. That function is simple enough to > > analyze with the naked eye, and it seems logically impossible for it to > > return nil on non-nil arguments. When I tried debugging it, the issue > went > > away entirely -- after instrumentation, c-determine-limit-no-macro > returns > > a numerical value, as it should, which propagates to a numerical return > > value of c-determine-limit, and hence to an error-free execution of > > c-guess-basic-syntax. This is all with emacs -Q and tested repeatedly > > across fresh startups of emacs. I then tried simply C-M-x'ing > > c-determine-limit-no-macro on startup, and the original issue went away. > > > As a "fix", I've simply copied the definition of > c-determine-limit-no-macro > > to my init file. I'd still be happy to understand better what's going > on. > > > Thanks, best, > > > Paul > > -- > Alan Mackenzie (Nuremberg, Germany). > --0000000000003338d405c1a6be0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

Looks good after updating -- s= eems like it was indeed a repeat of #48061.=C2=A0 Thanks for your help!=C2= =A0 I'll report back if anything similar comes up again.

=
Paul


On Wed, May 5, 2021 at 12:18 PM Alan Ma= ckenzie <acm@muc.de> wrote:
Hello, Paul.

On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote:
> Hi all,

> Thanks for your responses.=C2=A0 Alan's suggestion "M-: (def-= edebug-spec
> c-save-buffer-state let*)" allowed me to debug the original issue= in more
> detail.

> In summary, the issue goes away entirely if I simply C-M-x the functio= n
> c-determine-limit-no-macro before doing anything.=C2=A0 What baffles m= e is why
> that function should behave differently after C-M-x'ing (perhaps s= omething
> to do with emacs compilation, which I'm not so familiar with).

I'm glad you put so much work into debugging this.=C2=A0 What you have<= br> probably done is found bug #48061 again, which saves me a lot of work.
Thanks!=C2=A0 ;-)

In that bug, the native compiler mis-compiled c-determine-limit-no-macro such that it sometimes returned an invalid value nil.=C2=A0 This looks like=
exactly what we are seeing now.=C2=A0 Bug #48061 was fixed and closed on Wednesday 28th April, a week ago.

Could I ask you, please, to update your Emacs (if you haven't already done so) and rebuild it.=C2=A0 With any luck, the current bug will have bee= n
fixed.=C2=A0 I'm leaving the rest of your last post here, just in case = we
don't yet have a fix.=C2=A0 Would you please let us know how your lates= t test
goes.=C2=A0 Thanks!

> Before diving into the details, let me note that the issue does not ap= pear
> to be an isolated peculiarity related to inserting large chunks of cod= e --
> the same bug has shown up repeatedly the past few days in more "o= rganic"
> situations involving normal C++ code.=C2=A0 The example noted in my or= iginal
> report remains the simplest reproducible one that I've found.

> The part of c-guess-basic-syntax that generates the error ("Wrong= type
> argument: number-or-marker-p, nil") is the following:

>=C2=A0 =C2=A0;; CASE 5B: After a function header but before the body (o= r
> ;; the ending semicolon if there's no body).
> ((save-excursion
>=C2=A0 =C2=A0 (when (setq placeholder (c-just-after-func-arglist-p
>=C2=A0 =C2=A0 =C2=A0(max lim (c-determine-limit 500))))
>=C2=A0 =C2=A0 =C2=A0 (setq tmp-pos (point))))
>=C2=A0 (cond

> The issue is that (c-determine-limit 500) returns nil, which is an inv= alid
> argument to ~max~.

> When I instrument and step through the offending invocation of
> c-determine-limit, the execution passes through the second branch of t= he
> final ~cond~ clause, which reads as follows:

> ((>=3D count how-far-back)
>=C2=A0 (c-determine-limit-no-macro
>=C2=A0 (+ (car elt) (- count how-far-back))
>=C2=A0 org-start))

> Stepping through the above code block in edebug using SPC, the functio= n
> c-determine-limit-no-macro returns ~nil~, which then propagates as the=
> return value of c-determine-limit.=C2=A0 The problem boils down to: wh= y does
> c-determine-limit-no-macro return ~nil~?

> The arguments passed to the function c-determine-limit-no-macro in the=
> offending invocation are non-nil.=C2=A0 That function is simple enough= to
> analyze with the naked eye, and it seems logically impossible for it t= o
> return nil on non-nil arguments.=C2=A0 When I tried debugging it, the = issue went
> away entirely -- after instrumentation, c-determine-limit-no-macro ret= urns
> a numerical value, as it should, which propagates to a numerical retur= n
> value of c-determine-limit, and hence to an error-free execution of > c-guess-basic-syntax.=C2=A0 This is all with emacs -Q and tested repea= tedly
> across fresh startups of emacs.=C2=A0 I then tried simply C-M-x'in= g
> c-determine-limit-no-macro on startup, and the original issue went awa= y.

> As a "fix", I've simply copied the definition of c-deter= mine-limit-no-macro
> to my init file.=C2=A0 I'd still be happy to understand better wha= t's going on.

> Thanks, best,

> Paul

--
Alan Mackenzie (Nuremberg, Germany).
--0000000000003338d405c1a6be0d-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 09 05:34:00 2021 Received: (at control) by debbugs.gnu.org; 9 May 2021 09:34:00 +0000 Received: from localhost ([127.0.0.1]:55182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lffp2-0002wG-8J for submit@debbugs.gnu.org; Sun, 09 May 2021 05:34:00 -0400 Received: from colin.muc.de ([193.149.48.1]:12284 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lffp0-0002w5-37 for control@debbugs.gnu.org; Sun, 09 May 2021 05:33:58 -0400 Received: (qmail 87140 invoked by uid 3782); 9 May 2021 09:33:51 -0000 Received: from acm.muc.de (p2e5d56ec.dip0.t-ipconnect.de [46.93.86.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 09 May 2021 11:33:50 +0200 Received: (qmail 5548 invoked by uid 1000); 9 May 2021 09:33:50 -0000 Date: Sun, 9 May 2021 09:33:50 +0000 To: Paul Nelson Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Message-ID: References: <87a6pd45w6.fsf@tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control Cc: "Basil L. Contovounesios" , acm@muc.de, Lars Ingebrigtsen , control@debbugs.gnu.org, 48100-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 48100 merge 48061 48100 quit Hello, Paul. On Thu, May 06, 2021 at 12:26:12 +0200, Paul Nelson wrote: > Hi Alan, > Looks good after updating -- seems like it was indeed a repeat of #48061. > Thanks for your help! I'll report back if anything similar comes up again. Thanks, I'm glad it's fixed. I'm closing the bug with this post, and trying to merge it into bug #48061, the first bug where c-determine-limit-no-macro miscompiled. > Paul -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 16 23:47:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 06 Jun 2021 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator