CC Mode

Luc Teirlinck <teirllm@...> wrote:

>        In my opinion this behaviour is unacceptable. If for some reason I
>        choose to create a file with no trailing newline, it is not
>        emacs's
>        business to change the file silently behind my back.

Just out of curiosity: Is there a case when that newline causes a
problem, or is it more a matter of principle?

> /.../  I now am convinced that by far the best solution is to use a
> user option c-require-final-newline, keeping t as the default.  It
> would not inconvenience in any way the majority of users for which
> this is the correct behavior (note that I do absolutely not contest
> this) and which are used to the present situation.

I can do that. Setting that variable is not something I would have
come up with myself since there's no language standard or similar that
mandates it. But it's long time legacy, so t is better left the
default.

Martin Stjernholm wrote:

   Luc Teirlinck <teirllm@...> wrote:

No he did not! (My interjection, Luc.)

   >        In my opinion this behaviour is unacceptable. If for some reason I
   >        choose to create a file with no trailing newline, it is not
   >        emacs's
   >        business to change the file silently behind my back.

I did not write the above quote.  I agree with the substance, but this
is not the way I formulated things.

   Just out of curiosity: Is there a case when that newline causes a
   problem, or is it more a matter of principle?

We may have lost contact with Heinrich, but I guess that if it did not
cause a problem, he would not have posted a bug report.  I myself did
not have a concrete problem (I responded to Heinrich's posting), but I
nevertheless can easily think of situations where one might want a
program without trailing newline.

For instance, one may need to check how some program one wrote handles
input that has no final newline.  (In other words the program without
trailing newline might be meant to test another program).

Secondly, unless I am mistaken, cc-mode is not just for C, but for "C
and related stuff", which could include interactive languages similar
to C.  I have seen people deliberate omitting the newline from the end
of files (while programming for interactive languages), because they
first wanted to see the previous output before executing the last
command.  (In the situation I am thinking of the newline-less command
got printed in the xterm and the user wanted at that stage to decide
whether to press the return key or not.)

As I already mentioned before, I have no objection whatsoever against
t being the default.  I even believe it should be.  I believe it is
clearly the right thing for most people in most situations.  At present
there are two problems: people should know about the fact that
cc-mode's behavior is different from Emacs' general default behavior
regarding final newlines and they should be able to override the
default (temporarily or permanently) in an easier way than with a hook
function and an anonymous lambda expression, given the fact that not
all C programmers know Lisp.

I believe that the c-require-final-newline solution, with t as
default, would accomplish both without any inconvenience to anybody
who does not care about avoiding final newlines.  It is consistent
with what sh-mode does.  The fact that there would be a documented
user option showing up in the customization buffer would not only be
useful to people who want to temporarily or permanently override, but
would also be informative to people who like the default behavior, but
would otherwise not even know that it was there.  (If they do not know
that cc-mode is silently correcting their errors, they might not know
that they are making errors to begin with.)

   Setting that variable is not something I would have
   come up with myself since there's no language standard or similar that
   mandates it.

Of course not, but sometimes you have to "do the wrong thing" for
experimentation purposes, so I do not believe that an editor should
try to take away the user's ability to break standards.  Also, which
language's standard?  cc-mode seems rather general.

Sincerely,

Luc.

Luc Teirlinck <teirllm@...> wrote:

>    Setting that variable is not something I would have
>    come up with myself since there's no language standard or similar that
>    mandates it.
> 
> Of course not, but sometimes you have to "do the wrong thing" for
> experimentation purposes, so I do not believe that an editor should
> try to take away the user's ability to break standards.  Also, which
> language's standard?  cc-mode seems rather general.

You misunderstood me. I said that there is no language standard that
mandates a trailing newline (in none of the languages supported by CC
Mode), so CC Mode really has no business meddling with
require-final-newline at all. If I had originally written that code
I'd never have touched it.

Martin Stjernholm <mast@...> wrote:

   You misunderstood me. I said that there is no language standard that
   mandates a trailing newline (in none of the languages supported by CC
   Mode), so CC Mode really has no business meddling with
   require-final-newline at all. If I had originally written that code
   I'd never have touched it.

Indeed, I misunderstood you.  I thought that in your previous quote:

   Setting that variable is not something I would have
   come up with myself since there's no language standard or similar that
   mandates it.

"that variable" referred to the `c-require-final-newline' I was
proposing instead of to `require-final-newline' itself.  That in turn
made me completely misunderstand your entire message.  Sorry.

So it seems to me that we agree: cc-mode should not have touched
require-final-newline to begin with, but given the fact that it has
been doing so for a long time, it would surprise and confuse plenty of
users if we just set it back.

There are two solutions here.  I personally lean toward the first one,
the one we have been discussing.

That solution is to define a user option c-require-final-newline, with
default t, so with no change in behavior for existing users.  This
user option would turn up in the relevant customization buffer and
would be (briefly) mentioned in the mode documentation string and the
cc-mode manual.

This completely takes care of my own two objections: 

Firstly, the fact that standard Emacs behavior and even possibly
explicit user customization (say to 'maybe) gets overridden without
any mention anywhere whatsoever (unless I missed something), except in
the source code in Elisp.

Secondly, the fact that having to use hook functions to keep a user
option constant in all situations is unnatural and overly complex for
the purpose: hook functions are supposed to accomplish exactly the
opposite, make the option depend on the situation.

There is a second possible solution.

Since maybe you do not read gnu.emacs.bug, I may first have to
summarize additional input there:

    Benjamin Riefenstahl <Benjamin.Riefenstahl@...> wrote:

	Richard Stallman <rms@...> writes:

	Perhaps c-mode alone should set require-final-newline, and
	not the other modes of CC mode.

    I did some research: C++ also requires the final newline.  Java
    doesn't as far as I can make out from the language specs.  The
    Objective-C language manual doesn't talk about source code format,
    but
    it stresses C compatibility.  I haven't looked at CORBA IDL and
    Pike.

As the default has been t all over cc-mode for quite a while, I
personally believe it might be better to leave it that way.  I also
believe that a uniform default for all of cc-mode keeps things
simpler.  If users want different values in different modes, they can
use hooks.  This is what hooks are truly for.  Users who want to keep
the value constant all over Emacs could just set
c-require-final-newline to nil, without being forced to use hooks in a
situation that should not call for that.

There seems to be some disagreement between you and Benjamin on what
various standards require (unless I am again misunderstanding things),
but if one would pick the first solution, then this would become
irrelevant to the issue at hand.

Sincerely,

Luc.

Hi Luc, Martin,


> Martin Stjernholm <mast@...> wrote:
>    You misunderstood me. I said that there is no language standard
>    that mandates a trailing newline (in none of the languages
>    supported by CC Mode),

> Benjamin Riefenstahl <Benjamin.Riefenstahl@...> wrote:
>>     I did some research: C++ also requires the final newline.  Java
>>     doesn't as far as I can make out from the language specs.  The
>>     Objective-C language manual doesn't talk about source code
>>     format, but it stresses C compatibility.  I haven't looked at
>>     CORBA IDL and Pike.

I don't want to start a fight here.  Fact is the following statement
in C90 and C99 (ISO/IEC 9899:1999, Programming languages - C), section
5.1.1.2, Translation phases, clause 2:

  [...] A source file that is not empty shall end in a new-line
  character, which shall not be immediately preceded by a backslash
  character before any such splicing takes place.

Similar wording in C++98 (ISO/IEC 14882:1998, Programming languages -
C), section 2.1, Phases of translation, clause 2:

  [...] If a source file that is not empty does not end in a new-line
  character, or ends in a new-line character immediately preceded by a
  backslash character, the behaviour is undefined.


Language lawyers could in theory claim some virtual model of source
files where this statement automatically becomes irrelevant.  I don't
think that such an interpretation is intended here.  Besides it is a
fact (and I know that from experience) that compilers have required
the trailing newline or mis-behaved when it wasn't present.


Luc Teirlinck <teirllm@...> writes:
> As the default has been t all over cc-mode for quite a while, I
> personally believe it might be better to leave it that way.  I also
> believe that a uniform default for all of cc-mode keeps things
> simpler.  If users want different values in different modes, they
> can use hooks.  This is what hooks are truly for.  Users who want to
> keep the value constant all over Emacs could just set
> c-require-final-newline to nil, without being forced to use hooks in
> a situation that should not call for that.

What would be the difference between require-final-newline and
c-require-final-newline?

I get the feeling that a bit more documentation for
require-final-newline and possibly a note in the cc-mode documentation
is all that is really needed.


so long, benny

Benjamin Riefenstahl wrote:
   
   What would be the difference between require-final-newline and
   c-require-final-newline?

c-require-final-newline would only apply in cc-mode.  Its only purpose
would be to allow users to override cc-mode's setting of
require-final-newline without having to use a hook (like sh-mode does).

Sincerely,

Luc.

Benjamin Riefenstahl <Benjamin.Riefenstahl@...> wrote:

> I don't want to start a fight here.  Fact is the following statement
> in C90 and C99 (ISO/IEC 9899:1999, Programming languages - C), section
> 5.1.1.2, Translation phases, clause 2:
> 
>   [...] A source file that is not empty shall end in a new-line
>   character, which shall not be immediately preceded by a backslash
>   character before any such splicing takes place.
> 
> Similar wording in C++98 (ISO/IEC 14882:1998, Programming languages -
> C), section 2.1, Phases of translation, clause 2:
> 
>   [...] If a source file that is not empty does not end in a new-line
>   character, or ends in a new-line character immediately preceded by a
>   backslash character, the behaviour is undefined.

Thanks for pointing this out. I need to read up on the standards
better. ;) This explains the original code; CC Mode indeed has
business meddling with that variable in some of its languages (but not
all of them).

> What would be the difference between require-final-newline and
> c-require-final-newline?

c-require-final-newline will be an alist that specifies the value to
give to require-final-newline at mode initialization for each language
in CC Mode, much like sh-require-final-newline as Luc suggested. The
default value causes require-final-newline to be t in the languages
that mandates a final newline. It isn't touched in the other
languages.

c-require-final-newline will be an alist that specifies the value to
    give to require-final-newline at mode initialization for each language
    in CC Mode, much like sh-require-final-newline as Luc suggested.

I think that if a language is not mentioned in
c-require-final-newline, then the default value of
require-final-newline should not be overridden.

Then the default value of c-require-final-newline
can be ((c-mode . t) (c++-mode . t) (objc-mode . t)),
which will set require-final-newline to t for those three
languages while leaving it unaltered for other languages.

Do you agree?

Richard Stallman <rms@...> wrote:

/.../
> Then the default value of c-require-final-newline
> can be ((c-mode . t) (c++-mode . t) (objc-mode . t)),
> which will set require-final-newline to t for those three
> languages while leaving it unaltered for other languages.

That is exactly how I implemented it.

Richard Stallman wrote:   

   Then the default value of c-require-final-newline
   can be ((c-mode . t) (c++-mode . t) (objc-mode . t)),
   which will set require-final-newline to t for those three
   languages while leaving it unaltered for other languages.

   Do you agree?

And Martin Stjernholm replied:

   That is exactly how I implemented it.

To answer Richard's question:  I do agree.

Sincerely,

Luc.

[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 <heinrich.rommerskirchen@...> 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
<bug-cc-mode@...> or <emacs-devel@...> 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)

On Sun, Nov 21, 2004 at 11:41:34AM +0000, Alan Mackenzie wrote:

> 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 <heinrich.rommerskirchen@...> 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.

Yes, indeed. Heinrich Rommerskirchen wrote:

    cc-mode tries to be smart and adds newlines to a file without
    informing the user and without any easily found option to suppress
    it.

You see - nobody wants c-require-final-newline.
It is a misfeature. Heinrich Rommerskirchen hated getting a final
newline added by emacs behind his back. I hate it.

One does not become happier if there is a complicated way to make emacs
not do it. Emacs should not do it in the first place.

This misfeature was only added because cc-mode had another misfeature:
it blindly overrides global variable settings.

That makes life much more difficult for users. If they do something
globally, they also have to make the same change locally for all
major modes they will encounter, in order to have a uniform interface.

require-final-newline is a beautiful variable. Set it to ask by default
and some people will make it always true, some will make it always false.
Many will leave it to ask.

c-require-final-newline is an ugly bug. Who will change its value?
Only people who have been bitten by the fact that emacs changed their files,
spent time in debugging, spent time in searching the docs, spent time in
searching the net. And when c-require-final-newline is just equal to
require-final-newline and the latter has default ask, then nobody is
ever bitten.

If you insist that c-require-final-newline must exist, also that
must have default ask. But there is really no reason why
anybody would set it differently from require-final-newline.
If one only edits text files, set require-final-newline to true.
If one sometimes edits arbitrary files, set it to ask.
Also an arbitrary file can have a name ending in .c.
If one always knows what one is doing and never makes mistakes,
set it to false.

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> Yes, indeed. Heinrich Rommerskirchen wrote:
>
>     cc-mode tries to be smart and adds newlines to a file without
>     informing the user and without any easily found option to
>     suppress it.
>
> You see - nobody wants c-require-final-newline.

Telling your opponents in a discussion that you consider them to be
nobody is not exactly going to help get your point across.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@...> writes:
> 
> > Yes, indeed. Heinrich Rommerskirchen wrote:
> >
> >     cc-mode tries to be smart and adds newlines to a file without
> >     informing the user and without any easily found option to
> >     suppress it.
> >
> > You see - nobody wants c-require-final-newline.
> 
> Telling your opponents in a discussion that you consider them to be
> nobody is not exactly going to help get your point across.

So far I have not met anyone who required it.
Must I assume from your reaction that you do require separate
require-final-newline and c-require-final-newline variables?

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote:
>> Andries Brouwer <Andries.Brouwer@...> writes:
>> 
>> > Yes, indeed. Heinrich Rommerskirchen wrote:
>> >
>> >     cc-mode tries to be smart and adds newlines to a file without
>> >     informing the user and without any easily found option to
>> >     suppress it.
>> >
>> > You see - nobody wants c-require-final-newline.
>> 
>> Telling your opponents in a discussion that you consider them to be
>> nobody is not exactly going to help get your point across.
>
> So far I have not met anyone who required it.
> Must I assume from your reaction that you do require separate
> require-final-newline and c-require-final-newline variables?

I was fine already with the previous behavior that unconditionally
sets require-final-newline in C modes.  But I don't mind that for the
likes of you a customization variable c-require-final-newline has been
added.

I don't particularly like the idea that every mode that has particular
requirements for a variable like that has to have a separately named
variable of its own: this makes it more difficult to figure out what
happens.  I think that in the long run something more transparent for
mode-specific defaults should be found.  But at the moment, I don't
have a good idea for that.

Maybe it would be possible to have something like

  See also c-require-final-newline

in the displayed documentation for require-final-newline
automatically, by having the loading of c-require-final-newline place
an appropriate property on require-final-newline that is then
interpreted by the documentation printer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, Nov 21, 2004 at 02:08:41PM +0100, David Kastrup wrote:

> I don't particularly like the idea that every mode that has particular
> requirements for a variable like that has to have a separately named
> variable of its own: this makes it more difficult to figure out what
> happens.  I think that in the long run something more transparent for
> mode-specific defaults should be found.

Yes, indeed.

There is a general discussion here on the use of mode variables,
but I am afraid of commenting on that right now - like to avoid
blowing up this small discussion into too many threads. Maybe later.

My point today is:
emacs must never unexpectedly change a file behind the user's back.

That is, the default settings must be so that emacs asks
before changing.

This general principle applied to the final newline leads to a
require-final-newline with default ask.

I do not believe that it is meaningful to have a separate
c-require-final-newline, but should it turn out that people
exist that really want different behaviours depending on major mode,
then for all major modes the default must again be ask
(or the value of the global variable).

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> My point today is:
> emacs must never unexpectedly change a file behind the user's back.

It doesn't.  Only when you edit and save a modified file, does it
interpret the variable.

> That is, the default settings must be so that emacs asks
> before changing.

I disagree.  The default for most modes should be to keep the files as
they are without asking.  But since files without newline at the end
are not valid C files, the default for C clearly should be different.

> I do not believe that it is meaningful to have a separate
> c-require-final-newline, but should it turn out that people exist
> that really want different behaviours depending on major mode, then
> for all major modes the default must again be ask (or the value of
> the global variable).

That's your opinion, as you have made abundantly clear already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, Nov 21, 2004 at 02:37:49PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@...> writes:
> 
> > My point today is:
> > emacs must never unexpectedly change a file behind the user's back.
> 
> It doesn't.  Only when you edit and save a modified file, does it
> interpret the variable.

That is not quite correct. Also when I save an unmodified file
under a different name the "copy" gets an extra newline.

> > That is, the default settings must be so that emacs asks
> > before changing.
> 
> I disagree.  The default for most modes should be to keep the files as
> they are without asking.  But since files without newline at the end
> are not valid C files, the default for C clearly should be different.

You mean "are not valid C99 files".
But they are valid C files for many other C dialects.
The mode is not called c99 mode.

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 02:37:49PM +0100, David Kastrup wrote:
>> 
>> I disagree.  The default for most modes should be to keep the files
>> as they are without asking.  But since files without newline at the
>> end are not valid C files, the default for C clearly should be
>> different.
>
> You mean "are not valid C99 files".
> But they are valid C files for many other C dialects.

"happens to work" and "valid" are two different things.  I don't know
any C standard that would specify well-defined behavior for a file
with a missing newline at the end.  The term "valid" is defined by a
language definition, not by the behavior of a particular
implementation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Hi, Andries!

On Sun, 21 Nov 2004, Andries Brouwer wrote:

>On Sun, Nov 21, 2004 at 11:41:34AM +0000, Alan Mackenzie wrote:

>> 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 <heinrich.rommerskirchen@...> 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.

>Yes, indeed. Heinrich Rommerskirchen wrote:

>    cc-mode tries to be smart and adds newlines to a file without
>    informing the user and without any easily found option to suppress
>    it.

>You see - nobody wants c-require-final-newline.

Untrue - Alfred M. Szmidt, for one, wants it.  If nobody wanted it, it
wouldn't have been implemented.

>It is a misfeature. Heinrich Rommerskirchen hated getting a final
>newline added by emacs behind his back. I hate it.

Yes, I think that's clear by now.  ;-)  The difference is, Heinrich had
no easy way of disabling this "feature".  Thanks to his bug report, you
do (assuming you've got CC Mode >= 5.30.  If you haven't, get 5.30.9 from
<http://cc-mode.sourceforge.net.release.php>).

>One does not become happier if there is a complicated way to make emacs
>not do it. Emacs should not do it in the first place.

It is a simple way.  The only difficult thing about it is discovering its
existence.

>This misfeature was only added because cc-mode had another misfeature:
>it blindly overrides global variable settings.

Yes indeed, but not blindly.  For example, it changes the
paragraph-start and paragraph-separate variables to recognise
comment-prefices (the "* " you have at the beginning of each comment
line), so that when you do M-q in a block comment, it doesn't just jumble
the entire comment into a compact mess.

>That makes life much more difficult for users. If they do something
>globally, they also have to make the same change locally for all
>major modes they will encounter, in order to have a uniform interface.

Users often want these things set differently in different modes.

>require-final-newline is a beautiful variable. Set it to ask by default
>and some people will make it always true, some will make it always false.
>Many will leave it to ask.

And some will want it t in C Mode and nil in Text Mode, and really don't
want to be bothered answering the question "Add one? (y or n)" twenty
times a day.

>c-require-final-newline is an ugly bug. Who will change its value?

_You_ will.  By putting the correct (for you) setting of it in your
.emacs file.

>Only people who have been bitten by the fact that emacs changed their
>files, spent time in debugging, spent time in searching the docs, spent
>time in searching the net. And when c-require-final-newline is just
>equal to require-final-newline and the latter has default ask, then
>nobody is ever bitten.

OK, you've been bitten.  Sorry.  It's happened already and it can't now
be undone.  The criticism in the previous paragraph is fair.  But read
the threads from January 2003, the ones that lead to the creation of that
variable, and see if you can come up with a better solution, given the
conflicting demands of (i) full customizability; (ii) the need to maintain
compatibility with existing behaviour; (iii) the need to keep users
informed about what's being done; (iv) the need not to irritate users
with excessive "are you sure?" type questions; .....

>If you insist that c-require-final-newline must exist, also that
>must have default ask. But there is really no reason why
>anybody would set it differently from require-final-newline.

Yes there is - To have appropriate (but different) values in Text Mode, C
Mode and AWK Mode, to name just three.  And if we changed the default
value to ask, complaints from other people would start rolling in.
That's guaranteed.  ;-(

>If one only edits text files, set require-final-newline to true.
>If one sometimes edits arbitrary files, set it to ask.
>Also an arbitrary file can have a name ending in .c.
>If one always knows what one is doing and never makes mistakes,
>set it to false.

Other people see things differently.  Emacs tries to cater for all
different tastes and preferences, and deciding on the Right defaults is
difficult.  Configure your .emacs file so that you won't get caught out
again.  Other than that, I don't think anybody can offer you much more
help.

>Andries

-- 
Alan Mackenzie (Munich, Germany)

On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote:

> "happens to work" and "valid" are two different things.  I don't know
> any C standard that would specify well-defined behavior for a file
> with a missing newline at the end.  The term "valid" is defined by a
> language definition, not by the behavior of a particular
> implementation.

Let me quote the Reference Manual in front of me.

"Blanks, tabs, newlines, and comments (collectively, "white space")
are ignored except as they serve to separate tokens."

Not "happen to work" - it is the C definition.

Andries

On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote:

> >You see - nobody wants c-require-final-newline.
> 
> Untrue - Alfred M. Szmidt, for one, wants it.

Did he tell you in private mail? To me he wrote

  "It is not relevant what I want"

> If nobody wanted it, it
> wouldn't have been implemented.

I think that implication is false. As I just wrote to dak,
a lot of stuff is implemented out of ignorance.

> >require-final-newline is a beautiful variable. Set it to ask by default
> >and some people will make it always true, some will make it always false.
> >Many will leave it to ask.
> 
> And some will want it t in C Mode and nil in Text Mode, and really don't
> want to be bothered answering the question "Add one? (y or n)" twenty
> times a day.

Possibly. So far we have not discovered such users.
Maybe Alfred M. Szmidt has told you in private mail that
he has such preferences.

I see lots of people who are unhappy. Jari Aalto writes

  "I agree. The problem is not just in CC mode"

Stefan Monnier writes

  "I'd tend to agree: setting it to `ask' is fine, but only the user
   should set it to t if she likes it, not the major mode."

Richard Stallman writes

  "I tend to think it is wrong for major modes to set this at all."

> OK, you've been bitten.  Sorry.  It's happened already and it can't now
> be undone.

And you see: nobody will discover the existence of this variable
until they have been bitten. That is, the default is unsafe -
files are changed that should have been left alone.
I oppose against an unsafe default.


Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote:
>
>> "happens to work" and "valid" are two different things.  I don't know
>> any C standard that would specify well-defined behavior for a file
>> with a missing newline at the end.  The term "valid" is defined by a
>> language definition, not by the behavior of a particular
>> implementation.
>
> Let me quote the Reference Manual

Which one?

> in front of me.
>
> "Blanks, tabs, newlines, and comments (collectively, "white space")
> are ignored except as they serve to separate tokens."
>
> Not "happen to work" - it is the C definition.

Well, if you look in the wrong places...

Both ANSI C and ANSI C++ standards contain the demand:

   "The program must end with a newline character."

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote:
>
>> And some will want it t in C Mode and nil in Text Mode, and really
>> don't want to be bothered answering the question "Add one? (y or
>> n)" twenty times a day.
>
> Possibly. So far we have not discovered such users.

So what am I?  An alien?  I already told you that I want just that
behavior.  In the interest of a civilized discussion, it would be nice
if you stopped doing the equivalent of putting your fingers in your
ears and singing "lalala, can't hear you".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, Nov 21, 2004 at 04:01:57PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@...> writes:

> > Let me quote the Reference Manual
> 
> Which one?

The original one. D.M. Ritchie, Bell Labs.

"This manual describes the C language on the DEC PDP-11, the DEC VAX-11,
the Honeywell 6000, the IBM System/370, and the Interdata 8/32."

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote:
>
>> "happens to work" and "valid" are two different things.  I don't know
>> any C standard that would specify well-defined behavior for a file
>> with a missing newline at the end.  The term "valid" is defined by a
>> language definition, not by the behavior of a particular
>> implementation.
>
> Let me quote the Reference Manual in front of me.
>
> "Blanks, tabs, newlines, and comments (collectively, "white space")
> are ignored except as they serve to separate tokens."

So you agree that adding a newline at the end of a valid C source file ca=
n
never produce an invalid C source file?

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@...
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
Key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On Sun, Nov 21, 2004 at 04:07:32PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@...> writes:
> 
> > On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote:
> >
> >> And some will want it t in C Mode and nil in Text Mode, and really
> >> don't want to be bothered answering the question "Add one? (y or
> >> n)" twenty times a day.
> >
> > Possibly. So far we have not discovered such users.
> 
> So what am I?  An alien?  I already told you that I want just that
> behavior.

