cc-mode adds newlines

cc-mode adds newlines

[Rommerskirchen Heinrich]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-msvc-nt5.0.2195)
 of 2002-03-19 on buffy
configured using `configure --with-msvc (12.00)'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: DEU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

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 can check it easily (see also recent input below): Start emacs
with "-q --no-init", create a new file "test.c", add some text without
a trailing newline and save the file. Then a newline is silently added.
I couldn't find a possibility to suppress this.

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.


Recent input:
C-x C-f ~ / t e s t . c <return> i C-x C-s <down> <menu-bar> 
<help-menu> <report-emacs-bug>

Recent messages:
(C:\LocalData\userid\bin\emacs-21.2\bin\emacs.exe -q --no-init)
For information about the GNU Project and its goals, type C-h C-p.
Loading image...done
(New file)
Loading cc-mode...done
Wrote c:/LocalData/userid/test.c
Loading emacsbug...done

cc-mode adds newlines

[Luc Teirlinck]

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.

The purpose of this reply is threefold:

To point out two ways you can get around this, to agree with you and
to point out what I consider to be another small bug in the process.

First way to solve the problem, exhibiting an unrelated small bug (or
so I believe) in the process.  It is the long way, but it shows how
you can figure out stuff like this yourself (with some effort).

Do M-x customize-browse.
Click successively on:
Programming
Languages
"group" next to `C'
Then in that list click on
C Mode Common Hook

Now something interesting happens (at least in my situation): `C Mode
Common Hook' suddenly changes into `CC Mode Common Hook'.  I consider
this to be a bug (but maybe I am wrong).  Firstly, it is confusing.
Secondly, I have nothing against customize's practice of cosmetically
changing variable names, but should the real names not be easily
recoverable from the "cosmetic" ones?  There is a c-mode-common-hook,
but, apparently, no cc-mode-common-hook.

Back to the original problem. Click on INS and then insert:
(lambda () (setq require-final-newline nil))

Save for future sessions.

Other way:

Put:

(add-hook 'c-mode-common-hook '(lambda () (setq require-final-newline nil)))

in your .emacs

    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 agree.  The culprit is c-common-init in cc-mode.el which
unconditionally sets require-final-newline to t without telling so in
the mode documentation you get with C-h m.  I believe it should either
use a customizable variable c-require-final-newline and tell about it
in the mode documentation, or, maybe better, set require-final-newline
to t if the global default value is t, and to 'maybe if the global
default value is 'maybe or nil.  I believe this would be the best of
both worlds:  nobody would inadvertently forget one without being
warned and, at the same time, nothing gets done "behind the user's
back".

Sincerely,

Luc Teirlinck.

cc-mode adds newlines

[Luc Teirlinck]

If you reply or follow up to my previous message on this, please
include cc's to:
Rommerskirchen Heinrich <heinrich.rommerskirchen@siemens.com>
bug-cc-mode@gnu.org

I made all kinds of blunders in address fields.  Sorry for the mess.

Sincerely,

Luc.

cc-mode adds newlines

[Luc Teirlinck]

