unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#26049: 25.2; Extra lines not added to comment
@ 2017-03-10 13:41 Antonin Houska
  2017-03-28  3:29 ` npostavs
  0 siblings, 1 reply; 9+ messages in thread
From: Antonin Houska @ 2017-03-10 13:41 UTC (permalink / raw)
  To: 26049

[-- Attachment #1: Type: text/plain, Size: 5402 bytes --]


Even though I have the following customizations in place

 '(comment-multi-line t)
 '(comment-style (quote extra-line))

comment-region command produces this

/* some comment */

rather than this

/*
 * some comment
 */

Attached is a patch that I use to fix the issue on my workstation. Besides
fixing the (supposed) off-by-one error, the patch also removes trailing
whitespace from the initial line of the comment ("/* "). (My knowledge of
Elisp is not too advanced so I wonder if there's simpler way to trim
whitespace from a string.)




In GNU Emacs 25.2.3 (x86_64-suse-linux-gnu, X toolkit, Xaw scroll bars)
 of 2017-03-10 built on linux-j735
Repository revision: 6e788ef0e262fafc014c21f4ad52cc5dc9f1715b
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	openSUSE Leap 42.1 (x86_64)

Configured using:
 'configure --prefix=/home/ah/emacs 'CC=ccache cc''

Configured features:
XPM JPEG TIFF GIF PNG SOUND NOTIFY GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $EMACSLOADPATH: :/home/ah/repos/pgqa/lisp/pgqa
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
Loading delsel...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/home/ah/emacs/share/emacs/25.2/lisp/progmodes/ada-xref hides /home/ah/repos/elpa/packages/ada-mode/ada-xref
/home/ah/emacs/share/emacs/25.2/lisp/progmodes/ada-stmt hides /home/ah/repos/elpa/packages/ada-mode/ada-stmt
/home/ah/emacs/share/emacs/25.2/lisp/progmodes/ada-prj hides /home/ah/repos/elpa/packages/ada-mode/ada-prj
/home/ah/emacs/share/emacs/25.2/lisp/progmodes/ada-mode hides /home/ah/repos/elpa/packages/ada-mode/ada-mode
/home/ah/repos/elpa/packages/ada-mode/ada-ref-man hides /home/ah/repos/elpa/packages/ada-ref-man/ada-ref-man
/home/ah/emacs/share/emacs/25.2/lisp/emacs-lisp/cl-generic hides /home/ah/repos/elpa/packages/cl-generic/cl-generic
/home/ah/emacs/share/emacs/25.2/lisp/emacs-lisp/cl-lib hides /home/ah/repos/elpa/packages/cl-lib/cl-lib
/home/ah/emacs/share/emacs/25.2/lisp/obsolete/crisp hides /home/ah/repos/elpa/packages/crisp/crisp
/home/ah/emacs/share/emacs/25.2/lisp/obsolete/landmark hides /home/ah/repos/elpa/packages/landmark/landmark
/home/ah/emacs/share/emacs/25.2/lisp/net/pinentry hides /home/ah/repos/elpa/packages/pinentry/pinentry
/home/ah/emacs/share/emacs/25.2/lisp/emacs-lisp/seq hides /home/ah/repos/elpa/packages/seq/seq
/home/ah/repos/elpa/packages/all/all hides /home/ah/repos/elpa/packages/company/test/all
/home/ah/emacs/share/emacs/25.2/lisp/indent hides /home/ah/repos/elpa/packages/js2-mode/tests/indent
/home/ah/repos/elpa/packages/load-relative/test/install-pkgs hides /home/ah/repos/elpa/packages/loc-changes/test/install-pkgs
/home/ah/repos/elpa/packages/loc-changes/test/test-basic hides /home/ah/repos/elpa/packages/test-simple/test/test-basic

Features:
(shadow sort mail-extr warnings emacsbug message dired format-spec
rfc822 mml mml-sec password-cache epg gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils
cc-styles cc-align cc-engine cc-vars cc-defs windmove delsel cus-start
cus-load go-mode-autoloads ggtags etags xref cl-seq project eieio
eieio-core cl-macs compile comint ansi-color ring ewoc finder-inf
package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer 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 inotify dynamic-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 132187 8058)
 (symbols 48 24578 0)
 (miscs 40 57 129)
 (strings 32 28089 5577)
 (string-bytes 1 861163)
 (vectors 16 18787)
 (vector-slots 8 538382 3672)
 (floats 8 272 74)
 (intervals 56 204 0)
 (buffers 976 20)
 (heap 1024 37606 923))
-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: comment_extra_line.diff --]
[-- Type: text/x-diff, Size: 1510 bytes --]

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
new file mode 100644
index 1af8929..75dbb07
*** a/lisp/newcomment.el
--- b/lisp/newcomment.el
*************** the region rather than at left margin."
*** 1139,1144 ****
--- 1139,1149 ----
  
  	  ;; make the leading and trailing lines if requested
  	  (when lines
+ 	    ;; Trim trailing whitespace from cs if there's some.
+ 	    (let ((wp-pos (string-match "\\s-+$" cs)))
+ 	      (if wp-pos
+ 		  (setq cs (substring cs 0 wp-pos))))
+ 
  	    (let ((csce
  		   (comment-make-extra-lines
  		    cs ce ccs cce min-indent max-indent block)))
*************** changed with `comment-style'."
*** 1209,1215 ****
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (search-forward "\n" end t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))
--- 1214,1222 ----
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (search-forward
!                                              "\n"
!                                              (min (1+ end) (point-max)) t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-03-10 13:41 bug#26049: 25.2; Extra lines not added to comment Antonin Houska
@ 2017-03-28  3:29 ` npostavs
  2017-03-28 12:52   ` Antonin Houska
  0 siblings, 1 reply; 9+ messages in thread
From: npostavs @ 2017-03-28  3:29 UTC (permalink / raw)
  To: Antonin Houska; +Cc: 26049

Antonin Houska <ah@cybertec.at> writes:

> Even though I have the following customizations in place
>
>  '(comment-multi-line t)
>  '(comment-style (quote extra-line))
>
> comment-region command produces this
>
> /* some comment */
>
> rather than this
>
> /*
>  * some comment
>  */
>
> Attached is a patch that I use to fix the issue on my workstation. Besides
> fixing the (supposed) off-by-one error, the patch also removes trailing
> whitespace from the initial line of the comment ("/* "). (My knowledge of
> Elisp is not too advanced so I wonder if there's simpler way to trim
> whitespace from a string.)
>

You can use use `string-trim-right' from subr-x.

>   	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
>   		  (<= (point) end))
>   	   (or block (not (string= "" comment-end)))
> ! 	   (or block (progn (goto-char beg) (search-forward
> !                                              "\n"
> !                                              (min (1+ end) (point-max)) t)))))

Maybe (re-search-forward "$" end t) is better?  It's a bit unclear to me
what exactly all those tests are looking for.  That code could use some
comments...





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-03-28  3:29 ` npostavs
@ 2017-03-28 12:52   ` Antonin Houska
  2017-03-29  2:25     ` npostavs
  0 siblings, 1 reply; 9+ messages in thread
From: Antonin Houska @ 2017-03-28 12:52 UTC (permalink / raw)
  To: npostavs; +Cc: 26049

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

npostavs@users.sourceforge.net wrote:

> Antonin Houska <ah@cybertec.at> writes:

> > Even though I have the following customizations in place
> >
> >  '(comment-multi-line t)
> >  '(comment-style (quote extra-line))
> >
> > comment-region command produces this
> >
> > /* some comment */
> >
> > rather than this
> >
> > /*
> >  * some comment
> >  */
> >
> > Attached is a patch that I use to fix the issue on my workstation. Besides
> > fixing the (supposed) off-by-one error, the patch also removes trailing
> > whitespace from the initial line of the comment ("/* "). (My knowledge of
> > Elisp is not too advanced so I wonder if there's simpler way to trim
> > whitespace from a string.)
> >

> You can use use `string-trim-right' from subr-x.

Thanks.

> >   	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
> >   		  (<= (point) end))
> >   	   (or block (not (string= "" comment-end)))
> > ! 	   (or block (progn (goto-char beg) (search-forward
> > !                                              "\n"
> > !                                              (min (1+ end) (point-max)) t)))))

> Maybe (re-search-forward "$" end t) is better?  It's a bit unclear to me
> what exactly all those tests are looking for.  That code could use some
> comments...

I've just verified your approach - it does work too.

Yes, comments would be useful. For the test we're fixing now, the reason seems
to be to ensure that the last line of the comment can be broken w/o affecting
the following (non-comment) text. Perhaps someone else might come up with
better wording.

New version of the patch is attached.

-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: newcomment_v2.diff --]
[-- Type: text/x-diff, Size: 1518 bytes --]

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
new file mode 100644
index 1af8929..f2d9735
*** a/lisp/newcomment.el
--- b/lisp/newcomment.el
***************
*** 69,74 ****
--- 69,77 ----
  
  ;;; Code:
  
+ (eval-when-compile
+   (require 'subr-x))
+ 
  ;;;###autoload
  (defalias 'indent-for-comment 'comment-indent)
  ;;;###autoload
*************** the region rather than at left margin."
*** 1139,1144 ****
--- 1142,1150 ----
  
  	  ;; make the leading and trailing lines if requested
  	  (when lines
+ 	    ;; Trim trailing whitespace from cs if there's some.
+             (setq cs (string-trim cs))
+ 
  	    (let ((csce
  		   (comment-make-extra-lines
  		    cs ce ccs cce min-indent max-indent block)))
*************** changed with `comment-style'."
*** 1209,1215 ****
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (search-forward "\n" end t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))
--- 1215,1221 ----
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (re-search-forward "$" end t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-03-28 12:52   ` Antonin Houska
@ 2017-03-29  2:25     ` npostavs
  2017-03-29  6:54       ` Antonin Houska
  0 siblings, 1 reply; 9+ messages in thread
From: npostavs @ 2017-03-29  2:25 UTC (permalink / raw)
  To: Antonin Houska; +Cc: 26049

Antonin Houska <ah@cybertec.at> writes:
>
>> >   	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
>> >   		  (<= (point) end))
>> >   	   (or block (not (string= "" comment-end)))
>> > ! 	   (or block (progn (goto-char beg) (search-forward
>> > !                                              "\n"
>> > !                                              (min (1+ end) (point-max)) t)))))
>
>> Maybe (re-search-forward "$" end t) is better?  It's a bit unclear to me
>> what exactly all those tests are looking for.  That code could use some
>> comments...
>
> I've just verified your approach - it does work too.

"$" also matches at the end of buffer even if it doesn't end in newline
(which is a very marginal corner case, I just happened to notice it
because I didn't hit RET in my test buffer).

> + 	    ;; Trim trailing whitespace from cs if there's some.
> +             (setq cs (string-trim cs))

This would trim leading whitespace too, do we want that?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-03-29  2:25     ` npostavs
@ 2017-03-29  6:54       ` Antonin Houska
  2017-09-23  7:41         ` Antonin Houska
  0 siblings, 1 reply; 9+ messages in thread
From: Antonin Houska @ 2017-03-29  6:54 UTC (permalink / raw)
  To: npostavs; +Cc: 26049

npostavs@users.sourceforge.net wrote:

> Antonin Houska <ah@cybertec.at> writes:
> >
> >> >   	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
> >> >   		  (<= (point) end))
> >> >   	   (or block (not (string= "" comment-end)))
> >> > ! 	   (or block (progn (goto-char beg) (search-forward
> >> > !                                              "\n"
> >> > !                                              (min (1+ end) (point-max)) t)))))
> >
> >> Maybe (re-search-forward "$" end t) is better?  It's a bit unclear to me
> >> what exactly all those tests are looking for.  That code could use some
> >> comments...
> >
> > I've just verified your approach - it does work too.

