cc-mode adds newlines

[Jari Aalto]

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


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

[Alan Mackenzie]

Post by Jari Aalto
This is your copy. Article has been posted to the newsgroup(s).
| 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.

Post by Jari Aalto
Jari

[Andries Brouwer]

Post by Alan Mackenzie

Post by Jari Aalto
| 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.

[Miles Bader]

Post by Andries Brouwer
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

[Alan Mackenzie]

Hi, Andries!

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Jari Aalto
| 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.

?? ;-)

Post by Andries Brouwer
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?".

Post by Andries Brouwer
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.]

Post by Andries Brouwer
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?

Post by Andries Brouwer
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.

Post by Andries Brouwer
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!

Post by Andries Brouwer
Andries

[Andries Brouwer]

Post by Alan Mackenzie

Post by Andries Brouwer
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.

Post by Alan Mackenzie

Post by Andries Brouwer
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.

Post by Alan Mackenzie

Post by Andries Brouwer
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.

Post by Alan Mackenzie
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.

Post by Alan Mackenzie
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.

Post by Alan Mackenzie

Post by Andries Brouwer
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

[Miles Bader]

Feel free to change the setting in your .emacs.

[Andries Brouwer]

Post by Miles Bader
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

[Alfred M. Szmidt]

Post by Miles Bader
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!

[Andries Brouwer]

Post by Alfred M. Szmidt
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

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

[Andries Brouwer]

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

[Alfred M. Szmidt]

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

[Jari Aalto]

"Alfred M. Szmidt" <***@kemisten.nu> writes:

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

It is good to have good defaults, but the principle should be:

No expected changes

This is just plain common sense. The editor should not make changes to
files, because then it may cause unexpected consequences:

all the sudden version control thinks that files have changes
because (C or other mode) decided to make changes.

It should be left to user's control. All those final-newline* settings
should be removed and instruct users to add hooks functions
(or enable features) if they really want those settings active.

Jari

[Stefan Monnier]

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

Irrelevant. That's what mode hooks are for.


Stefan

[Miles Bader]

Post by Andries Brouwer
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

[Andries Brouwer]

Post by Miles Bader

Post by Andries Brouwer
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

[David Kastrup]

Post by Andries Brouwer

Post by Miles Bader

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by David Kastrup
For what it's worth, that is what I believe.

OK.

Post by David Kastrup
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.

Post by David Kastrup
Emacs is not written by lunatics

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

Andries

[David Kastrup]

Post by Andries Brouwer

Post by David Kastrup
For what it's worth, that is what I believe.

OK.

Post by David Kastrup
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.

Post by Andries Brouwer

Post by David Kastrup
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.

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer
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

[Thien-Thi Nguyen]

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

[David Kastrup]

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Andries Brouwer
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

[David Kastrup]

Post by Andries Brouwer
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?

[Andreas Schwab]

Post by Andries Brouwer
That is a phantasy argument.

Not at all.

Post by Andries Brouwer
Old compilers just accept the C source without final newline
without any complaint. Some newer pedantic ones print a warning.

[...]

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by Andreas Schwab

Post by Andries Brouwer
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

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

[Alan Mackenzie]

[cc's have been changed]

Hi, Andries

Post by Andries Brouwer

Post by Alan Mackenzie
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 <***@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.

[ .... ]

Post by Andries Brouwer
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.

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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?".

Post by Andries Brouwer

Post by Alan Mackenzie
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-***@gnu.org> or <emacs-***@gnu.org> would be the right place
to send this.

Post by Andries Brouwer

Post by Alan Mackenzie
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.

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
Andries

[Andries Brouwer]

Post by Alan Mackenzie
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
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

[David Kastrup]

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer
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

[David Kastrup]

Post by Andries Brouwer

Post by David Kastrup

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by David Kastrup
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

[David Kastrup]

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer
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.

Post by David Kastrup

Post by Andries Brouwer
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

[David Kastrup]

Post by Andries Brouwer

Post by David Kastrup
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.

[Andries Brouwer]

Post by David Kastrup
"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

[David Kastrup]

Post by Andries Brouwer

Post by David Kastrup
"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?

Post by Andries Brouwer
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."

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer
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

[Kevin Rodgers]

Post by Andries Brouwer

Post by David Kastrup

Post by Andries Brouwer
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?

[Andreas Schwab]

Post by Andries Brouwer

Post by David Kastrup
"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.

[Andries Brouwer]

Post by Andreas Schwab
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

[Andries Brouwer]

Date: Sun, 21 Nov 2004 14:28:04 +0100
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

[Eli Zaretskii]

Date: Sun, 21 Nov 2004 22:28:06 +0100
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.

[David Kastrup]

Post by Andries Brouwer

Date: Sun, 21 Nov 2004 14:28:04 +0100
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.

[Andries Brouwer]

Post by Andries Brouwer
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

[Eli Zaretskii]

Date: Sun, 21 Nov 2004 22:21:58 +0100

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.

[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

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

[Stefan Monnier]

Post by Richard Stallman
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

[Kevin Rodgers]

Post by Stefan Monnier

Post by Richard Stallman
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))

