Re: cc-mode adds newlines

Re: cc-mode adds newlines

[Jari Aalto]

This is your copy. Article has been posted to the newsgroup(s).


<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

[Alan Mackenzie]

On Fri, 19 Nov 2004, Jari Aalto wrote:

>This is your copy. Article has been posted to the newsgroup(s).


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

In CC mode, there is the (customisable) variable c-require-final-newline,
an association list, which you can set to either t, nil, or "don't
touch!" for each language independently.  The thinking is that some
languages' syntaxes absolutely require a final newline (I haven't myself
checked if this is true), and that only in those languages (C, C++,
Objective-C) is c-require-final-newline set to t. 

>Jari

-- 
Alan Mackenzie (Munich, Germany)

Re: cc-mode adds newlines

[Andries Brouwer]

On Fri, Nov 19, 2004 at 08:27:48PM +0000, Alan Mackenzie wrote:
> On Fri, 19 Nov 2004, Jari Aalto wrote:
> 
> >| 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.
> 
> In CC mode, there is the (customisable) variable c-require-final-newline,
> an association list, which you can set to either t, nil, or "don't
> touch!" for each language independently.  The thinking is that some
> languages' syntaxes absolutely require a final newline (I haven't myself
> checked if this is true), and that only in those languages (C, C++,
> Objective-C) is c-require-final-newline set to t. 

But of course this thinking is flawed. In many ways.
It is not the goal of an editor to force the user to
write syntactically correct programs.
It is excellent if the editor helps the user, warns for
things that often are mistakes, etc. But the user is the
final authority.
In this case of newlines emacs considers itself as final
authority. That is a serious bug. It must ask by default.

Andries

# cat > hi.c
main(){ printf("hi!\n");}# 
# cat hi.c
main(){ printf("hi!\n");}# cc hi.c
# a.out
hi!
# 

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


The introduction of this alist was a bug.
The introduction of c-require-final-newline was a bug.
The variable require-final-newline expresses well what the user wants.

Re: cc-mode adds newlines

[Miles Bader]

> That is a serious bug. It must ask by default.

You're being extremely silly.  It's absolutely not a "serious bug",
and arguably it's not a bug at all.

I expect most people would rather like being able to independently
specify this feature for different modes -- while it's annoying for
_all_ files to have a newline added (especially when editing e.g.,
binary files!), I think it's perfectly reasonable for _C_ files to
have a final newline added by default.