> "$" also matches at the end of buffer even if it doesn't end in newline
> (which is a very marginal corner case, I just happened to notice it
> because I didn't hit RET in my test buffer).

IMO this is ok. If the 'extra-line value of `comment-style' tells that the
comment should look like this

/*
 * some comment
 */

it'd be kind of inconsistend if just a missing RET at the end of buffer
resulted in this

/* some comment */

which effectively means discrepancy from the customization setting.

(The initial version of my patch ignored the `extra-line' setting in this
special case, but it was a thinko rather than intention.)

> 
> > + 	    ;; Trim trailing whitespace from cs if there's some.
> > +             (setq cs (string-trim cs))
> 
> This would trim leading whitespace too, do we want that?

I haven't noticed any related issue but yes, string-trim-right is more
precise. If the (supposedly accidental) leading space should be removed from
the value of `comment-start', it should probably happen elsewhere in the code
because it's not specific to the 'extra-line style.

-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-03-29  6:54       ` Antonin Houska
@ 2017-09-23  7:41         ` Antonin Houska
  2017-09-23 14:37           ` Noam Postavsky
  0 siblings, 1 reply; 9+ messages in thread
From: Antonin Houska @ 2017-09-23  7:41 UTC (permalink / raw)
  To: npostavs; +Cc: 26049

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

Antonin Houska <ah@cybertec.at> wrote:

> npostavs@users.sourceforge.net wrote:
> 
> > Antonin Houska <ah@cybertec.at> writes:
> > >
> > >> >   	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
> > >> >   		  (<= (point) end))
> > >> >   	   (or block (not (string= "" comment-end)))
> > >> > ! 	   (or block (progn (goto-char beg) (search-forward
> > >> > !                                              "\n"
> > >> > !                                              (min (1+ end) (point-max)) t)))))
> > >
> > >> Maybe (re-search-forward "$" end t) is better?  It's a bit unclear to me
> > >> what exactly all those tests are looking for.  That code could use some
> > >> comments...
> > >
> > > I've just verified your approach - it does work too.
> 
> > "$" also matches at the end of buffer even if it doesn't end in newline
> > (which is a very marginal corner case, I just happened to notice it
> > because I didn't hit RET in my test buffer).
> 
> IMO this is ok. If the 'extra-line value of `comment-style' tells that the
> comment should look like this
> 
> /*
>  * some comment
>  */
> 
> it'd be kind of inconsistend if just a missing RET at the end of buffer
> resulted in this
> 
> /* some comment */
> 
> which effectively means discrepancy from the customization setting.
> 
> (The initial version of my patch ignored the `extra-line' setting in this
> special case, but it was a thinko rather than intention.)
> 
> > 
> > > + 	    ;; Trim trailing whitespace from cs if there's some.
> > > +             (setq cs (string-trim cs))
> > 
> > This would trim leading whitespace too, do we want that?
> 
> I haven't noticed any related issue but yes, string-trim-right is more
> precise. If the (supposedly accidental) leading space should be removed from
> the value of `comment-start', it should probably happen elsewhere in the code
> because it's not specific to the 'extra-line style.

The next version of the patch (with string-trim replaced with
string-trim-right) is below. Is there anything else I should do?

-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: newcomment.diff --]
[-- Type: text/x-diff, Size: 1524 bytes --]

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
new file mode 100644
index 1af8929..f2d9735
*** a/lisp/newcomment.el
--- b/lisp/newcomment.el
***************
*** 69,74 ****
--- 69,77 ----
  
  ;;; Code:
  
+ (eval-when-compile
+   (require 'subr-x))
+ 
  ;;;###autoload
  (defalias 'indent-for-comment 'comment-indent)
  ;;;###autoload
*************** the region rather than at left margin."
*** 1139,1144 ****
--- 1142,1150 ----
  
  	  ;; make the leading and trailing lines if requested
  	  (when lines
+ 	    ;; Trim trailing whitespace from cs if there's some.
+             (setq cs (string-trim-right cs))
+ 
  	    (let ((csce
  		   (comment-make-extra-lines
  		    cs ce ccs cce min-indent max-indent block)))
*************** changed with `comment-style'."
*** 1209,1215 ****
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (search-forward "\n" end t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))
--- 1215,1221 ----
  	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
  		  (<= (point) end))
  	   (or block (not (string= "" comment-end)))
! 	   (or block (progn (goto-char beg) (re-search-forward "$" end t)))))
  
      ;; don't add end-markers just because the user asked for `block'
      (unless (or lines (string= "" comment-end)) (setq block nil))

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-09-23  7:41         ` Antonin Houska
@ 2017-09-23 14:37           ` Noam Postavsky
  2017-11-06 10:14             ` Antonin Houska
  0 siblings, 1 reply; 9+ messages in thread
From: Noam Postavsky @ 2017-09-23 14:37 UTC (permalink / raw)
  To: Antonin Houska; +Cc: 26049

tags 26049 + patch
quit

Antonin Houska <ah@cybertec.at> writes:

> The next version of the patch (with string-trim replaced with
> string-trim-right) is below. Is there anything else I should do?

Could you please add a commit message (see CONTRIBUTE under "Commit
messages" for conventions) and post a version produced via 'git
format-patch' (that way I can grab the patch + commit message
automagically).

Have you assigned copyright for Emacs?  (The patch is small enough to be
applied regardless, but if not you should add
"Copyright-paperwork-exempt: yes" to the commit message.)







^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-09-23 14:37           ` Noam Postavsky
@ 2017-11-06 10:14             ` Antonin Houska
  2017-11-07  0:07               ` Noam Postavsky
  0 siblings, 1 reply; 9+ messages in thread
From: Antonin Houska @ 2017-11-06 10:14 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 26049

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> tags 26049 + patch
> quit
> 
> Antonin Houska <ah@cybertec.at> writes:
> 
> > The next version of the patch (with string-trim replaced with
> > string-trim-right) is below. Is there anything else I should do?
> 
> Could you please add a commit message (see CONTRIBUTE under "Commit
> messages" for conventions) and post a version produced via 'git
> format-patch' (that way I can grab the patch + commit message
> automagically).

See below.

-- 
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Handle-single-line-comments-correctly-Bug-26049.patch --]
[-- Type: text/x-diff, Size: 1743 bytes --]

From e782404ce76c05076b794e9506049d7ed4c55663 Mon Sep 17 00:00:00 2001
From: Antonin Houska <ah@melesmeles.cz>
Date: Mon, 6 Nov 2017 09:59:07 +0100
Subject: [PATCH] Handle single-line comments correctly (Bug#26049)

* lisp/newcomment.el: the comment text had to contain at least one
line break for the ending extra line to be added. The behavior seems
more consistent if the end of the comment text is also considered a
line break.

While fixing this, also removed trailing white space from the comment
initial line (/*).

Copyright-paperwork-exempt: yes
---
 lisp/newcomment.el | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/newcomment.el b/lisp/newcomment.el
index 2e644c3a99..950f3c85b4 100644
--- a/lisp/newcomment.el
+++ b/lisp/newcomment.el
@@ -69,6 +69,9 @@
 
 ;;; Code:
 
+(eval-when-compile
+  (require 'subr-x))
+
 ;;;###autoload
 (defalias 'indent-for-comment 'comment-indent)
 ;;;###autoload
@@ -1141,6 +1144,9 @@ comment-region-internal
 
 	  ;; make the leading and trailing lines if requested
 	  (when lines
+	    ;; Trim trailing whitespace from cs if there's some.
+            (setq cs (string-trim-right cs))
+
 	    (let ((csce
 		   (comment-make-extra-lines
 		    cs ce ccs cce min-indent max-indent block)))
@@ -1211,7 +1217,7 @@ comment-region-default
 	   (progn (goto-char end) (end-of-line) (skip-syntax-backward " ")
 		  (<= (point) end))
 	   (or block (not (string= "" comment-end)))
-	   (or block (progn (goto-char beg) (search-forward "\n" end t)))))
+	   (or block (progn (goto-char beg) (re-search-forward "$" end t)))))
 
     ;; don't add end-markers just because the user asked for `block'
     (unless (or lines (string= "" comment-end)) (setq block nil))
-- 
2.12.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#26049: 25.2; Extra lines not added to comment
  2017-11-06 10:14             ` Antonin Houska
@ 2017-11-07  0:07               ` Noam Postavsky
  0 siblings, 0 replies; 9+ messages in thread
From: Noam Postavsky @ 2017-11-07  0:07 UTC (permalink / raw)
  To: Antonin Houska; +Cc: 26049

tags 26049 fixed
close 26049 26.1
quit

Antonin Houska <ah@cybertec.at> writes:

> Subject: [PATCH] Handle single-line comments correctly (Bug#26049)
>
> * lisp/newcomment.el: the comment text had to contain at least one
> line break for the ending extra line to be added. The behavior seems
> more consistent if the end of the comment text is also considered a
> line break.
>
> While fixing this, also removed trailing white space from the comment
> initial line (/*).
>
> Copyright-paperwork-exempt: yes

Thanks, I rephrased/reformatted the message a bit and pushed to
emacs-26.

[1: db949166ec]: 2017-11-06 19:01:19 -0500
  Handle single-line comments correctly (Bug#26049)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=db949166ecb9aeaa15aa41369a55b3ea6ceaa3b0





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-11-07  0:07 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-10 13:41 bug#26049: 25.2; Extra lines not added to comment Antonin Houska
2017-03-28  3:29 ` npostavs
2017-03-28 12:52   ` Antonin Houska
2017-03-29  2:25     ` npostavs
2017-03-29  6:54       ` Antonin Houska
2017-09-23  7:41         ` Antonin Houska
2017-09-23 14:37           ` Noam Postavsky
2017-11-06 10:14             ` Antonin Houska
2017-11-07  0:07               ` Noam Postavsky

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).