GNU bug report logs - #43481
27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43481 in the body.
You can then email your comments to 43481 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Campbell Barton <ideasman42 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; cc-mode's c-context-line-break fails, inserting a new-line
 into the previous comment
Date: Fri, 18 Sep 2020 09:38:16 +1000

Running 'c-context-line-break' sometimes adds the line break to the
previous comment, this seems to depend on the internal state
since it doesn't happen every time.

Tested in 27.1, and current master, this has been an issue for some
years IIRC.

Take this example C file:

---- BEGIN `example.c`
/*
 * A
 */

/*
 * B
 */
---- END

- Move the cursor the end-of-line above 'A'.
- M-x, c-context-line-break

----  `example.c` (with newline above 'A', as expected).
/*
 *
 * A
 */

/*
 * B
 */
---- END


- Move the cursor the end-of-line above 'B'.
- M-x, c-context-line-break


----  `example.c` (there should be newline above 'B', but there is
not).
/*
 *
 * A

 */

/*
 * B
 */
---- END


----  `example.c` (EXPECTED RESULT)
/*
 *
 * A
 */

/*
 *
 * B
 */
---- END

Instead of a newline being added above 'B', a newline is added
to the previous comment after A, with no leading character.

----

I looked into the bug and this is caused by 'c-literal-limits'
returning an invalid range (where the beginning is correct, but the
end is the end of the previous comment, instead of the end of the
current comment).
Printing 'c-literal-limits' before calling 'c-context-line-break'
shows this error, temporarily advising 'c-literal-limits' to return
the beginning/end of the comment is a workaround which
gives the 'EXPECTED RESULT'.


In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3)
 of 2020-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version
11.0.12009000
System Description: Arch Linux

Recent messages:
Package cl is deprecated
LSP :: foo.c not in project or it is blacklisted.
Undo-Fu-Session discarding undo data: file length mismatch
Undo [5 times]
progn: Beginning of buffer
mouse-yank-secondary: No secondary selection
scroll-up-command: End of buffer
funcall-interactively: End of buffer

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  display-fill-column-indicator-mode: t
  spell-fu-mode: t
  which-function-mode: t
  highlight-numbers-mode: t
  default-text-scale-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  show-paren-mode: t
  savehist-mode: t
  mydoxygen-highlight-mode: t
  gui-clipboard-history-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  shell-dirtrack-mode: t
  evil-mode: t
  evil-local-mode: t
  global-undo-fu-session-mode: t
  undo-fu-session-mode: t
  override-global-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/ideasman42/.config/emacs/elpa/cmake-mode-20190710.1319/cmake-mode
hides /usr/share/emacs/site-lisp/cmake-mode

Features:
(shadow sort mail-extr scroll-on-drag emacsbug message format-spec
rfc822 mml mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
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 counsel xdg dired
dired-loaddefs swiper ivy delsel ivy-faces ivy-overlay colir undo-fu
jka-compr add-log vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs view
lsp-svelte lsp-sqls lsp-yaml lsp-xml lsp-vimscript lsp-vhdl lsp-vetur
lsp-html lsp-verilog lsp-terraform lsp-tex lsp-solargraph lsp-rust
lsp-rf lsp-r lsp-purescript lsp-pyls lsp-pwsh lsp-php lsp-perl lsp-
ocaml
lsp-nim lsp-lua lsp-kotlin lsp-json url url-proxy url-privacy url-
expand
url-methods url-history url-cookie url-domsuf mailcap lsp-javascript
lsp-haxe lsp-groovy lsp-hack lsp-go lsp-gdscript lsp-fsharp lsp-fortran
lsp-eslint lsp-erlang lsp-elixir lsp-elm lsp-dockerfile lsp-dhall
lsp-css lsp-csharp gnutls lsp-crystal lsp-cmake lsp-clojure lsp-clangd
dom lsp-bash lsp-angular lsp-ada display-fill-column-indicator spell-fu
rainbow-delimiters elisp-autofmt nameless lisp-mnt whitespace
lisp-extra-font-lock which-func highlight-numbers parent-mode hideshow
default-text-scale diff-hl face-remap vc-hg vc-git vc-dir vc
vc-dispatcher diff-mode rst cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs hl-line paren
stackexchange-transpose-words stackexchange-imenu-goto
stackexchange-c-transpose-args stackexchange-sort-line-in-block
stackexchange-scroll-and-clamp stackexchange-scratch-buffer-from-file
stackexchange-revert-all-buffers
stackexchange-neotree-project-dir-toggle
stackexchange-mode-line-visual-bell stackexchange-ispell-word-immediate
stackexchange-frame-urgent-hint-set
stackexchange-delete-surround-at-point
stackexchange-comment-multi-line-toggle
stackexchange-backspace-whitespace-to-tab-stop savehist
gui-clipboard-history-mode lsp-mode lsp-protocol yasnippet xref project
url-util tree-widget wid-edit spinner cl network-stream puny nsm rmc
markdown-mode rx color noutline outline lv inline imenu ht filenotify f
s ewoc dash-functional dash compile bindat evil-surround evil
evil-keybindings evil-integration undo-tree diff evil-maps evil-
commands
ffap reveal flyspell ispell evil-jumps evil-command-window evil-types
evil-search evil-ex shell pcomplete comint ansi-color evil-macros
evil-repeat evil-states evil-core advice evil-common windmove thingatpt
rect evil-digraphs evil-vars ring edmacro kmacro undo-fu-session
cl-extra help-mode pcase inkpot-theme use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core derived finder-inf info package easymenu
browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq
byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip
eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd 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 timer
select scroll-bar mouse jit-lock font-lock syntax facemenu 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 loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-
readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-
toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 649698 493642)
 (symbols 48 36426 1)
 (strings 32 254465 6152)
 (string-bytes 1 5053219)
 (vectors 16 42495)
 (vector-slots 8 1252832 32982)
 (floats 8 261 269)
 (intervals 56 1250 0)
 (buffers 1000 13))

