Re: cc-mode adds newlines

[Andries Brouwer <Andries.Brouwer@cwi.nl>]

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

> >It is not the goal of an editor to force the user to write syntactically
> >correct programs.
> 
> Well, that is debateable.  I'd tend to agree with you, whilst pointing
> out that in this case, there was no "force" used [see below].
> 
> 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.

> >It is excellent if the editor helps the user, warns for things that
> >often are mistakes, etc. But the user is the final authority.
> 
> You'll note that, for example, CC Mode warns you about unterminated
> strings and unterminated comments.  [Don't laugh - before the days of
> syntax highlighting, unterminated comments were the utter devil to find -
> often the resulting source was syntactically valid, but the "else" bit of
> an "if" got commented out, for example.]

I have been using C for thirty years or so.

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

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.

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

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

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

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

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

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.

Andries