OK. That letter never reached my mailbox. What came into my
mailbox was

  >> Must I assume from your reaction that you do require separate
  >> require-final-newline and c-require-final-newline variables?

  > I was fine already with the previous behavior that unconditionally
  > sets require-final-newline in C modes.  But I don't mind that for the
  > likes of you a customization variable c-require-final-newline has been
  > added.

which is a rather different statement.
But now you confirm Alan Mackenzie's claim that there exists at least
one person who needs distinct require-final-newline and
c-require-final-newline variables. Surprising, but OK.

> In the interest of a civilized discussion,

Must I remind you again... Please - we talk about emacs.

Andries

On Sun, Nov 21, 2004 at 04:18:08PM +0100, Andreas Schwab wrote:

> So you agree that adding a newline at the end of a valid C source file can
> never produce an invalid C source file?

I do not know of examples where that is the case.

There are many changes of layout that would not change the semantics
of a C program for most purposes. But there can be special reasons
to wish for a file with special properties.


Andries

> >You see - nobody wants c-require-final-newline.
   > 
   > Untrue - Alfred M. Szmidt, for one, wants it.

   Did he tell you in private mail? To me he wrote

     "It is not relevant what I want"

I told this on this mailing list, that you are incapable reading, is
really not my problem.

To quote myself:

,----
|    > Feel free to change the setting in your .emacs.
| 
|    That is the typical defensive developer reaction that makes sure
|    bugs stay for a long time.
| 
| I suppose that it didn't occur to you that this might not be a bug?
| But something that Miles, and the rest of the world, actually thinks
| is a good idea.  I for one consider it a good thing, and consider
| files that do not have a final newline broken.
`----

On Sun, Nov 21, 2004 at 08:03:55PM +0100, Alfred M. Szmidt wrote:
>    > >You see - nobody wants c-require-final-newline.
>    > 
>    > Untrue - Alfred M. Szmidt, for one, wants it.
> 
>    Did he tell you in private mail? To me he wrote
> 
>      "It is not relevant what I want"
> 
> I told this on this mailing list, that you are incapable reading, is
> really not my problem.
> 
> To quote myself:
> 
> ,----
> |    > Feel free to change the setting in your .emacs.
> | 
> |    That is the typical defensive developer reaction that makes sure
> |    bugs stay for a long time.
> | 
> | I suppose that it didn't occur to you that this might not be a bug?
> | But something that Miles, and the rest of the world, actually thinks
> | is a good idea.  I for one consider it a good thing, and consider
> | files that do not have a final newline broken.
> `----

Enough has been said already, and I consider the discussion over.
We know what is wrong. Maybe it will be fixed.

