Hello, Wei. Thank you for taking the trouble to report this bug, and thanks even more for stripping it down to a bare minimum amount of text. On Sun, Sep 29, 2019 at 02:36:47 +0000, Sun, Wei via CC-Mode-help wrote: > Package: cc-mode > $ cat test.cc > // 你好a > I want to delete the `a`, when press `backspace` after `a`, emacs will throw an error: > `c-unfind-coalesced-tokens: Wrong type argument: integer-or-marker-p, > nil` > the backtrace is: > Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) > c-forward-sws() > c-unfind-coalesced-tokens(6 7) > c-before-change(6 7) > delete-char(-1 nil) > delete-backward-char(1 nil) > backward-delete-char-untabify(1) > c-electric-backspace(nil) > funcall-interactively(c-electric-backspace nil) > call-interactively(c-electric-backspace nil nil) > command-execute(c-electric-backspace) Yes. The cause of this problem is the use of the regular expression "\\<\\>" in CC Mode, which was meant "not to match anything". It turns out that if an Asian character is directly followed by a European character without spaces between them, this position can be at both the start of a word and the end of a word. This is what has happened here. This bug was actually fixed in the Emacs master branch last year, but was too late to make it into Emacs 26. The fix was to use an actual "will never match" regular expression, namely "a\\`". > what's more, if you are visiting a large c++ file, after this error > occurs, then everything will become very slow. This happens because the error with the regexp causes CC Mode's "before change function" to get removed from before-change-hook. When CC Mode detects this, as a precaution against file corruption, it assumes every change is over the entire buffer. This prevents any loss of text, but runs very slowly. [ Dump of CC Mode's configuration appreciated, but snipped.] As a workaround to the bug, please apply the attached patch and byte compile CC Mode. (CC Mode is the ?14 files emacs/lisp/progmodes/cc-*.el). If you want any help in applying this patch or byte compiling the result, feel free to send me private email. Thanks again for this bug report! -- Alan Mackenzie (Nuremberg, Germany).