Message #10 received at 43481 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Campbell Barton <ideasman42 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43481 <at> debbugs.gnu.org
Subject: Re: bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting
 a new-line into the previous comment
Date: Tue, 24 Nov 2020 15:02:46 +0000

Hello, Campbell.

Thank you indeed for taking the trouble to report this bug.

On Fri, Sep 18, 2020 at 09:38:16 +1000, Campbell Barton wrote:
> Running 'c-context-line-break' sometimes adds the line break to the
> previous comment, this seems to depend on the internal state
> since it doesn't happen every time.

Yes.  The internal state it depends on is a cache for things like
c-literal-limits (as you point out below).  To make the bug show itself,
first type a space in the "A" comment somewhere (which clears the cache
entries for any points after the place of the change), then move point
into the B comment and type M-j.

> Tested in 27.1, and current master, this has been an issue for some
> years IIRC.

> Take this example C file:

> ---- BEGIN `example.c`
> /*
>  * A
>  */

> /*
>  * B
>  */
> ---- END

> - Move the cursor the end-of-line above 'A'.
> - M-x, c-context-line-break

> ----  `example.c` (with newline above 'A', as expected).
> /*
>  *
>  * A
>  */

> /*
>  * B
>  */
> ---- END

[ .... ]

> ----

> I looked into the bug and this is caused by 'c-literal-limits'
> returning an invalid range (where the beginning is correct, but the
> end is the end of the previous comment, instead of the end of the
> current comment).

Thank you very much indeed for taking the debugging so far.  That was
exceptionally helpful.

What was happening was CC Mode read a cache entry, and because there was
no entry for the "B" comment, got that for the "A" comment.  It later
wrongly used the END element of that cache entry, without testing
properly that it was valid.

> Printing 'c-literal-limits' before calling 'c-context-line-break'
> shows this error, temporarily advising 'c-literal-limits' to return
> the beginning/end of the comment is a workaround which
> gives the 'EXPECTED RESULT'.

Yes.

> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
> cairo version 1.17.3)
>  of 2020-08-29 built on juergen
> Windowing system distributor 'The X.Org Foundation', version
> 11.0.12009000
> System Description: Arch Linux

[ .... ]

Would you please try the following patch in CC Mode.  After applying it,
you need byte compile only cc-engine.el (which is in
emacs/lisp/progmodes/).  In the unlikely event you would like any help
with the patching or byte compilation, feel free to send me private
email.

Having applied it, please test out the problem in your real code, and
confirm that the bug is, in fact, fixed, or alternatively tell us that
there are still glitches with it.  Thanks!



