[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48100: 28.0.50; inserting too many lines into a fresh cpp file break
From: |
Alan Mackenzie |
Subject: |
bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer |
Date: |
Sun, 2 May 2021 12:24:22 +0000 |
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 <cstdio>
> #include <cstdlib>
> #include <cstring>
> #include <climits>
> #include <cfloat>
> #include <vector>
> #include <cmath>
> #include <set>
> #include <list>
> #include <map>
> #include <stack>
> #include <queue>
> #include <iostream>
> #include <sstream>
> #include <fstream>
> #include <algorithm>
> #include <numeric>
> #include <functional>
> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> #include <climits>
> #include <cfloat>
> #include <vector>
> #include <cmath>
> #include <set>
> #include <list>
> #include <map>
> #include <stack>
> 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 <stack>).
> 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).
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Lars Ingebrigtsen, 2021/05/02
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer,
Alan Mackenzie <=
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Basil L. Contovounesios, 2021/05/02
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Alan Mackenzie, 2021/05/02
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Paul Nelson, 2021/05/05
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Lars Ingebrigtsen, 2021/05/05
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Alan Mackenzie, 2021/05/05
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Paul Nelson, 2021/05/06
- bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer, Alan Mackenzie, 2021/05/09