unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Re: cc-mode adds newlines
@ 2003-01-24  5:18 Luc Teirlinck
  0 siblings, 0 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-24  5:18 UTC (permalink / raw)
  Cc: bug-gnu-emacs

>From an earlier message:

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

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

I changed my mind about which of the two solutions I proposed is
better.  I now am convinced that by far the best solution is to use a
user option c-require-final-newline, keeping t as the default.  It
would not inconvenience in any way the majority of users for which
this is the correct behavior (note that I do absolutely not contest
this) and which are used to the present situation.  The user option
would show up in the customization buffer and could be mentioned in
the mode documentation string.  It would be easy for users with
sophisticated needs, like Heinrich, to find out about the default and
override it.  What I also consider to be very important is that the
c-require-final-newline solution is consistent with sh-mode's solution
to exactly the same problem: sh-require-final-newline.  This makes
Emacs as a whole more predictable and easier to understand.

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 23+ messages in thread
[parent not found: <mailman.3671.1100818498.8225.bug-gnu-emacs@gnu.org>]
* cc-mode adds newlines
@ 2004-11-18 22:45 Andries.Brouwer
  0 siblings, 0 replies; 23+ messages in thread
From: Andries.Brouwer @ 2004-11-18 22:45 UTC (permalink / raw)


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

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

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

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

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

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

Andries

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: cc-mode adds newlines
@ 2003-01-24  2:41 Luc Teirlinck
  0 siblings, 0 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-24  2:41 UTC (permalink / raw)
  Cc: bug-gnu-emacs

Benjamin Riefenstahl wrote:

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

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

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* cc-mode adds newlines
@ 2003-01-24  1:36 Luc Teirlinck
  2003-01-25 19:22 ` Richard Stallman
       [not found] ` <mailman.985.1043522856.21513.bug-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-24  1:36 UTC (permalink / raw)
  Cc: bug-gnu-emacs

Benjamin Riefenstahl wrote:

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

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

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

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

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

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

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

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

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

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

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

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 23+ messages in thread
[parent not found: <mailman.884.1043357104.21513.bug-gnu-emacs@gnu.org>]
* cc-mode adds newlines
@ 2003-01-23 22:41 Luc Teirlinck
  0 siblings, 0 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-23 22:41 UTC (permalink / raw)
  Cc: Rommerskirchen Heinrich

>From my previous message:

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

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

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

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

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* cc-mode adds newlines
@ 2003-01-23 21:52 Luc Teirlinck
  0 siblings, 0 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-23 21:52 UTC (permalink / raw)


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

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

Sincerely,

Luc.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* cc-mode adds newlines
@ 2003-01-23 21:25 Luc Teirlinck
  0 siblings, 0 replies; 23+ messages in thread
From: Luc Teirlinck @ 2003-01-23 21:25 UTC (permalink / raw)


Heinrich Rommerskirchen wrote:

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

The purpose of this reply is threefold:

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

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

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

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

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

Save for future sessions.

Other way:

Put:

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

in your .emacs

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

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

Sincerely,

Luc Teirlinck.

^ permalink raw reply	[flat|nested] 23+ messages in thread
* cc-mode adds newlines
@ 2003-01-23 13:17 Rommerskirchen Heinrich
  0 siblings, 0 replies; 23+ messages in thread
From: Rommerskirchen Heinrich @ 2003-01-23 13:17 UTC (permalink / raw)


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

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

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

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

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

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

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


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

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2004-11-28 19:39 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-24  5:18 cc-mode adds newlines Luc Teirlinck
     [not found] <mailman.3671.1100818498.8225.bug-gnu-emacs@gnu.org>
2004-11-18 23:23 ` Kevin Rodgers
2004-11-19  0:46   ` Andreas Schwab
2004-11-18 23:31 ` Jari Aalto
     [not found] ` <mailman.3684.1100821293.8225.bug-gnu-emacs@gnu.org>
2004-11-19  0:14   ` Stefan Monnier
2004-11-19 20:04     ` Richard Stallman
     [not found]     ` <mailman.56.1100895632.27204.bug-gnu-emacs@gnu.org>
2004-11-19 22:00       ` Hallvard B Furuseth
2004-11-21 15:38         ` Richard Stallman
     [not found]         ` <mailman.416.1101052189.27204.bug-gnu-emacs@gnu.org>
2004-11-22  5:55           ` Paul D. Smith
     [not found]           ` <mailman.619.1101127694.27204.bug-gnu-emacs@gnu.org>
2004-11-22 18:55             ` Stefan Monnier
     [not found]             ` <mailman.723.1101150150.27204.bug-gnu-emacs@gnu.org>
2004-11-22 19:37               ` Hallvard B Furuseth
2004-11-22 22:49                 ` Andreas Schwab
     [not found]                 ` <mailman.778.1101164414.27204.bug-gnu-emacs@gnu.org>
2004-11-28 19:39                   ` Hallvard B Furuseth
  -- strict thread matches above, loose matches on Subject: below --
2004-11-18 22:45 Andries.Brouwer
2003-01-24  2:41 Luc Teirlinck
2003-01-24  1:36 Luc Teirlinck
2003-01-25 19:22 ` Richard Stallman
     [not found] ` <mailman.985.1043522856.21513.bug-gnu-emacs@gnu.org>
2003-01-26 20:24   ` Benjamin Riefenstahl
     [not found] <mailman.884.1043357104.21513.bug-gnu-emacs@gnu.org>
2003-01-23 23:35 ` Benjamin Riefenstahl
2003-01-23 22:41 Luc Teirlinck
2003-01-23 21:52 Luc Teirlinck
2003-01-23 21:25 Luc Teirlinck
2003-01-23 13:17 Rommerskirchen Heinrich

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).