The current setup is broken because it does things behind the user's back.

It is also broken because the CC major mode is documented as
"C mode: Major mode for editing K&R and ANSI C code",
while K&R C is explicitly documented as not requiring
a final newline. That makes the case for C not stronger than
the case for java where no sneaky insertions are done by default.

But now that you query my reading comprehension - let me explain to you
that I distinguish carefully between people who want all their edited
files to end in a newline (and then setting require-final-newline to true
suffices) and people who do not want that, but do want all edited
C files to get an automatic final newline.

The part you quote suggests that you might belong to the former
category, and when I enquired further, to be sure, you said
that your personal opinion was not relevant.

Thus, so far you never stated that you actually do want a
c-require-final-newline different from require-final-newline,
more or less contradicting the part you quote here.

But after a little provocation people will find themselves
with opinions they never imagined they could have :-)

Good luck - Andries

On Sun, Nov 21, 2004 at 09:42:00PM +0200, Eli Zaretskii wrote:

> > You see - nobody wants c-require-final-newline.
> 
> Please stop pretending that you and Heinrich are ``everybody'', and
> all the rest of the world are ``nobody''.
> 
> Personally, I've set require-final-newline to t many years ago, and
> never looked back since then.  How's that for ``nobody''?

Ha, welcome! A new participant in the discussion.

