GNU bug report logs - #26049
25.2; Extra lines not added to comment

Previous Next

Package: emacs;

Reported by: Antonin Houska <ah <at> cybertec.at>

Date: Fri, 10 Mar 2017 16:05:02 UTC

Severity: normal

Tags: fixed, patch

Found in version 25.2

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Antonin Houska <ah <at> cybertec.at>
To: npostavs <at> users.sourceforge.net
Cc: 26049 <at> debbugs.gnu.org
Subject: bug#26049: 25.2; Extra lines not added to comment
Date: Wed, 29 Mar 2017 08:54:53 +0200
npostavs <at> users.sourceforge.net wrote:

> Antonin Houska <ah <at> 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




This bug report was last modified 7 years and 195 days ago.

Previous Next


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