>From my previous message:

    Do M-x customize-browse.
    Click successively on:
    Programming
    Languages
    "group" next to `C'
    Then in that list click on
    C Mode Common Hook

I want to be more explicitly precise, since this is actually a "bug
report" in its own right:

Instead of "click on C Mode Common Hook" I meant:
"Click, with mouse 2 on the Show Value field next to it."
Then we get the extra `C'.
Notice that hiding it again also erases that extra `C' again.
Note that, even though this seems like a small detail, it is confusing.
It made me look for an, apparently non-existing, cc-mode-common-hook.

(And I now finally have my address field straight, I hope.)

Sincerely,

Luc.

Re: cc-mode adds newlines

[Benjamin Riefenstahl]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

Hi Luc, Heinrich,


Note that I get this on gnu.emacs.bug, and I haven't seen the original
message so I may be missing something.

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

In general that's correct behaviour, as C requires its input to be a
vaild text file and in valid text files all lines must have a trailing
line terminator.  Some compilers *will* actually ignore the last line,
if it doesn't have a line terminator.

Same goes for other types of text files.  The behaviour of standard C
functions like fgets() is not well defined on text files that are not
valid with regard to this.  Therefore some programs will fail in this
case.

Was there a reason to want to have invalid C source originally, or was
that just an aesthetic problem?


so long, benny

cc-mode adds newlines

[Luc Teirlinck]

Benjamin Riefenstahl wrote:

     Was there a reason to want to have invalid C source originally, or was
     that just an aesthetic problem?

I myself have even the default value of require-final-newline set to t,
so in my personal usage I have no problem with what cc-mode does.  But
clearly Heinrich does.  He should tell you the details.  I do not know
whether he reads the news group or whether you included a cc to him.

However, maybe I am misunderstanding things, but is cc-mode not more
general than just C:

       CC Mode is a GNU Emacs mode for editing files containing C, C++,
    Objective-C, Java, CORBA IDL, and Pike code.

Also do not forget that, in addition to the above, people can use
cc-mode for just about any language for which no separate mode is
available.  Actually, the Emacs manual encourages them to do that:

       Ideally, Emacs should provide a major mode for each programming
    language that you might want to edit; if it doesn't have a mode for
    your favorite language, you can contribute one.  But often the mode
    for one language can serve for other syntactically similar languages. 

Users who know Elisp can write their own mode, but others may just
try to customize cc-mode the best they can. 

So, it is not clear that we are talking about invalid C source,
because it is not clear we are talking about C source.  Heinrich can
give you the details, but essentially I do have reservations about
overriding the user's global value of require-final-newline, without
any notice, if one does not even knows which language the user might
be programming.  (Overriding nil to 'maybe is OK, because it asks for
permission.)  Again, CC Mode's documentation seems to suggest that it
is for "C and other similar things", not just for C.

Also, people might want to test what the exact effect of forgetting
newlines in a language is, for whichever reason.  In that case, just
temporarily using the trivial hook function I suggested would be
sufficient, if one knows what is going on.  The problem is that people
might not be aware that you are correcting the mistakes they are
experimenting with.  Hence, they believe that they are not mistakes at
all, because everything works OK.  That is also part of why I believe
it is wrong to correct users's mistakes behind their back.  You can do
so, as long as you inform them about it.  Actually, you should inform
them about their mistakes, and if you do not automatically correct you
should at least offer to correct them (that is exactly what the 'maybe
value does).

The reservation I have is not just about automatically overriding the
default-value, that in itself could be OK, but about doing so without
clear notice, for instance in the C-h m output.  Just a small line in
the mode documentation might be helpful, maybe with a one-line
description of how they can override, if, for whichever reason, they
feel that need.  So what I am suggesting is not necessarily even
changing the current situation, but "change or inform".

We will have to wait for Heinrich's response to see what his concrete
problem is.

Sincerely,

Luc.

Re: cc-mode adds newlines

[Luc Teirlinck]

Benjamin Riefenstahl wrote:

      Was there a reason to want to have invalid C source originally, or was
      that just an aesthetic problem?

Let me try to give a better and shorter answer than in my previous
message.  Even if we are talking about a C program, there are, of
course, plenty of valid reasons to play around with invalid source.
One may want to test how some program, maybe a program one is writing,
parser, preprocessor, compiler, whatever, reacts to various forms of
invalid input.

Sincerely,

Luc.

Re: cc-mode adds newlines

[Luc Teirlinck]

>From an earlier message:

       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 agree.  The culprit is c-common-init in cc-mode.el which
   unconditionally sets require-final-newline to t without telling so in
   the mode documentation you get with C-h m.  I believe it should either
   use a customizable variable c-require-final-newline and tell about it
   in the mode documentation, or, maybe better, set require-final-newline
   to t if the global default value is t, and to 'maybe if the global
   default value is 'maybe or nil.  I believe this would be the best of
   both worlds:  nobody would inadvertently forget one without being
   warned and, at the same time, nothing gets done "behind the user's
   back".

I changed my mind about which of the two solutions I proposed is
better.  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.  The user option
would show up in the customization buffer and could be mentioned in
the mode documentation string.  It would be easy for users with
sophisticated needs, like Heinrich, to find out about the default and
override it.  What I also consider to be very important is that the
c-require-final-newline solution is consistent with sh-mode's solution
to exactly the same problem: sh-require-final-newline.  This makes
Emacs as a whole more predictable and easier to understand.

Sincerely,

Luc.

Re: cc-mode adds newlines

[Richard Stallman]

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

Re: cc-mode adds newlines

[Benjamin Riefenstahl]

Hi Richard, Luc,


Richard Stallman <rms@gnu.org> 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.


so long, benny

cc-mode adds newlines

[Andries.Brouwer]

Working with emacs 21.3.
Struggled for a while to get emacs to save a file without final newline.

It is very bad that an editor decides to change my files behind
my back. If it asks "shall I add?", that is OK. If there is a
user variable that one can set so that it will never ask, that
is OK as well. But the default must always be not to damage
the user's files by doing "helpful" things.

OK. There is a variable require-final-newline.
But setting it did not make any difference.
The setting was overridden by cc-mode.el.

So, it looks like this aspect of emacs 21.3 is broken.

Asking Google I find a lot of discussion about the topic.
Apparently I am not the only one who hates it if the editor
changes files without having been asked to.
There is talk about c-require-final-newline as a variable,
or perhaps as an alist.

I see discussion about what languages have formal standards
that require source code lines to end with newline.
But that is all completely beside the point.
The point is: emacs must not start changing my files without
being asked. It doesnt do other things to my source code
(fortunately) to make it more "correct".
An editor must not "fix" my grammar, or spelling, or layout,
or anything at all in the source file without having been asked.

Andries

Re: cc-mode adds newlines

[Kevin Rodgers]

Andries.Brouwer@cwi.nl wrote:
 > OK. There is a variable require-final-newline.
 > But setting it did not make any difference.
 > The setting was overridden by cc-mode.el.

So override cc-mode.el:

(add-hook 'c-mode-common-hook
	  (lambda () (setq require-final-newline nil)))

-- 
Kevin Rodgers

Re: cc-mode adds newlines

[Jari Aalto]

<Andries.Brouwer@cwi.nl> writes:
| Working with emacs 21.3.
| Struggled for a while to get emacs to save a file without final newline.
| ...The point is: emacs must not start changing my files without
| being asked.

I agree. The problem is not just in CC mode, but also in other modes as
well. Could someone from the dev team address these below.

Jari


cd /usr/src/cvs-source/emacs/lisp/progmodes/
find .. -name '*l' -type f -print0 | xargs -0 -e grep -n -e require-final-new
../files.el:275:(defcustom require-final-newline nil
../files.el:1527:file due to `require-final-newline' is also disabled.
../files.el:3172:                  (or (eq require-final-newline t)
../files.el:3173:                      (and require-final-newline
../textmodes/text-mode.el:71:  (set (make-local-variable 'require-final-newline\
) t)
../textmodes/texinfo.el:583:  (make-local-variable 'require-final-newline)
../textmodes/texinfo.el:584:  (setq require-final-newline t)
../progmodes/mixal-mode.el:1307:  (set (make-local-variable 'require-final-newl\
ine) t))
../progmodes/modula2.el:153:  (make-local-variable 'require-final-newline)
../progmodes/modula2.el:154:  (setq require-final-newline t)
../progmodes/antlr-mode.el:2538:  (make-local-variable 'require-final-newline)
../progmodes/antlr-mode.el:2652:  (make-local-variable 'require-final-newline)
../progmodes/antlr-mode.el:2657:  (setq require-final-newline t)
../progmodes/perl-mode.el:478:  (make-local-variable 'require-final-newline)
../progmodes/perl-mode.el:479:  (setq require-final-newline t)
../progmodes/simula.el:382:  (make-local-variable 'require-final-newline)
../progmodes/simula.el:383:  (setq require-final-newline t)
../progmodes/icon.el:179:  (make-local-variable 'require-final-newline)
../progmodes/icon.el:180:  (setq require-final-newline t)
../progmodes/ada-mode.el:1119:  (set (make-local-variable 'require-final-newlin\
e) t)
../progmodes/cc-vars.el:834:(defcustom c-require-final-newline
../progmodes/cc-vars.el:844:the value to give to `require-final-newline' at mod\
e initialization;
../progmodes/cc-vars.el:847:`require-final-newline' in buffers for that languag\
e."
../progmodes/cc-vars.el:850:                (symbol :format "%v" :value ,requir\
e-final-newline))
../progmodes/cc-vars.el:853:                (symbol :format "%v" :value ,requir\
e-final-newline))
../progmodes/cc-vars.el:856:                (symbol :format "%v" :value ,requir\
e-final-newline))
../progmodes/cc-vars.el:859:                (symbol :format "%v" :value ,requir\
e-final-newline))
../progmodes/cc-vars.el:862:                (symbol :format "%v" :value ,requir\
e-final-newline))
../progmodes/cc-vars.el:865:                (symbol :format "%v" :value ,requir\
e-final-newline)))
../progmodes/cfengine.el:225:  (set (make-local-variable 'require-final-newline\
) t)
../progmodes/fortran.el:677:  (set (make-local-variable 'require-final-newline)\
 t)
../progmodes/python.el:1720:  (set (make-local-variable 'require-final-newline)\
 t)
../progmodes/f90.el:815:  (set (make-local-variable 'require-final-newline) t)
../progmodes/sh-script.el:496:(defcustom sh-require-final-newline
../progmodes/sh-script.el:499:    (rc . require-final-newline)
../progmodes/sh-script.el:500:    (sh . require-final-newline))
../progmodes/sh-script.el:501:  "*Value of `require-final-newline' in Shell-Scr\
ipt mode buffers.
../progmodes/sh-script.el:1312:  (make-local-variable 'require-final-newline)
../progmodes/sh-script.el:1487:  (let ((tem (sh-feature sh-require-final-newlin\
e)))
../progmodes/sh-script.el:1488:    (unless (eq tem 'require-final-newline)
../progmodes/sh-script.el:1489:      (setq require-final-newline tem)))
../progmodes/tcl.el:534:  ;; (make-local-variable 'require-final-newline)
../progmodes/tcl.el:535:  ;; (setq require-final-newline t)
../progmodes/vhdl-mode.el:4560:  (set (make-local-variable 'require-final-newli\
ne) t)
../progmodes/cc-mode.el:557:  (let ((rfn (assq mode c-require-final-newline)))
../progmodes/cc-mode.el:559:      (make-local-variable 'require-final-newline)
../progmodes/cc-mode.el:560:      (setq require-final-newline (cdr rfn)))))
../progmodes/cperl-mode.el:1464:  (make-local-variable 'require-final-newline)
../progmodes/cperl-mode.el:1465:  (setq require-final-newline t)
../progmodes/idlwave.el:1895:  (set (make-local-variable 'require-final-newline\
) t)
../net/snmp-mode.el:358:  (make-local-variable 'require-final-newline)
../net/snmp-mode.el:359:  (setq require-final-newline t))
../mail/rmailout.el:149:                (let ((require-final-newline nil)
../mail/rmail.el:1135:  (make-local-variable 'require-final-newline)
../mail/rmail.el:1136:  (setq require-final-newline nil)
../mail/rmail.el:1400:        (delete-region (point) (point-max)) ; caused by r\
equire-final-newline
../emulation/viper-cmd.el:1881:      ;; when requested otherwise (require-final\
-newline is nil)
../emulation/viper-cmd.el:1884:        require-final-newline
../emulation/viper.el:625:  (setq require-final-newline nil
../emulation/viper.el:666:   require-final-newline
../emulation/viper.el:668:    'require-final-newline viper-saved-non-viper-vari\
ables)
../emulation/viper.el:685:  (viper-delocalize-var 'require-final-newline)
../emulation/viper.el:977:      require-final-newline t)
../emulation/viper.el:979:  (make-variable-buffer-local 'require-final-newline)
../emulation/viper.el:1124:        (cons 'require-final-newline (list require-f\
inal-newline))
../emulation/tpu-edt.el:199:;;    (setq require-final-newline t)
../gnus/gnus-util.el:874:                 (let ((require-final-newline nil)
../gnus/gnus-util.el:927:               (let ((require-final-newline nil)
../gnus/mailcap.el:329:     (require-final-newline nil))
../emacs-lisp/elint.el:743:     point-before-scroll require-final-newline selec\
tive-display
../eshell/esh-mode.el:369:  ;; set require-final-newline to nil; otherwise, all\
 redirected
../eshell/esh-mode.el:372:  (set (make-local-variable 'require-final-newline) n\
il)
../arc-mode.el:542:     (make-local-variable 'require-final-newline)
../arc-mode.el:543:     (setq require-final-newline nil)
../hexl.el:106:(defvar hexl-mode-old-require-final-newline)
../hexl.el:249:    (make-local-variable 'hexl-mode-old-require-final-newline)
../hexl.el:250:    (setq hexl-mode-old-require-final-newline require-final-newl\
ine)
../hexl.el:251:    (make-local-variable 'require-final-newline)
.../hexl.el:252:    (setq require-final-newline nil)
../hexl.el:356:  (setq require-final-newline hexl-mode-old-require-final-newlin\
e)
../log-edit.el:101:(defvar cvs-commit-buffer-require-final-newline t)
../log-edit.el:102:(make-obsolete-variable 'cvs-commit-buffer-require-final-new\
line
../log-edit.el:103:                        'log-edit-require-final-newline)
../log-edit.el:105:(defcustom log-edit-require-final-newline
../log-edit.el:106:  cvs-commit-buffer-require-final-newline
../log-edit.el:367:        (or (eq log-edit-require-final-newline t)
../log-edit.el:368:            (and log-edit-require-final-newline
../url/url-history.el:139:        (require-final-newline t))
../tar-mode.el:574:  (set (make-local-variable 'require-final-newline) nil) ; b\
inary data, dude...

Re: cc-mode adds newlines

[Stefan Monnier]

> I agree. The problem is not just in CC mode, but also in other modes as
> well. Could someone from the dev team address these below.

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.


        Stefan

Re: cc-mode adds newlines

[Andreas Schwab]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Andries.Brouwer@cwi.nl wrote:
>  > OK. There is a variable require-final-newline.
>  > But setting it did not make any difference.
>  > The setting was overridden by cc-mode.el.
>
> So override cc-mode.el:
>
> (add-hook 'c-mode-common-hook
> 	  (lambda () (setq require-final-newline nil)))

Or customize c-require-final-newline.

Andreas.

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

Re: cc-mode adds newlines

[Richard Stallman]

    > I agree. The problem is not just in CC mode, but also in other modes as
    > well. Could someone from the dev team address these below.

    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.

I tend to think it is wrong for major modes to set this at all.
So what if the C standard says files must end in a newline?
We would still say that any compiler that actually requires this
ought to be changed.  So why bother users about it?

Of all the modes that currently set require-final-newline to t,
are there any in which the file really won't work if it lacks
a final newline?

Re: cc-mode adds newlines

[Hallvard B Furuseth]

Richard Stallman <rms@gnu.org> writes:
>   > I agree. The problem is not just in CC mode, but also in other modes
>   > as well. Could someone from the dev team address these below.
>
>   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.
>
> I tend to think it is wrong for major modes to set this at all.

Personally I want them to leave it alone, but if people want modes to
mess with it, you might add a variable which can be set to allow that.

> So what if the C standard says files must end in a newline?

Besides, if cc-mode is invoked just because of the file name, how
does Emacs know that this really is a C file?

> We would still say that any compiler that actually requires this
> ought to be changed.  So why bother users about it?

If a compiler is used in strict ISO C mode and does not complain
about such a file, it is buggy.

I don't see why one should bother to change a compiler to support an
extension which seems to offer very little extra value.  Any extension
may cause a program to fail when used with another compiler.

I don't know why the restriction exists, but since it is explicitly
spelled out I expect there is a good reason.  Maybe related to how the C
standard supports file systems where a text file must end with newline.

Anyway, that's all the compiler's job to worry about, not Emacs'.

-- 
Hallvard

Re: cc-mode adds newlines

[Richard Stallman]

    I don't know why the restriction exists, but since it is explicitly
    spelled out I expect there is a good reason.

In the GNU Project we don't impose restrictions just because someone
else decided to.

Re: cc-mode adds newlines

[Paul D. Smith]

%% Richard Stallman <rms@gnu.org> writes:

  rs> In the GNU Project we don't impose restrictions just because
  rs> someone else decided to.

That's fine for GCC and other GNU tools, but Emacs is not always used
to edit files which are only used with other GNU programs.

The C standard requires a newline.  It's probably not the only one.
Regardless of standards, there are tools out there which do not behave
properly if a file does not end in a newline.  Sometimes they even
misbehave _silently_.  And finally, I have a very hard time imagining a
situation where it's important to _NOT_ have a final newline in a text
file, especially a C source file (if your file is not a C file then you
shouldn't be editing it in C mode!)  I'm quite confident that the large
majority of users _WANT_ a newline at the end of their text files; I
really doubt that this can be creating real problems for anyone other
than a very tiny minority.


If the consensus is that modes shouldn't be setting this variable due to
philosophical thoughts about Emacs modifying files behind the user's
back that's OK, but if you change this behavior please replace it with a
simple, one-step operation to reinstate the current operation for the
modes where it makes sense (e.g. at least those that currently have it
set to t).  I don't think all those people should have to go create a
new mode hook for every mode that used to have this value set but no
longer does.  Maybe a new value for require-final-newline of 'text or
something where Emacs would just add the newline for text files (modes
might have to define this property somehow) without asking, and ask for
other files.


Anyway, that's my $0.02.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: cc-mode adds newlines

[Stefan Monnier]

> The C standard requires a newline.

Where?

> Regardless of standards, there are tools out there which do not behave
> properly if a file does not end in a newline.

Yup.  A good reason to set require-final-newlnie to `ask'.

> Sometimes they even misbehave _silently_.

Make that a "Usually".

> And finally, I have a very hard time imagining a situation where it's
> important to _NOT_ have a final newline in a text file, especially
> a C source file

Come on, that's easy.  Think of the usual "proof by diagonalization".
I.e. one such situation is when you want to find out if the tool misbehaves
in the absence of a final newline.


        Stefan

Re: cc-mode adds newlines

[Hallvard B Furuseth]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The C standard requires a newline.
>
> Where?

C99 5.1.1.2 Translation phases:

2. Each instance of a backslash character (\) immediately followed by
   a new-line character is deleted, splicing physical source lines to
   form logical source lines.  (...) 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.

Phase 2 in C89 had similar text.

>> Regardless of standards, there are tools out there which do not behave
>> properly if a file does not end in a newline.
>
> Yup.  A good reason to set require-final-newlnie to `ask'.

One of the good things about Emacs compared to other "user-friendly"
things out there was once that one didn't have to tell it "yes, I really
mean that and you really don't know better than me" all the time.

>> And finally, I have a very hard time imagining a situation where it's
>> important to _NOT_ have a final newline in a text file, especially
>> a C source file
>
> Come on, that's easy.  Think of the usual "proof by diagonalization".
> I.e. one such situation is when you want to find out if the tool
> misbehaves in the absence of a final newline.

Or, like I said, if it's a file name which ends with .c or .h but is
not a C source file.  Filename extension collisions do happen at times.

-- 
Hallvard

Re: cc-mode adds newlines

[Andreas Schwab]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> Or, like I said, if it's a file name which ends with .c or .h but is
> not a C source file.  Filename extension collisions do happen at times.

It's easy to switch to a different mode then.

Andreas.

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

Re: cc-mode adds newlines

[Hallvard B Furuseth]

Andreas Schwab <schwab@suse.de> writes:
> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
>> Or, like I said, if it's a file name which ends with .c or .h but is
>> not a C source file.  Filename extension collisions do happen at times.
>
> It's easy to switch to a different mode then.

If one knows what causes the problem, yes.  And, with the current
"silent change" setting, if one even notices that this happens.

-- 
Hallvard