But you see - according to your own words, you do not want
c-require-final-newline. You are quite satisfied with
require-final-newline.

Andries

On Sun, Nov 21, 2004 at 09:48:38PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 21 Nov 2004 14:28:04 +0100
> > From: Andries Brouwer <Andries.Brouwer@...>
> > Cc: bug-cc-mode@..., Alan Mackenzie <acm@...>,
> > 	Andries Brouwer <Andries.Brouwer@...>, emacs-devel@...
> > 
> > My point today is:
> > emacs must never unexpectedly change a file behind the user's back.
> 
> Obviously, those of us who set require-final-newline to t disagree.
> So what is the point of saying in yet another way what you've already
> said so many times?

People are slow in getting my point, that is why some repetition
seems to be needed. For example, you think that setting
require-final-newline to t means disagreeing with me.
But I like the variable require-final-newline, absolutely
nothing wrong with it, especially when the default is ask.

If one changes it to t then one has asked emacs to change one's files.
Probably one does so after considering what kind of files one usually edits.
A conscious decision.

So, if you set require-final-newline to true and emacs inserts the
final newline then there is nothing unexpected about the change.

But if you do not set require-final-newline to true, in fact set
it to ask, and still emacs inserts a final newline without asking,
that is really bad.

Andries

The current setup is broken because it does things behind the
   user's back.

Get of your high horse, the current setup is broken according to
_you_, I like the current setup.  If you do not like it, you can fix
it in your .emacs.  I won't be trying to start useless discussions if
the defaults do change, since I will just edit my .emacs and I will
continue to be a happy person.

The only broken thing might be the implementation, having
require-final-newline to be a alist of modes where you want to have
final newlines would be a good thing.  Maybe you would like to add
such a feature?

   Thus, so far you never stated that you actually do want a
   c-require-final-newline different from require-final-newline, more
   or less contradicting the part you quote here.

There is no contradiction, _some_ people might want it.  It happens
that for me they are the same.

On Sun, Nov 21, 2004 at 10:46:51PM +0100, Alfred M. Szmidt wrote:

>    Thus, so far you never stated that you actually do want a
>    c-require-final-newline different from require-final-newline, more
>    or less contradicting the part you quote here.
> 
> There is no contradiction, _some_ people might want it.  It happens
> that for me they are the same.

Good, thank you, that is what I thought.

Andries

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

I guess that's one of the reasons why some people consider `customize'
as harmful: using mode hooks is nothing bad, quite the contrary: it's the
standard way to change things in a mode-specific way.

