Re: cc-mode adds newlines

[Alan Mackenzie]

[cc's have been changed]

Hi, Andries

On Sun, 21 Nov 2004, Andries Brouwer wrote:

>On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote:

>> An equally valid argument is that of the programmer who hacks through
>> the night and sets off a build (which takes several hours to
>> complete), goes home for some sleep, then comes back into the office
>> the following afternoon.  He then finds that the build failed for lack
>> of a final newline in one of the files.  Then he expostulates "FAQ!
>> Why couldn't that stupid editor have put that stupid newline in for
>> me?".

>That is a phantasy argument.
>Old compilers just accept the C source without final newline
>without any complaint. Some newer pedantic ones print a warning.

Maybe you're right here.  I don't know.

I've had a search through the archives.  I found your bug report in
gnu.emacs.bug recently, and a previous bug report (strangely enough, with
exactly the same subject, "cc-mode adds newlines" ;-), from
Heinrich Rommerskirchen <address@hidden> on Thu, 23
Jan 2003 13:17:12.  Maybe you've read through that thread already.  That
also lead to discussion on the CC Mode mailing list (archived on
<http://cc-mode.sourceforge.net> somewhere), which led to the
introduction of `c-require-final-newline'.

Heinrich Rommerskirchen's complaint was that c-mode silently set
require-final-newline to t without him being able to do anything about
it.  c-require-final-newline was the answer to that, giving people a way
to "do something about it".  It was given the default value ((c-mode . t)
(c++-mode .t) (objc-mode .t)) so as not to change the behaviour for users
used to the old way.

[ .... ]

>I have been using C for thirty years or so.

In which case, change my suggestions yesterday from "a disco" and "a game
of squash" to "a concert" and "a game of bowls".  ;-).  I've been using C
for about fifteen years, and I've been working on CC Mode for about three
years.

>> >In this case of newlines emacs considers itself as final authority. That
>> >is a serious bug. It must ask by default.

>> No.  It is _your_ copy of Emacs, and it is _your_ choice how you
>> configure it.  You can actually set Emacs up to ask about
>> final-newlines first (see the Emacs manual, page "Saving", then use
>> that information to set c-require-final-newline), but you've probably
>> found that out already.

>That is a phantasy argument. If emacs dumps core when I do something,
>and there is a variable do-not-dump-core you cannot point out the
>existence of the variable to dismiss the bug.

Of course not.  Emacs dumping core (and it does happen) is absolutely a
bug, to be fixed.  Adding terminal newlines is a (mis)feature of dubious
value.  They're essentially different things.

>The alist c-require-final-newline was an extremely poor design decision.
>The single variable require-final-newline is excellent, especially if
>the default is ask.

The single variable require-final-newline was what led to Heinrich
Rommerskirchen's difficulties.  c-require-final-newline was the solution
(or "solution").  Before that, c-mode silently set require-final-newline
to t, and the only remedy was to write a hook function.  That was surely
worse.  As from CC Mode 5.30, you can fix this by setting a customization
variable.

>It is very poor design to add switches and variables just because
>it is a logical possibility that someone might want it.

In this case, somebody (who had the same problem as you) actually needed
it.  Maybe the solution wasn't optimal.

>It is not true that emacs is getting better and better as the number of
>variables that can be customised increases.

That's a whole different discussion.  ;-)  But it's worth pointing out
that when Emacs 21.1 came out, it had the "fringe" to the left and right
of each frame, and that was one of the few features that could not be
turned off by a customisation variable.  gnu.emacs.help was flooded with
requests "how do I turn this damn thing off?".

>> I think your complaint here is that you didn't know about the setting,
>> and had no reason to suspect it might exist, and therefore no reason
>> to spend weeks meticulously searching through the manual for anything
>> random which might mess up your files.  That's a fair complaint.

>Not precisely. The (stupid, buggy) variable that was added later does
>not yet exist in my version of emacs.  For me the fastest would have
>been to save the file, rename it, delete the final newline, rename it
>back.  Silly kludges showing the brokenness of emacs.

That's somewhat unfair.  `require-final-newline' is something that, with
the benefit of hindsight, was perhaps a bad idea.  Having major modes
setting it was worse.  But if the Emacs developers hadn't put in things
like that, most of which have proven their worth, Emacs wouldn't be what
it is.

Please read through all the archives I mentioned above (if you haven't
done so already), mull over all the issues, and if you still think things
could be improved make a concrete suggestion.  Either
<address@hidden> or <address@hidden> would be the right place
to send this.

>> It's also fair for me to ask, did you suffer any actual damage from
>> this terminating newline?  Something like the source file being an
>> input to some scriptfile, rather than just being compiled, and that
>> script fouling up?

>Yes. I needed a file without trailing newline.

OK.  Set c-require-final-newline to ((c-mode . ask) (c++-mode . ask)
(objc-mode . ask)).  You can do this either through M-x customize-group
<CR> C <CR>, etc., or by putting it by hand into one of your hook
functions in your .emacs file.  Then, at the very least, _your_ Emacs
will work properly.

>> >It is not true that all dialects of C require a final newline.

>> Yes, but _some_ of them do, and more importantly the C standard does.

>But again - that is almost irrelevant.
>Emacs must enable me to do what I want to or need to do.
>It is nice if it warns me when it thinks something might be wrong.

Somebody, sometime, wanted or needed the final newline inserted
automatically.  She got that.  This feature is now in such a mess that
it's difficult (or impossible) to fix so that it's right for everybody.

>If emacs thinks that the file being edited perhaps is a C program
>(for example because the name ends in .c), and moreover that I
>perhaps want to create a file that satisfies the C99 standard,
>then it should warn. It should not do anything at all on its own accord
>behind my back.

I can only apologise for myself and on behalf of the CC Mode maintainer
(Martin Stjernholm) and the Emacs developers as a body.  We don't get
everything right every time.

>Andries

-- 
Alan Mackenzie (Munich, Germany)