bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Eli Zaretskii]

To reproduce:

  emacs -Q
  C-x C-f src/xdisp.c
  C-u 19 M-g g
  C-e

This should bring you to the end of this line in xdisp.c:

  along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */

It is the end of a comment.  Now do this:

  M-: (local-set-key "\C-m" 'c-context-line-break) RET

Then press RET.  I expect Emacs to open a new line, indent it
according to the context, and put point after the indentation.
Instead, the new line is inserted _before_ the point's line, and point
stays at the end of the comment as it was before.

This is a regression wrt Emacs 26.

I had this customization of RET in CC mode since about forever, and it
always worked like I expected.  Until Emacs 27.1.

Can this be fixed for Emacs 27.2, please?

In GNU Emacs 27.1.50 (build 107, i686-pc-mingw32)
 of 2020-11-23 built on HOME-C4E4A596F7
Repository revision: 2b1cec559202d5985b7431ffce943bf4b019fb95
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Recent messages:
Undo [3 times]
RET (translated from <return>) runs the command newline [2 times]
Making completion list...
c-context-line-break
RET (translated from <return>) runs the command c-context-line-break
Undo
user-error: You didn’t specify a function symbol
Type C-x 1 to delete the help window, C-M-v to scroll help.
 [2 times]
GNU Emacs 27.1.50 (build 107, i686-pc-mingw32) of 2020-11-23

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Help

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
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-print
time-date subr-x cl-extra seq byte-opt gv bytecomp byte-compile cconv
thingatpt help-fns radix-tree help-mode vc-git diff-mode easy-mmode
bug-reference cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars 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 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 w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 83507 9659)
 (symbols 48 10409 1)
 (strings 16 28014 2352)
 (string-bytes 1 925109)
 (vectors 16 14367)
 (vector-slots 8 178621 7676)
 (floats 8 39 54)
 (intervals 40 3254 13)
 (buffers 888 14))

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Eli Zaretskii]

merge 44823 43481
thanks

> Date: Mon, 23 Nov 2020 19:33:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> To reproduce:
> 
>   emacs -Q
>   C-x C-f src/xdisp.c
>   C-u 19 M-g g
>   C-e
> 
> This should bring you to the end of this line in xdisp.c:
> 
>   along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
> 
> It is the end of a comment.  Now do this:
> 
>   M-: (local-set-key "\C-m" 'c-context-line-break) RET
> 
> Then press RET.  I expect Emacs to open a new line, indent it
> according to the context, and put point after the indentation.
> Instead, the new line is inserted _before_ the point's line, and point
> stays at the end of the comment as it was before.
> 
> This is a regression wrt Emacs 26.
> 
> I had this customization of RET in CC mode since about forever, and it
> always worked like I expected.  Until Emacs 27.1.

I see someone already reported this 2 months ago.  Merging.

> Can this be fixed for Emacs 27.2, please?

Yes, please.

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Alan Mackenzie]

Hello, Eli.

On Mon, Nov 23, 2020 at 19:33:35 +0200, Eli Zaretskii wrote:
> To reproduce:

>   emacs -Q
>   C-x C-f src/xdisp.c
>   C-u 19 M-g g
>   C-e

> This should bring you to the end of this line in xdisp.c:

>   along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */

> It is the end of a comment.  Now do this:

>   M-: (local-set-key "\C-m" 'c-context-line-break) RET

> Then press RET.  I expect Emacs to open a new line, indent it
> according to the context, and put point after the indentation.
> Instead, the new line is inserted _before_ the point's line, and point
> stays at the end of the comment as it was before.

> This is a regression wrt Emacs 26.

> I had this customization of RET in CC mode since about forever, and it
> always worked like I expected.  Until Emacs 27.1.

> Can this be fixed for Emacs 27.2, please?

This is an off-by-one error, and was fixed in master with the following
commit:

commit 7574390099f0de11939a0e3626cf222b58863290
Author: Alan Mackenzie <acm@muc.de>
Date:   Thu Jun 25 17:07:16 2020 +0000

    CC Mode.  Fix an off by one error.  Fixes bug #41809

    * lisp/progmodes/cc-engine.el (c-full-pp-to-literal): Change > to >= (twice).

I can't remember why I didn't commit this to the emacs-27 branch.
Possibly it was too close to the release.

I'll cherry-pick it back to the emacs-27 branch.


> In GNU Emacs 27.1.50 (build 107, i686-pc-mingw32)
>  of 2020-11-23 built on HOME-C4E4A596F7
> Repository revision: 2b1cec559202d5985b7431ffce943bf4b019fb95
> Repository branch: emacs-27
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Eli Zaretskii]

> Date: Tue, 24 Nov 2020 16:22:46 +0000
> Cc: bug-gnu-emacs@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> commit 7574390099f0de11939a0e3626cf222b58863290
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Thu Jun 25 17:07:16 2020 +0000
> 
>     CC Mode.  Fix an off by one error.  Fixes bug #41809
> 
>     * lisp/progmodes/cc-engine.el (c-full-pp-to-literal): Change > to >= (twice).
> 
> I can't remember why I didn't commit this to the emacs-27 branch.
> Possibly it was too close to the release.
> 
> I'll cherry-pick it back to the emacs-27 branch.

Thanks!

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Alan Mackenzie]

Hello again, Eli.

On Tue, Nov 24, 2020 at 16:22:46 +0000, Alan Mackenzie wrote:
> On Mon, Nov 23, 2020 at 19:33:35 +0200, Eli Zaretskii wrote:
> > To reproduce:

> >   emacs -Q
> >   C-x C-f src/xdisp.c
> >   C-u 19 M-g g
> >   C-e

> > This should bring you to the end of this line in xdisp.c:

> >   along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */

> > It is the end of a comment.  Now do this:

> >   M-: (local-set-key "\C-m" 'c-context-line-break) RET

> > Then press RET.  I expect Emacs to open a new line, indent it
> > according to the context, and put point after the indentation.
> > Instead, the new line is inserted _before_ the point's line, and point
> > stays at the end of the comment as it was before.

> > This is a regression wrt Emacs 26.

> > I had this customization of RET in CC mode since about forever, and it
> > always worked like I expected.  Until Emacs 27.1.

> > Can this be fixed for Emacs 27.2, please?

> This is an off-by-one error, and was fixed in master with the following
> commit:

> commit 7574390099f0de11939a0e3626cf222b58863290
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Thu Jun 25 17:07:16 2020 +0000

>     CC Mode.  Fix an off by one error.  Fixes bug #41809

>     * lisp/progmodes/cc-engine.el (c-full-pp-to-literal): Change > to >= (twice).

> I can't remember why I didn't commit this to the emacs-27 branch.
> Possibly it was too close to the release.

> I'll cherry-pick it back to the emacs-27 branch.

DONE.  It appears now to be working.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44823: 27.1.50; c-context-line-break misbehaves at end of comment

[Eli Zaretskii]

> Date: Tue, 24 Nov 2020 16:39:29 +0000
> Cc: bug-gnu-emacs@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > commit 7574390099f0de11939a0e3626cf222b58863290
> > Author: Alan Mackenzie <acm@muc.de>
> > Date:   Thu Jun 25 17:07:16 2020 +0000
> 
> >     CC Mode.  Fix an off by one error.  Fixes bug #41809
> 
> >     * lisp/progmodes/cc-engine.el (c-full-pp-to-literal): Change > to >= (twice).
> 
> > I can't remember why I didn't commit this to the emacs-27 branch.
> > Possibly it was too close to the release.
> 
> > I'll cherry-pick it back to the emacs-27 branch.
> 
> DONE.  It appears now to be working.

Yes, it does.  Thanks.

I don't know whether to close this bug, because I merged it with
43481, which you seem to say is a different issue?