At most, I think think it's a documentation bug: it would be nice if
you could know what's going on by looking at the documentation for
`require-final-newline'.  This suggests that maybe this feature really
should be provided more centrally -- for instance what if
`require-final-newline' could be an alist, allowing one to specify
values for different modes, as well as a default, in a manner similar
ot the way `c-require-final-newline' works now.

-Miles

Re: cc-mode adds newlines

[Alan Mackenzie]

Hi, Andries!

On Sat, 20 Nov 2004, Andries Brouwer wrote:

>On Fri, Nov 19, 2004 at 08:27:48PM +0000, Alan Mackenzie wrote:
>> On Fri, 19 Nov 2004, Jari Aalto wrote:

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

>> In CC mode, there is the (customisable) variable
>> c-require-final-newline, an association list, which you can set to
>> either t, nil, or "don't touch!" for each language independently.  The
>> thinking is that some languages' syntaxes absolutely require a final
>> newline (I haven't myself checked if this is true), and that only in
>> those languages (C, C++, Objective-C) is c-require-final-newline set
>> to t. 

>But of course this thinking is flawed. In many ways.

?? ;-)

>It is not the goal of an editor to force the user to write syntactically
>correct programs.

Well, that is debateable.  I'd tend to agree with you, whilst pointing
out that in this case, there was no "force" used [see below].

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

>It is excellent if the editor helps the user, warns for things that
>often are mistakes, etc. But the user is the final authority.

You'll note that, for example, CC Mode warns you about unterminated
strings and unterminated comments.  [Don't laugh - before the days of
syntax highlighting, unterminated comments were the utter devil to find -
often the resulting source was syntactically valid, but the "else" bit of
an "if" got commented out, for example.]

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

You'd be surprised just how much people's ideas vary about what the
Obviously Right Thing is.  To me, it's inconceivable that anybody would
want scrolling past the end of a file to add new lines to it, but that
was the default Emacs behaviour until recently.  Right at the moment, I'm
having a discussion with somebody on gnu.emacs.help who can't understand
why anybody would _choose_ to use a text console rather than an X windows
display.  This is the reason that Emacs is so highly customizable.

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.

It's also fair for me to ask, did you suffer any actual damage (as
opposed to having your sense of what's proper put out of joint) 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?

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

>The introduction of this alist was a bug.
>The introduction of c-require-final-newline was a bug.
>The variable require-final-newline expresses well what the user wants.

Go out and either (i) spend the night at a disco; or (ii) go for a swim,
or a game of squash; or (ii) get blind drunk for the evening.  By the
time you get back home, c-require-final-newline won't seem so important.

All the best!

>Andries

-- 
Alan Mackenzie (Munich, Germany)

Re: cc-mode adds newlines

[Andries Brouwer]

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

> >It is not the goal of an editor to force the user to write syntactically
> >correct programs.
> 
> Well, that is debateable.  I'd tend to agree with you, whilst pointing
> out that in this case, there was no "force" used [see below].
> 
> An equally valid argument is that of the programmer who hacks through the
> night and sets off a build (which takes several hours to complete), goes
> home for some sleep, then comes back into the office the following
> afternoon.  He then finds that the build failed for lack of a final
> newline in one of the files.  Then he expostulates "FAQ!  Why couldn't
> that stupid editor have put that stupid newline in for me?".

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

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

I have been using C for thirty years or so.

> >In this case of newlines emacs considers itself as final authority. That
> >is a serious bug. It must ask by default.
> 
> No.  It is _your_ copy of Emacs, and it is _your_ choice how you
> configure it.  You can actually set Emacs up to ask about final-newlines
> first (see the Emacs manual, page "Saving", then use that information to
> set c-require-final-newline), but you've probably found that out already.

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

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

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

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

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

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

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

Yes. I needed a file without trailing newline.

> >It is not true that all dialects of C require a final newline.
> 
> Yes, but _some_ of them do, and more importantly the C standard does.

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

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

Andries

Re: cc-mode adds newlines

[Miles Bader]

Feel free to change the setting in your .emacs.

Re: cc-mode adds newlines

[David Kastrup]

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

> On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote:
>
>> >It is not the goal of an editor to force the user to write syntactically
>> >correct programs.
>> 
>> Well, that is debateable.  I'd tend to agree with you, whilst pointing
>> out that in this case, there was no "force" used [see below].
>> 
>> An equally valid argument is that of the programmer who hacks through the
>> night and sets off a build (which takes several hours to complete), goes
>> home for some sleep, then comes back into the office the following
>> afternoon.  He then finds that the build failed for lack of a final
>> newline in one of the files.  Then he expostulates "FAQ!  Why couldn't
>> that stupid editor have put that stupid newline in for me?".
>
> That is a phantasy argument.
> Old compilers just accept the C source without final newline
> without any complaint. Some newer pedantic ones print a warning.

I would not be surprised if there were compilers that just dropped the
last character of a line read in, assuming it to be a linefeed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 07:00:08PM +0900, Miles Bader wrote:
> 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.

The next-line command is a cursor movement command, but it
used to add lines to the file if you went past end-of-file.
A bad bug, but for years people said that individual users
could fix it in their individual .emacs files.
And thus it happened that thousands of people had something like

(global-set-key "\^N" 'my-next-line)
(defun my-next-line (arg)
  "next-line, but do not go past end of buffer"
  (interactive "p")
  (if (not (eobp)) (next-line arg)))

in their .emacs. And thousands of others were bitten.

If there is a bug in emacs it must be fixed in emacs.

Andries

Re: cc-mode adds newlines

[Alan Mackenzie]

[cc's have been changed]

Hi, Andries

On Sun, 21 Nov 2004, Andries Brouwer wrote:

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

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

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

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

I've had a search through the archives.  I found your bug report in
gnu.emacs.bug recently, and a previous bug report (strangely enough, with
exactly the same subject, "cc-mode adds newlines" ;-), from
Heinrich Rommerskirchen <heinrich.rommerskirchen@siemens.com> 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@gnu.org> or <emacs-devel@gnu.org> 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)

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 12:06:24PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> writes:
> 
> > On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote:
> >
> >> >It is not the goal of an editor to force the user to write syntactically
> >> >correct programs.
> >> 
> >> Well, that is debateable.  I'd tend to agree with you, whilst pointing
> >> out that in this case, there was no "force" used [see below].
> >> 
> >> An equally valid argument is that of the programmer who hacks through the
> >> night and sets off a build (which takes several hours to complete), goes
> >> home for some sleep, then comes back into the office the following
> >> afternoon.  He then finds that the build failed for lack of a final
> >> newline in one of the files.  Then he expostulates "FAQ!  Why couldn't
> >> that stupid editor have put that stupid newline in for me?".
> >
> > That is a phantasy argument.
> > Old compilers just accept the C source without final newline
> > without any complaint. Some newer pedantic ones print a warning.
> 
> I would not be surprised if there were compilers that just dropped the
> last character of a line read in, assuming it to be a linefeed.

That is a phantasy argument, and you know it.

But this is a completely irrevant side discussion.

It is not the case that emacs has the goal to force users
to only write syntactically correct programs -
and, as said, there is no guarantee at all that a file
with a name ending in .c is in fact a C99 program.

In fact there is no guarantee that it is a C program at all.
For example, I have old files where the .c extension means
that it was compressed using the "compact" utility.

Andries

Re: cc-mode adds newlines

[David Kastrup]

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

> It is not the case that emacs has the goal to force users
> to only write syntactically correct programs -
> and, as said, there is no guarantee at all that a file
> with a name ending in .c is in fact a C99 program.
>
> In fact there is no guarantee that it is a C program at all.
> For example, I have old files where the .c extension means
> that it was compressed using the "compact" utility.

And you edit those files in C mode in Emacs and save them again?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: cc-mode adds newlines

[Alfred M. Szmidt]

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

   The next-line command is a cursor movement command, but it used to
   add lines to the file if you went past end-of-file.  A bad bug, but
   for years people said that individual users could fix it in their
   individual .emacs files.

How was this a bug? It was intended to work that way.  I actually get
mad when C-n doesn't add new lines and must always fiddle the silly
next-line-add-newline variable (I always manage to forget to set it in
my .emacs)


Just because you dislike something, doesn't mean that it is a bug.
You have your .emacs to twidle the things you dislike.  Which is what
I think Miles was trying to point out.

Cheers!

Re: cc-mode adds newlines

[Andries Brouwer]

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@siemens.com> 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

Re: cc-mode adds newlines

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 01:08:50PM +0100, Alfred M. Szmidt wrote:

> I for one consider it a good thing, and consider
> files that do not have a final newline broken.

And require-final-newline is not good enough for you?
You need a separate c-require-final-newline?

Andries

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Miles Bader]

> in their .emacs. And thousands of others were bitten.

There's the difference, of course -- there probably aren't more than a
handful of people who object to Emacs making sure their .c files end
in a newline, and I expect their are far more people who _like_ the
feature.  Emacs defaults are intended to be useful for the majority.

-Miles

Re: cc-mode adds newlines

[Alfred M. Szmidt]

   And require-final-newline is not good enough for you?  You need a
   separate c-require-final-newline?

Did it occur to you that some users might wish to require newlines in
C files, and not in other files? Or the other way around? I guess not.

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 09:53:07PM +0900, Miles Bader wrote:

> > in their .emacs. And thousands of others were bitten.
> 
> There's the difference, of course -- there probably aren't more than a
> handful of people who object to Emacs making sure their .c files end
> in a newline, and I expect their are far more people who _like_ the
> feature.  Emacs defaults are intended to be useful for the majority.

Aha. So you left your previous sidetrack and now come to a new
possible objection, namely the one that having a c-require-final-newline
different from require-final-newline is useful for the majority.
Is that really what you believe?

Andries

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 01:58:12PM +0100, Alfred M. Szmidt wrote:

>    And require-final-newline is not good enough for you?  You need a
>    separate c-require-final-newline?
> 
> Did it occur to you

You did not answer the question.

Re: cc-mode adds newlines

[David Kastrup]

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

> On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote:
>> Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Alfred M. Szmidt]

   >    And require-final-newline is not good enough for you?  You need a
   >    separate c-require-final-newline?
   > 
   > Did it occur to you

   You did not answer the question.

It is not relevant what I want, but what everyone else wants.  Emacs
is not _my_ editor, but the editor of several thousand people.  It
should have such defaults that make sense for the general cases, and
should have variables/hooks that can be modifed for those cases where
the person dislikes the defaults.

So indeed, I did answer your question.

Re: cc-mode adds newlines

[David Kastrup]

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

> On Sun, Nov 21, 2004 at 09:53:07PM +0900, Miles Bader wrote:
>
>> > in their .emacs. And thousands of others were bitten.
>> 
>> There's the difference, of course -- there probably aren't more
>> than a handful of people who object to Emacs making sure their .c
>> files end in a newline, and I expect their are far more people who
>> _like_ the feature.  Emacs defaults are intended to be useful for
>> the majority.
>
> Aha. So you left your previous sidetrack and now come to a new
> possible objection, namely the one that having a
> c-require-final-newline different from require-final-newline is
> useful for the majority.  Is that really what you believe?

For what it's worth, that is what I believe.  And obviously it is what
the people responsible for the current behavior believe.  Emacs is not
written by lunatics randomly changing code and seeing whether people
complain, even though you seem to have that impression.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Andries Brouwer]

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

> For what it's worth, that is what I believe.

OK.

> And obviously it is what the people responsible for
> the current behavior believe.

I do not think so. Most likely they are sorry that this happened.

> Emacs is not written by lunatics

Please ... don't start this type of silliness.

Andries

Re: cc-mode adds newlines

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[David Kastrup]

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

> On Sun, Nov 21, 2004 at 02:14:21PM +0100, David Kastrup wrote:
>
>> For what it's worth, that is what I believe.
>
> OK.
>
>> And obviously it is what the people responsible for
>> the current behavior believe.
>
> I do not think so. Most likely they are sorry that this happened.

Variables are not introduced by accident.

>> Emacs is not written by lunatics
>
> Please ... don't start this type of silliness.

Oh, I am not starting it.  It is just paraphrasing your statement that
Emacs authors are sorry that when they introduce a variable that it
happens to do just the job that it has been invented for in the first
place.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 02:37:49PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Alan Mackenzie]

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@siemens.com> 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)

Re: cc-mode adds newlines

[Andries Brouwer]

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

> > I do not think so. Most likely they are sorry that this happened.
> 
> Variables are not introduced by accident.

This is a side discussion, but let me answer once.

Variables are often introduced out of ignorance.
(Not the pejorative ignorance but the lack-of-information ignorance.)

There is a certain behaviour, and it gets complaints.
Now what? Shall we change it? But it could be that someone depends on it.
Let us introduce an additional variable so that people can select
both old and new behaviour.

This procedure happens all the time. In many cases there is
no evidence that there actually exist people who want the old
behaviour.

But introducing an additional choice is not an unconditional
improvement. Each variable makes the system more complicated,
and therefore more difficult to use. That is, each new variable
makes the system a bit worse. New variables should be introduced
only when they offer an important new choice.

Andries

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Andreas Schwab]

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

> That is a phantasy argument.

Not at all.

> Old compilers just accept the C source without final newline
> without any complaint. Some newer pedantic ones print a warning.
[...]
> I have been using C for thirty years or so.

If you've really been using C for thirty years then you should have known
that C source files without final newline are a _real_ problem.

See <http://groups.google.com/groups?hl=de&lr=&selm=304%40mtuni.ATT.COM>
for an example.

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

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 03:47:54PM +0100, Andreas Schwab wrote:

> > Old compilers just accept the C source without final newline
> > without any complaint. Some newer pedantic ones print a warning.
> 
> If you've really been using C for thirty years then you should have known
> that C source files without final newline are a _real_ problem.
> 
> See <http://groups.google.com/groups?hl=de&lr=&selm=304%40mtuni.ATT.COM>
> for an example.

Hi Andreas -

Thanks - you are always good for solid facts.
So, yes, there exists, or has existed, a compiler or compilation setup
where an error was returned for a missing final newline.
(1988 "Gnu on 386 running UNIX" is not very specific.)

That makes it extra clear why it is very useful to have the warning
provided by setting require-final-newline to ask.

Andries

Re: cc-mode adds newlines

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Andries Brouwer]

On Sun, Nov 21, 2004 at 04:01:57PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Andreas Schwab]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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 can
never produce an invalid C source file?

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

[Andries Brouwer]

On Sun, Nov 21, 2004 at 04:07:32PM +0100, David Kastrup wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> 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

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Richard Stallman]

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

He should use GCC--then this will never happen.

It would be useful to warn about missing final newlines in C, but
Emacs should not by default add them blindly.

Re: cc-mode adds newlines

[Kai Grossjohann]

Alan Mackenzie <acm@muc.de> writes:

> On Sun, 21 Nov 2004, Andries Brouwer wrote:
>
>> 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.

Perhaps it would be useful if there was an easy way to set
require-final-newline buffer-locally.

That would work for other variables as well, and it would work for
other modes.

What do people think about a "mode specific variables" feature where
users can customize that they want the variable foo to have the value
bar in quux-mode?

... after 21.4.

Kai

Re: cc-mode adds newlines

[Thien-Thi Nguyen]

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

   New variables should be introduced
   only when they offer an important new choice.

the verbosity produced (or induced) by this topic
indicates to me that there is lots of importance
involved.  either the importance is recognized and
codified (even if awkwardly), or the importance is
glossed over to re-emerge as bug reports.

if you would characterize your observations as a
bug-report, i think it is reasonable and responsible
to describe to you the mechanisms you can use to
achieve the desired behavior.  if you would, on the
other hand, characterize your observations as advice
on how to design things, pointers to past discussion
would also be appropriate.  i see these kinds of
responses, so it seems to me people are acting well.

i think you have good ideas but it seems you do not
accept that after a certain point, goodness is
measured in many more ways than simply those that
are based on the ideal.  (this is fortunate for
people who grow more ugly w/ age, like me. ;-)
lthough it is a lot to ask, perhaps when the next
issue comes along, could you involve yourself early
on, so that what good advice you have to share has
the best prospects of finding traction?

thi

Re: cc-mode adds newlines

[Alfred M. Szmidt]

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

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Andries Brouwer]

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@cwi.nl>
> > Cc: bug-cc-mode@gnu.org, Alan Mackenzie <acm@muc.de>,
> > 	Andries Brouwer <Andries.Brouwer@cwi.nl>, emacs-devel@gnu.org
> > 
> > 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

Re: cc-mode adds newlines

[Alfred M. Szmidt]

   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.

Re: cc-mode adds newlines

[Alan Mackenzie]

Hi!

On Sun, 21 Nov 2004, Richard Stallman 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?".

>He should use GCC--then this will never happen.

<OFF TOPIC>

Actually, in my (paid) work, our project got hit recently by a GCC
newlines problem:  A string which was sent as a command from one box
along a comms channel to another box had an embedded newline in it.  This
was fine and worked.  That is, it worked until a mix up with our
proprietory version control system, so that one day we got the source
code with "proprietory" line terminators.  It compiled without errors or
warnings.  The command string with the proprietory EOL _didn't_ work.  It
didn't cause an error message either, since it was still valid syntax
(yes, that's a design bug on our part.)  It took us ~40 hours of work to
track it down.  :-(

Accepting such strings is a violation of the C++ standard, I think.  I'll
need to complain about this to GCC.  Possibly, I'll not be the first.

<\OFF TOPIC>

>It would be useful to warn about missing final newlines in C, but Emacs
>should not by default add them blindly.

It's good to get such firm guidance.  Thanks.  I'll forward this to
Martin (assuming he hasn't got the message some other way), and maybe we
can bring out a CC Mode 5.30.10 with this in it "quite soon".

-- 
Alan Mackenzie (Munich, Germany)

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Stefan Monnier]

>    And require-final-newline is not good enough for you?  You need a
>    separate c-require-final-newline?
> Did it occur to you that some users might wish to require newlines in
> C files, and not in other files? Or the other way around? I guess not.

Irrelevant.  That's what mode hooks are for.


        Stefan

Re: cc-mode adds newlines

[Stefan Monnier]

> 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

Re: cc-mode adds newlines

[Eli Zaretskii]

> Date: Sun, 21 Nov 2004 22:21:58 +0100
> From: Andries Brouwer <Andries.Brouwer@cwi.nl>
> Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>, acm@muc.de, bug-cc-mode@gnu.org,
> > 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.

Re: cc-mode adds newlines

[Eli Zaretskii]

> Date: Sun, 21 Nov 2004 22:28:06 +0100
> From: Andries Brouwer <Andries.Brouwer@cwi.nl>
> Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>, bug-cc-mode@gnu.org, acm@muc.de,
>    emacs-devel@gnu.org
> 
> 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.

Re: cc-mode adds newlines

[David Kastrup]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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@cwi.nl>
>> > Cc: bug-cc-mode@gnu.org, Alan Mackenzie <acm@muc.de>,
>> > 	Andries Brouwer <Andries.Brouwer@cwi.nl>, emacs-devel@gnu.org
>> > 
>> > 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

Re: cc-mode adds newlines

[Benjamin Riefenstahl]

Hi Andries,


Andries Brouwer writes:
> 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.

You mean the K&R book explicitly said so in it's pre-standard edition?

Naturally there is not really a standard definition of pre-standard C.
>From what I know about C89, like most restrictions, the requirement of
a final newline was most likely made because one or more compilers
required it that were already implemented and used before the
standard.


benny

Re: cc-mode adds newlines

[Richard Stallman]

    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.

Re: cc-mode adds newlines

[Stefan Monnier]

> 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

Re: cc-mode adds newlines

[Andries Brouwer]

On Mon, Nov 22, 2004 at 12:54:24PM +0100, Benjamin Riefenstahl wrote:

> > 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.
> 
> You mean the K&R book explicitly said so in it's pre-standard edition?

I do not have the K&R book here. I quoted an earlier source that I
do have here. Google also finds it various places on the web, e.g. at
http://www.freaknet.org/martin/tape/stuff/docs/cman/cman1

"Blanks, tabs, newlines, and comments as described below
are ignored except as they serve to separate tokens."

[C Reference Manual, Dennis M. Ritchie, May 1, 1977.
Reprinted in "The C Programming language" by BWK & DMR, 1978.]

> Naturally there is not really a standard definition of pre-standard C.
> From what I know about C89, like most restrictions, the requirement of
> a final newline was most likely made because one or more compilers
> required it that were already implemented and used before the
> standard.

Yes.

Andries

Re: cc-mode adds newlines

[Andreas Schwab]

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

> [C Reference Manual, Dennis M. Ritchie, May 1, 1977.
> Reprinted in "The C Programming language" by BWK & DMR, 1978.]

Yet there have been many K&R-C compilers out there that don't follow that
manual word by word.  Can you say bugs?

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

[Kevin Rodgers]

Stefan Monnier wrote:
 >>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 agree, but I would like to see it implemented outside of customize.
Custom would of course provide an interface to it, but wouldn't be the
only way to specify a mode-specific value.

For example, what if you just stored those values in each variable's
property list?  E.g.

(put 'require-final-newline 'c-mode t)

would be equivalent to

(add-hook 'c-mode-hook
	  (lambda ()
	    (set (make-local-variable 'require-final-newline) t))

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

Minor improvement (eliminate concat):

                   (when (and (string-match "\\(-mode\\)-hook\\'" 
(symbol-name s))
                              (fboundp (intern (setq mode (substring 
(symbol-name s) 0 (match-end 1))))))
                     (push mode modes))))

Why is it better to look for -mode-hook variables and derive the -mode
function, than to just look for -mode functions?

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

Ah, we're talking about almost exactly the same thing.  You've collected
all the mode-specific values into an association list keyed by the mode
symbol, and put that on the variable's custom-per-mode property; whereas
I put each value on a separate property.

But the main difference is that I imagined the mode-specific value being
set by normal-mode instead of the mode's hook (which would be preserved
as a user option, not a system variable).

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

-- 
Kevin Rodgers

Re: cc-mode adds newlines

[Kevin Rodgers]

Kai Grossjohann wrote:
 > Perhaps it would be useful if there was an easy way to set
 > require-final-newline buffer-locally.

What is not easy about

(add-hook 'c-mode-hook
           (lambda ()
             (set (make-local-variable 'require-final-newline) nil)))

 > That would work for other variables as well, and it would work for
 > other modes.

Indeed it does.

 > What do people think about a "mode specific variables" feature where
 > users can customize that they want the variable foo to have the value
 > bar in quux-mode?

What do you think about Stefan's custom-based proposal (later in the
thread) and my response?

-- 
Kevin Rodgers

Re: cc-mode adds newlines

[Kevin Rodgers]

Andries Brouwer wrote:
> On Sun, Nov 21, 2004 at 04:01:57PM +0100, David Kastrup wrote:
> 
>>Andries Brouwer <Andries.Brouwer@cwi.nl> 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."

Which of those implementations are you using?

-- 
Kevin Rodgers

Re: cc-mode adds newlines

[Stefan Monnier]

> I agree, but I would like to see it implemented outside of customize.
> Custom would of course provide an interface to it, but wouldn't be the
> only way to specify a mode-specific value.

I think `add-hook' is perfectly fine for non-custom uses.
People have used it for years without any problems.

