* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
@ 2020-09-17 23:38 Campbell Barton
2020-11-24 15:02 ` Alan Mackenzie
0 siblings, 1 reply; 6+ messages in thread
From: Campbell Barton @ 2020-09-17 23:38 UTC (permalink / raw)
To: 43481
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))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
2020-09-17 23:38 bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment Campbell Barton
@ 2020-11-24 15:02 ` Alan Mackenzie
2020-11-26 4:58 ` Campbell Barton
0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-11-24 15:02 UTC (permalink / raw)
To: Campbell Barton; +Cc: 43481
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
2020-11-24 15:02 ` Alan Mackenzie
@ 2020-11-26 4:58 ` Campbell Barton
2020-11-26 11:43 ` Alan Mackenzie
0 siblings, 1 reply; 6+ messages in thread
From: Campbell Barton @ 2020-11-26 4:58 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 43481
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
2020-11-26 4:58 ` Campbell Barton
@ 2020-11-26 11:43 ` Alan Mackenzie
2020-11-27 0:11 ` Campbell Barton
0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-11-26 11:43 UTC (permalink / raw)
To: Campbell Barton; +Cc: 43481-done
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
2020-11-26 11:43 ` Alan Mackenzie
@ 2020-11-27 0:11 ` Campbell Barton
2020-11-27 7:01 ` Robert Pluim
0 siblings, 1 reply; 6+ messages in thread
From: Campbell Barton @ 2020-11-27 0:11 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 43481-done
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment
2020-11-27 0:11 ` Campbell Barton
@ 2020-11-27 7:01 ` Robert Pluim
0 siblings, 0 replies; 6+ messages in thread
From: Robert Pluim @ 2020-11-27 7:01 UTC (permalink / raw)
To: Campbell Barton; +Cc: Alan Mackenzie, 43481
Campbell Barton <ideasman42@gmail.com> writes:
> Great, any reason this isn't in master?
>
emacs-27 gets merged to master on a regular basis.
Robert
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-11-27 7:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-17 23:38 bug#43481: 27.1; cc-mode's c-context-line-break fails, inserting a new-line into the previous comment Campbell Barton
2020-11-24 15:02 ` Alan Mackenzie
2020-11-26 4:58 ` Campbell Barton
2020-11-26 11:43 ` Alan Mackenzie
2020-11-27 0:11 ` Campbell Barton
2020-11-27 7:01 ` Robert Pluim
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).