diff -r 4cdd79795247 cc-engine.el
--- a/cc-engine.el	Sun Nov 15 10:19:11 2020 +0000
+++ b/cc-engine.el	Tue Nov 24 14:53:07 2020 +0000
@@ -3152,7 +3152,7 @@
 		      ((nth 7 s) 'c++)
 		      (t 'c)))
 	    (setq start (nth 8 s))
-	    (unless end
+	    (unless (and end (>= end here))
 	      (setq s1 (parse-partial-sexp here (point-max)
 					   nil		  ; TARGETDEPTH
 					   nil		  ; STOPBEFORE


-- 
Alan Mackenzie (Nuremberg, Germany).

Message #13 received at 43481 <at> debbugs.gnu.org (full text, mbox):

From: Campbell Barton <ideasman42 <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43481 <at> debbugs.gnu.org
Subject: Re: bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting
 a new-line into the previous comment
Date: Thu, 26 Nov 2020 15:58:20 +1100

Hi Alan, thanks for fixing this,

Tested this both with `emacs -Q` and my personal (evil) config.

When your fix is applied, in both cases this works as expected.

On 11/25/20 2:02 AM, Alan Mackenzie wrote:
> Hello, Campbell.
> 
> Thank you indeed for taking the trouble to report this bug.
> 
> On Fri, Sep 18, 2020 at 09:38:16 +1000, Campbell Barton wrote:
>> Running 'c-context-line-break' sometimes adds the line break to the
>> previous comment, this seems to depend on the internal state
>> since it doesn't happen every time.
> 
> Yes.  The internal state it depends on is a cache for things like
> c-literal-limits (as you point out below).  To make the bug show itself,
> first type a space in the "A" comment somewhere (which clears the cache
> entries for any points after the place of the change), then move point
> into the B comment and type M-j.
> 
>> Tested in 27.1, and current master, this has been an issue for some
>> years IIRC.
> 
>> Take this example C file:
> 
>> ---- BEGIN `example.c`
>> /*
>>   * A
>>   */
> 
>> /*
>>   * B
>>   */
>> ---- END
> 
>> - Move the cursor the end-of-line above 'A'.
>> - M-x, c-context-line-break
> 
>> ----  `example.c` (with newline above 'A', as expected).
>> /*
>>   *
>>   * A
>>   */
> 
>> /*
>>   * B
>>   */
>> ---- END
> 
> [ .... ]
> 
>> ----
> 
>> I looked into the bug and this is caused by 'c-literal-limits'
>> returning an invalid range (where the beginning is correct, but the
>> end is the end of the previous comment, instead of the end of the
>> current comment).
> 
> Thank you very much indeed for taking the debugging so far.  That was
> exceptionally helpful.
> 
> What was happening was CC Mode read a cache entry, and because there was
> no entry for the "B" comment, got that for the "A" comment.  It later
> wrongly used the END element of that cache entry, without testing
> properly that it was valid.
> 
>> Printing 'c-literal-limits' before calling 'c-context-line-break'
>> shows this error, temporarily advising 'c-literal-limits' to return
>> the beginning/end of the comment is a workaround which
>> gives the 'EXPECTED RESULT'.
> 
> Yes.
> 
>> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
>> cairo version 1.17.3)
>>   of 2020-08-29 built on juergen
>> Windowing system distributor 'The X.Org Foundation', version
>> 11.0.12009000
>> System Description: Arch Linux
> 
> [ .... ]
> 
> Would you please try the following patch in CC Mode.  After applying it,
> you need byte compile only cc-engine.el (which is in
> emacs/lisp/progmodes/).  In the unlikely event you would like any help
> with the patching or byte compilation, feel free to send me private
> email.
> 
> Having applied it, please test out the problem in your real code, and
> confirm that the bug is, in fact, fixed, or alternatively tell us that
> there are still glitches with it.  Thanks!
> 
> 
> 
> diff -r 4cdd79795247 cc-engine.el
> --- a/cc-engine.el	Sun Nov 15 10:19:11 2020 +0000
> +++ b/cc-engine.el	Tue Nov 24 14:53:07 2020 +0000
> @@ -3152,7 +3152,7 @@
>   		      ((nth 7 s) 'c++)
>   		      (t 'c)))
>   	    (setq start (nth 8 s))
> -	    (unless end
> +	    (unless (and end (>= end here))
>   	      (setq s1 (parse-partial-sexp here (point-max)
>   					   nil		  ; TARGETDEPTH
>   					   nil		  ; STOPBEFORE
> 
> 

Message #18 received at 43481-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Campbell Barton <ideasman42 <at> gmail.com>
Cc: 43481-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting
 a new-line into the previous comment
Date: Thu, 26 Nov 2020 11:43:14 +0000

Hello, Campbell.

On Thu, Nov 26, 2020 at 15:58:20 +1100, Campbell Barton wrote:
> Hi Alan, thanks for fixing this,

> Tested this both with `emacs -Q` and my personal (evil) config.

> When your fix is applied, in both cases this works as expected.

Thanks indeed for testing this.  I have committed the fix to the
emacs-27 branch at savannah, and am closing the bug with this post.

-- 
Alan Mackenzie.

Message #26 received at 43481-done <at> debbugs.gnu.org (full text, mbox):

From: Campbell Barton <ideasman42 <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 43481-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting
 a new-line into the previous comment
Date: Fri, 27 Nov 2020 11:11:44 +1100

Great, any reason this isn't in master?

On 11/26/20 10:43 PM, Alan Mackenzie wrote:
> Hello, Campbell.
> 
> On Thu, Nov 26, 2020 at 15:58:20 +1100, Campbell Barton wrote:
>> Hi Alan, thanks for fixing this,
> 
>> Tested this both with `emacs -Q` and my personal (evil) config.
> 
>> When your fix is applied, in both cases this works as expected.
> 
> Thanks indeed for testing this.  I have committed the fix to the
> emacs-27 branch at savannah, and am closing the bug with this post.
> 

Message #29 received at 43481 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Campbell Barton <ideasman42 <at> gmail.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 43481 <at> debbugs.gnu.org
Subject: Re: bug#43481: 27.1; cc-mode's c-context-line-break fails,
 inserting a new-line into the previous comment
Date: Fri, 27 Nov 2020 08:01:23 +0100

Campbell Barton <ideasman42 <at> gmail.com> writes:

> Great, any reason this isn't in master?
>

emacs-27 gets merged to master on a regular basis.

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.