> That's somewhat unfair.  `require-final-newline' is something that, with
> the benefit of hindsight, was perhaps a bad idea.

No, it's a very good idea.  But setting it to t without the user's explicit
consent is a problem because few users know about it so they won't
understand what's going on.  Setting it to `ask' is safe and provides
basically the same benefit.


        Stefan

> Date: Sun, 21 Nov 2004 22:21:58 +0100
> From: Andries Brouwer <Andries.Brouwer@...>
> Cc: Andries Brouwer <Andries.Brouwer@...>, acm@..., bug-cc-mode@...,
> > Personally, I've set require-final-newline to t many years ago, and
> > never looked back since then.  How's that for ``nobody''?
> 
> Ha, welcome! A new participant in the discussion.
> 
> But you see - according to your own words, you do not want
> c-require-final-newline. You are quite satisfied with
> require-final-newline.

I want both.

And, somewhere in this tiresome discussion you said that Emacs should
not change files ``behind the user's back''.  The above is meant to
tell you that I obviously disagree.

> Date: Sun, 21 Nov 2004 22:28:06 +0100
> From: Andries Brouwer <Andries.Brouwer@...>
> Cc: Andries Brouwer <Andries.Brouwer@...>, bug-cc-mode@..., acm@...,
>    emacs-devel@...
> 
> People are slow in getting my point

That's because you are slow in getting theirs.

> So, if you set require-final-newline to true and emacs inserts the
> final newline then there is nothing unexpected about the change.

You obviously think that people who customize Emacs remember by heart
every single customization they do.  It may come as a surprise to you,
then, that I actually needed to look it up in my .emacs.  So much for
``concious'' and ``nothing unexpected''.

> But if you do not set require-final-newline to true, in fact set
> it to ask, and still emacs inserts a final newline without asking,
> that is really bad.

Others tried to explain to you in so many words why it might be
actually good.  Perhaps you should re-read those messages.

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 21, 2004 at 09:48:38PM +0200, Eli Zaretskii wrote:
>> > Date: Sun, 21 Nov 2004 14:28:04 +0100
>> > From: Andries Brouwer <Andries.Brouwer@...>
>> > Cc: bug-cc-mode@..., Alan Mackenzie <acm@...>,
>> > 	Andries Brouwer <Andries.Brouwer@...>, emacs-devel@...
>> > 
>> > My point today is:
>> > emacs must never unexpectedly change a file behind the user's back.
>> 
>> Obviously, those of us who set require-final-newline to t disagree.
>> So what is the point of saying in yet another way what you've already
>> said so many times?
>
> People are slow in getting my point, that is why some repetition
> seems to be needed.

If you let go of the assumption that you are the only intelligent
person on this planet, it might make communicating with you less
unpleasant.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Somebody, sometime, wanted or needed the final newline inserted
    automatically.

We know someone thought this should be done.  Was that someone's
thought based on an actual need, or was someone assigning too much
importance to the ANSI C standard?

      The term "valid" is defined by a
    language definition, not by the behavior of a particular
    implementation.

The C standard doesn't decide what is valid or not.
It is just a guide that helps us decide what is useful or not.
That is why many of the unhelpful warning requirements of ANSI C
are implemented only with --pedantic, and we recommend that
people not use --pedantic.  The C standard "requires" these
warnings, but it has no authority over us.

      I think that in the long run something more transparent for
    mode-specific defaults should be found.

I think we should add a variable require-final-newline-modes which
would be a list of mode names.  run-mode-hook could see if the current
mode is in require-final-newline-modes, and if so, set
require-final-newline to require-final-newline-mode-value.  The
default for require-final-newline-mode-value would be :ask, but if a
user sets it to t, then all the appriate modes would set
require-final-newline to t.

> I think we should add a variable require-final-newline-modes which
> would be a list of mode names.  run-mode-hook could see if the current
> mode is in require-final-newline-modes, and if so, set
> require-final-newline to require-final-newline-mode-value.  The
> default for require-final-newline-mode-value would be :ask, but if a
> user sets it to t, then all the appriate modes would set
> require-final-newline to t.

I think that would be silly.  Tons of variable might want to be set
differently in different modes.  Do we really want to add all the
corresponding foo-modes side-variables?
I think we'd be better off with a more generic solution.

I.e. we should aim for a way to specify per-mode settings in custom.
That would be a lot more useful and wouldn't require adding any
new variable.

Here is one way it could work:

- instead of `:type foo' use `:type (per-mode foo)' where (per-mode foo)
  stands for something like (repeat (cons mode foo)) where the list of modes
  can be obtained doing

    (let ((modes nil) mode)
      (mapatoms (lambda (s)
                  (if (and (string-match "-mode-hook\\'" (symbol-name s))
                           (fboundp (intern (concat (setq mode (substring (symbol-name s) 0 (match-beginning 0))) "-mode"))))
                      (push mode modes))))
      modes)

- set custom-get and custom-set functions could look like:

(defun custom-set-per-mode (var vals)
  (put var 'custom-per-mode vals)
  (dolist (setting vals)
    (let ((mode (car setting))
          (value (cdr setting)))
      (if (eq t mode)
          (set-default var value)
        (let ((fun (intern (concat "custom-set-" mode "-" (symbol-name var)))))
          (unless (fboundp fun)
            (fset fun
                  `(lambda ()
                     (let ((val (assoc ',mode (get ',var 'custom-per-mode))))
                       (if val (set (make-local-variable ',var) (cdr val)))))))
          (add-hook (intern (concat mode "-mode-hook")) fun))))))

(defun custom-get-per-mode (var)
  (let* ((val (get var 'custom-per-mode))
         (defval (assq t val)))
    (unless (eq (cdr defval) (default-value var))
      ;; It was changed somehow...
      (setcdr defval (default-value var)))
    val))

Ideally we should even provide such per-mode settings for *all* custom
variables, without having to change the `defcustom'.


        Stefan

I think that would be silly.  Tons of variable might want to be set
    differently in different modes.  Do we really want to add all the
    corresponding foo-modes side-variables?

This is an example of taking something to an extreme and then
criticizing the extreme.  This particular variable seems to be a special
issue.  I'm not proposing this for all variables, only for this one.

However, we could also just add a single new variable
require-final-newline-in-modes which says what to do in certain
modes that ask for it.  The modes that now bind require-final-newline
to t would bind it to require-final-newline-in-modes instead.

    I.e. we should aim for a way to specify per-mode settings in custom.
    That would be a lot more useful and wouldn't require adding any
    new variable.

If we can do that cleanly, it would be a good thing.
But is there anyone who would want to really implement it?
Also, it isn't the time for such things now.

    - instead of `:type foo' use `:type (per-mode foo)' where (per-mode foo)
      stands for something like (repeat (cons mode foo)) where the list of modes
      can be obtained doing

If we do this, I think we should do this in a way that doesn't require
a special custom type, so that it would work for any variable.

>     I think that would be silly.  Tons of variable might want to be set
>     differently in different modes.  Do we really want to add all the
>     corresponding foo-modes side-variables?

> This is an example of taking something to an extreme and then
> criticizing the extreme.  This particular variable seems to be a special
> issue.  I'm not proposing this for all variables, only for this one.

Looking at my own .emacs, I see that I never set require-final-newline in
a mode-dependent way.  After all, the final-newline is an extremely minor
detail, so setting the global value of require-final-newline is already
a lot of effort compared to the potential benefit.
On the other hand, there are several other variables that I set differently
depending on the major mode.

Now I'm not the canonical user, but I still think it's a good indication
that if we add require-final-newline-in-modes, we should also add many other
similar variables for fill-column, fill-prefix, comment-start,
comment-auto-fill-only-in-comments, comment-end, left-margin, tab-width,
indent-tabs-mode, font-lock-keyword-face, font-lock-function-name-face,
fill-indent-according-to-mode, c-basic-offset, ...

> However, we could also just add a single new variable
> require-final-newline-in-modes which says what to do in certain
> modes that ask for it.  The modes that now bind require-final-newline
> to t would bind it to require-final-newline-in-modes instead.

I can't believe we're spending so much time on a miserable final newline
which is very rarely missing and even more rarely a source of problem.

> If we do this, I think we should do this in a way that doesn't require
> a special custom type, so that it would work for any variable.

Agreed,


        Stefan

A late response to a tiresome discussion, but as the primary
maintainer of CC Mode I think I ought to give my input to the
discussion about c-require-final-newlines:

One goal of CC Mode is to set up a buffer suitably for writing
C/C++/Java/etc code. That means modifying a number of variables - the
syntax table, comment-start and comment-end to name just a few. There
are great many dialects of these languages, so CC Mode uses the
current language standards as the authorative sources to determine its
settings. For C that standard is ISO C99, for C++ it's ISO C++ 97, for
Java it's the 2.0 language spec from Sun (since I've not yet adapted
CC Mode for the additional syntax in the upcoming J2SE 5.0), etc. I
plan to continue to update CC Mode to comply with the latest standards
as they become available.

For the languages where the standards mandate a trailing newline, CC
Mode therefore sets require-final-newline to t by default, just like
it configures the comment syntax according to the standard, recognizes
"#" for preprocessor directives in the languages that uses cpp, etc.
This to make the defaults reflect the most common editing situations.
It's of course often necessary to override them to suit a specific
situation, and just like other major modes CC Mode provides plenty of
ways to do that.

Regarding the argument that setting require-final-newline to t by
default (as opposed to setting the multitude of other variables to
various defaults) makes things happen "behind the back" of the user, I
believe it's only a subjective perception: It's a sign that something
happened that a specific user didn't expect; in reality there are lots
of stuff that happens "behind the back", but as long as they agree to
the user's expectations they aren't percieved that way. Therefore it
can just as well be due to lack of knowledge from the user as it is
counterintuitive behavior in the program. Other arguments are
necessary to discern where the fault is.

Anyway, I've now explained the policy behind the default used by CC
Mode, and so far I haven't seen any good arguments to depart from it
in this specific case.

As for c-require-final-newlines, I think in hindsight that it's an
ugly kludge and that it was a mistake. I agree with Stefan Monnier:
The generic way to override a variable in a specific mode is to set it
in a mode hook (or by using file local variables), and that ought to
work in this case too. If the problem is that mode hooks are too
difficult to use by many users then a simpler generic way to do mode
specific variable overrides should be added. A growing plethora of
special case variables like c-require-final-newlines does not make
things easy to understand.

I don't intend to remove c-require-final-newlines again, however.
Instead I'll be happy to deprecate it when a better tool is available.

From mast@... Sun Nov 28 15:45:23 2004
	From: Martin Stjernholm <mast@...>

	For the languages where the standards mandate a trailing newline, CC
	Mode therefore sets require-final-newline to t by default, ...

Do you think it would be appropriate for cc-mode to insert a
semicolon in a context like  label: }  where the standard does
not accept empty statements? For example automatically, when
the file is saved?

Andries

<Andries.Brouwer@...> wrote:

> Do you think it would be appropriate for cc-mode to insert a
> semicolon in a context like  label: }  where the standard does
> not accept empty statements? For example automatically, when
> the file is saved?

I could respond to this with a lengthy discussion of how that analogy
is different to the issue at hand. I could also challenge you with
similar slightly flawed analogies which would in the same roundabout
way defend the current behavior. But I don't have the time or the will
to involve myself in such discussions, so you have to produce directly
applicable arguments if you want to convince me.

On Sun, Nov 28, 2004 at 06:17:42PM +0100, Martin Stjernholm wrote:

> you have to produce directly applicable arguments
> if you want to convince me.

The basic point is that of data integrity.
Files must not be changed unless the user asks for a change.
When there has not been any such explicit request, and .emacs
is empty, then emacs should not do any helpful polishing.

The current situation, where (after 0 changes) save-buffer
returns "(No changes need to be saved)" and write-file
nevertheless writes a different file, is unfortunate and messy.

Andries

Andries Brouwer <Andries.Brouwer@...> writes:

> On Sun, Nov 28, 2004 at 06:17:42PM +0100, Martin Stjernholm wrote:
>
>> you have to produce directly applicable arguments
>> if you want to convince me.
>
> The basic point is that of data integrity.
> Files must not be changed unless the user asks for a change.
> When there has not been any such explicit request, and .emacs
> is empty, then emacs should not do any helpful polishing.
>
> The current situation, where (after 0 changes) save-buffer
> returns "(No changes need to be saved)" and write-file
> nevertheless writes a different file, is unfortunate and messy.

I would say that such behaviour is a bug in require-final-newline,
not in the way cc-mode uses it.

IMO, require-final-newline should only be checked when saving a file
which is already modified.

-- 
Kim F. Storm <storm@...> http://www.cua.dk

There
    are great many dialects of these languages, so CC Mode uses the
    current language standards as the authorative sources to determine its
    settings.

The standard is very useful as a guide to what to do, but don't let
the word "authoritative" suggest that it is some kind of authority
that we must follow.  It is not.  CC mode should take full account of
what standards say, but that does not mean trying to "comply" with
them.

    For the languages where the standards mandate a trailing newline, CC
    Mode therefore sets require-final-newline to t by default,

This is not the right basis for making the decision.

The current situation, where (after 0 changes) save-buffer
    returns "(No changes need to be saved)" and write-file
    nevertheless writes a different file, is unfortunate and messy.

This suggests that perhaps require-final-newline should be implemented
in a different way when it IS enabled, so as to avoid this anomalous
behavior.

Do you think it would be appropriate for cc-mode to insert a
    semicolon in a context like  label: }  where the standard does
    not accept empty statements? For example automatically, when
    the file is saved?

Note that GCC accepts this too, as an extension.
It is not valid ISO C, but it is valid GNU C.
In designing GNU software, valid GNU C is a more
important criterion than valid ISO C.

Richard Stallman <rms@...> writes:

>     Do you think it would be appropriate for cc-mode to insert a
>     semicolon in a context like  label: }  where the standard does
>     not accept empty statements? For example automatically, when
>     the file is saved?
>
> Note that GCC accepts this too, as an extension.

No more.

> It is not valid ISO C, but it is valid GNU C.
> In designing GNU software, valid GNU C is a more
> important criterion than valid ISO C.

<URL:http://gcc.gnu.org/gcc-3.4/changes.html>

[...]

C/Objective-C/C++

[...]

    * The undocumented extension that allowed C programs to have a
      label at the end of a compound statement, which has been
      deprecated since GCC 3.0, has been removed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Richard Stallman <rms@...> wrote:

>     For the languages where the standards mandate a trailing newline, CC
>     Mode therefore sets require-final-newline to t by default,
>
> This is not the right basis for making the decision.

I believe it is, indirectly: The default settings should be suitable
for the most common editing situations. It's reasonable to assume that
a commonly accepted standard (which is the case with ANSI C) describe
the common ground between implementations. Hence the standard is a
very good source when finding out what the most common editing
situations are.

> Note that GCC accepts this too, as an extension.

    No more.

They were not supposed to do this!

I believe it is, indirectly: The default settings should be suitable
    for the most common editing situations. It's reasonable to assume that
    a commonly accepted standard (which is the case with ANSI C) describe
    the common ground between implementations. Hence the standard is a
    very good source when finding out what the most common editing
    situations are.

It tells us what some of the common editing situations are, yes.  So
it is useful to look at the standard for many purposes, including this
one.  However, being a useful source of suggestions and insight is
quite different from laying down the law.

The current situation, where (after 0 changes) save-buffer
	returns "(No changes need to be saved)" and write-file
	nevertheless writes a different file, is unfortunate and messy.

I looked at changing this, but couldn't find a good way to do it.
I tried to provide values of require-final-newline
that only add a newline if the file is really changed.

But it is hard to distinguish use of write-file from "really changed"
because write-file operates by marking the buffer as modified
(that is how it forces a save).

Do you have any ideas?  It would not be hard to make a further
change here.

On Fri, Dec 31, 2004 at 10:26:03AM -0500, Richard Stallman wrote:

> 	The current situation, where (after 0 changes) save-buffer
> 	returns "(No changes need to be saved)" and write-file
> 	nevertheless writes a different file, is unfortunate and messy.
> 
> I looked at changing this, but couldn't find a good way to do it.
> I tried to provide values of require-final-newline
> that only add a newline if the file is really changed.
> 
> But it is hard to distinguish use of write-file from "really changed"
> because write-file operates by marking the buffer as modified
> (that is how it forces a save).
> 
> Do you have any ideas?  It would not be hard to make a further
> change here.

I do not have the source in front of me so can only make vague remarks.
Also, I do not know precisely how much and in what way this final
newline handling has changed.

Maybe I would be tempted to invent a prepare-write-file-hook
(if there is none already) that would do any required transformations
before the file is actually written.

Both save-buffer and write-file could call this hook.

This hook could set file-changed in case it adds a final newline.

Now if save-buffer only tests file-changed after calling
prepare-write-file-hook it notices the change.

Andries


[And please, have defaults such that a file is never changed
unless the user explicitly asks for the change. That is, newlines
must be added only if .emacs contains settings that ask for
such a behaviour.]

Maybe I would be tempted to invent a prepare-write-file-hook
    (if there is none already) that would do any required transformations
    before the file is actually written.

    Both save-buffer and write-file could call this hook.

    This hook could set file-changed in case it adds a final newline.

    Now if save-buffer only tests file-changed after calling
    prepare-write-file-hook it notices the change.

Actually, save-buffer doesn't add a newline, or do much of anything,
unless the buffer is already marked "modified".  The present problem,
or at least you've considered it one, is that write-file adds the
newline unconditionally.  That is because write-file marks the buffer
modified before it calls save-buffer.

I don't think your proposal would alter what happens in this case.

On Sun, Jan 02, 2005 at 11:05:56AM -0500, Richard Stallman wrote:

A happy 2005 to you!

>     Maybe I would be tempted to invent a prepare-write-file-hook
>     (if there is none already) that would do any required transformations
>     before the file is actually written.
> 
>     Both save-buffer and write-file could call this hook.
> 
>     This hook could set file-changed in case it adds a final newline.
> 
>     Now if save-buffer only tests file-changed after calling
>     prepare-write-file-hook it notices the change.
> 
> Actually, save-buffer doesn't add a newline, or do much of anything,
> unless the buffer is already marked "modified".  The present problem,
> or at least you've considered it one, is that write-file adds the
> newline unconditionally.  That is because write-file marks the buffer
> modified before it calls save-buffer.
> 
> I don't think your proposal would alter what happens in this case.

I was of the opinion that write-file and save-buffer should show
consistent behaviour; if write-file changes the contents of a file
by adding an additional byte, even when so far the file was not
modified, then save-buffer should also do that - this consistency
is what is obtained by the above suggestion.

Of course I consider silently changing a user's files to be
something terrible, so this prepare-write-file-hook should
do this adding of a newline only when there is some very explicit
evidence that this is what the user wants, like a setting in .emacs.
Certainly the chosen filename alone should not suffice.

Andries