bug#26049: 25.2; Extra lines not added to comment

[Antonin Houska <ah@cybertec.at>]

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