Post by Stefan Monnier
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.
- 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"))))

Post by Stefan Monnier
(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?

Post by Stefan Monnier
(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)))))

Post by Stefan Monnier
(unless (fboundp fun)
(fset fun
`(lambda ()
(let ((val (assoc ',mode (get ',var

'custom-per-mode))))

Post by Stefan Monnier
(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).

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

[Stefan Monnier]

Post by Kevin Rodgers
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.

Post by Kevin Rodgers
(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'.

Post by Kevin Rodgers
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

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

[Stefan Monnier]

Post by 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, ...

Post by Stefan Monnier
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.

Post by Stefan Monnier
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

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

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

[Martin Stjernholm]

Post by Martin Stjernholm
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.

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

[Alan Mackenzie]

Hi, Andries!

Post by Andries Brouwer

Post by Alan Mackenzie
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
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.

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.

Post by Andries Brouwer
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>).

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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.

Post by Andries Brouwer
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; .....

Post by Andries Brouwer
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. ;-(

Post by Andries Brouwer
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.

Post by Andries Brouwer
Andries

[Andries Brouwer]

Post by Alan Mackenzie

Post by Andries Brouwer
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"

Post by Alan Mackenzie
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.

Post by Alan Mackenzie

Post by Andries Brouwer
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."

Post by Alan Mackenzie
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

[David Kastrup]

Post by Andries Brouwer

Post by Alan Mackenzie
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".

[Andries Brouwer]

Post by David Kastrup

Post by Andries Brouwer

Post by Alan Mackenzie
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

Post by David Kastrup

Post by Andries Brouwer
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.

Post by David Kastrup
In the interest of a civilized discussion,

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

Andries

[Alfred M. Szmidt]

Post by Alan Mackenzie

Post by Andries Brouwer
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.
`----

[Andries Brouwer]

Post by Andries Brouwer

Post by Alan Mackenzie

Post by Andries Brouwer
You see - nobody wants c-require-final-newline.

Untrue - Alfred M. Szmidt, for one, wants it.

"It is not relevant what I want"
I told this on this mailing list, that you are incapable reading, is
really not my problem.
,----
| > 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

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

[Andries Brouwer]

Post by Andries Brouwer
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

[Benjamin Riefenstahl]

Hi Andries,

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.

[Andries Brouwer]

Post by Benjamin Riefenstahl

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

Post by Benjamin Riefenstahl
Naturally there is not really a standard definition of pre-standard C.

[Andreas Schwab]

Post by Andries Brouwer
[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.

[Kai Grossjohann]

Post by Alan Mackenzie

Post by Andries Brouwer
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

[Kevin Rodgers]

Post by Kai Grossjohann
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)))

Post by Kai Grossjohann
That would work for other variables as well, and it would work for
other modes.

Indeed it does.

Post by Kai Grossjohann
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?

[Kai Grossjohann]

Post by Kevin Rodgers

Post by Kai Grossjohann
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.

Post by Kevin Rodgers

Post by Kai Grossjohann
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

[Alan Mackenzie]

Hi!

Post by Alan Mackenzie
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>

Post by Alan Mackenzie
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".

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

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

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

Post by Alan Mackenzie
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.

Post by Alan Mackenzie
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!

[A***@cwi.nl]

[Martin Stjernholm]

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.

[Andries Brouwer]

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

[Kim F. Storm]

Post by Andries Brouwer

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.

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

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

[Andries Brouwer]

Post by Andries Brouwer
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.]

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

[Andries Brouwer]

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

A happy 2005 to you!

Post by Andries Brouwer
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

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

[David Kastrup]

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.

[Richard Stallman]

Post by Richard Stallman
Note that GCC accepts this too, as an extension.

No more.

They were not supposed to do this!