> (put 'require-final-newline 'c-mode t)

> would be equivalent to

> (add-hook 'c-mode-hook
> 	  (lambda ()
> 	    (set (make-local-variable 'require-final-newline) t))

I recommend

   (defun my-c-mode-hook ()
     (set (make-local-variable 'require-final-newline) t))
   (add-hook 'c-mode-hook 'my-c-mode-hook)

It's better behaved when you reload your .emacs.

If you think the above is too scary, we can provide functions/macros to make
it less so.  E.g. a macro `setq-local'.

> Ah, we're talking about almost exactly the same thing.  You've collected
> all the mode-specific values into an association list keyed by the mode
> symbol, and put that on the variable's custom-per-mode property; whereas
> I put each value on a separate property.

I actually dislike this property in my sample code because it duplicate
some info.  A better way would be to hard-code the result of `assq'
inthe definition of the functions we put on the hooks, and then in
custom-get-per-mode we'd rebuild the alist by looking at the hooks and
extracting the value from the body of the function.  But that's pretty ugly.

The reason for doing that would be that if a user does
(remove-hook 'foo-mode-hook 'custom-set-foo-some-var) it should properly
update the corresponding value returned by custom-get-per-mode.


        Stefan

Re: cc-mode adds newlines

[Richard Stallman]

      Thanks.  I'll forward this to
    Martin (assuming he hasn't got the message some other way), and maybe we
    can bring out a CC Mode 5.30.10 with this in it "quite soon".

This is not just a CC mode issue, because there are other modes
that bind require-final-newline.  This morning I proposed a more
general solution to the problem.

Re: cc-mode adds newlines

[Richard Stallman]

    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.

Re: cc-mode adds newlines

[Stefan Monnier]

>     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

Re: cc-mode adds newlines

[Kai Grossjohann]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kai Grossjohann wrote:
>> Perhaps it would be useful if there was an easy way to set
>> require-final-newline buffer-locally.
>
> What is not easy about
>
> (add-hook 'c-mode-hook
>           (lambda ()
>             (set (make-local-variable 'require-final-newline) nil)))

I neglected to say "using Customize" somewhere.

>> What do people think about a "mode specific variables" feature where
>> users can customize that they want the variable foo to have the value
>> bar in quux-mode?
>
> What do you think about Stefan's custom-based proposal (later in the
> thread) and my response?

Both are implementations of what I want, but I haven't looked at
things in sufficient detail to figure out which of the implementations
is better.

Kai

Re: cc-mode adds newlines

[Richard Stallman]

    Accepting such strings is a violation of the C++ standard, I think.  I'll
    need to complain about this to GCC.  Possibly, I'll not be the first.

We do not "violate" the C++ standard, we diverge from it.  We do not
regard standards as authorities.  We make our own decisions.

Complain if you wish, but I will not agree to the absurd limitation of
string constants to a single line.

Re: cc-mode adds newlines

[Alan Mackenzie]

Hi, Richard, Hi, Emacs developers, Hi, gcc maintainers!

On Wed, 24 Nov 2004, Richard Stallman wrote:

[Subject: gcc's acceptance of string constants which straddle lines.]
>    Accepting such strings is a violation of the C++ standard, I think.  I'll
>    need to complain about this to GCC.  Possibly, I'll not be the first.

>We do not "violate" the C++ standard, we diverge from it.  We do not
>regard standards as authorities.  We make our own decisions.

OK.  That's fine by me, but .....

The situation which bit me was this:  In our embedded system, commands
get sent from device to device as strings of ASCII, a fairly normal
thing.

One particular command string was, in essence, coded thus:

const char *command =
    "aaaa
     bbbb" ;

which normally compiles to "aaaa<LF>     bbbb".  The receiving device
ignores the white space.

However, due to a mixup with proprietory version control systems and
editors, this source file somehow got to the build process with
"proprietory" line terminators.  gcc compiled the file without complaint
(on QNX, a proprietory Posix system), but the command string ended up as

"aaaa<CR><LF>    bbbb".

To the receiving device, the <CR> meant something like "do not process
the rest of this command".  To track the resulting bug down took about 40
hours of work, all told.

This is, I think, the reason why the C and C++ standards don't allow
strings to straddle lines:  the meaning of a source file can change with
the EOL convention.

Now, I like proprietory file formats almost as little as you do, and over
the decades, in projects like ours, they must have wasted untold billions
of dollars, pounds, Marks, Yen, Francs, ...., not to mention trillions of
Lira and Pesetas ;-).

It would have been nice to have got at least a warning message here.  Of
course, the Right Thing is for me to put the appropriate option (perhaps
-traditional-cpp?) into the build scripts.  The solution I actually
adopted was to purge all such strings from the source files (all ~2200 of
them - it's a very slackly written program :-(  It took me ~half a day to
write a regular expression to find them).  However, those 40 hours of
work are lost forever :-(.

But I _do_ understand the need for having strings straddling lines, too.
It's would be a pain in the donkey to have to end every line of, for
example, the doc string in a DEFUN macro with ....\n", and things like
that.  And I _do_ understand that it's desirable, sometimes, to compile
those strings with the target OS's EOL convention.

>Complain if you wish, but I will not agree to the absurd limitation of
>string constants to a single line.

By "complain", I meant simply to draw my experiences to the attention of
the gcc maintainers, and ask them to consider, perhaps, whether the gcc
options (or their defaults) might be modified in some way so as to help
other projects avoid falling into the same trap as mine did, whilst at
the same time not inconveniencing those who positively need such strings.

I was not proposing throwing some sort of temper fit.  I think you know
me better than that by now.  ;-)

So, gcc people:  is there a way?

Thanks in advance!

-- 
Alan Mackenzie (Munich, Germany)

Re: cc-mode adds newlines

[Martin Stjernholm]

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.

Re: cc-mode adds newlines

[Andries.Brouwer]

	From mast@roxen.com Sun Nov 28 15:45:23 2004
	From: Martin Stjernholm <mast@lysator.liu.se>

	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

Re: cc-mode adds newlines

[Martin Stjernholm]

<Andries.Brouwer@cwi.nl> 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.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Andries Brouwer]

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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Kim F. Storm]

Andries Brouwer <Andries.Brouwer@cwi.nl> 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@cua.dk> http://www.cua.dk



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Richard Stallman]

    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.





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Richard Stallman]

    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.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Richard Stallman]

    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.

Re: cc-mode adds newlines

[David Kastrup]

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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Martin Stjernholm]

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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Richard Stallman]

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

    No more.

They were not supposed to do this!

Re: cc-mode adds newlines

[Richard Stallman]

    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.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: cc-mode adds newlines

[Richard Stallman]

	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.

Re: cc-mode adds newlines

[Andries Brouwer]

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

Re: cc-mode adds newlines

[Richard Stallman]

    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.

Re: cc-mode adds newlines

[Andries Brouwer]

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