* Re: cc-mode adds newlines @ 2004-11-28 16:56 Andries.Brouwer [not found] ` <Andries.Brouwer@cwi.nl> 2004-11-30 7:01 ` Richard Stallman 0 siblings, 2 replies; 88+ messages in thread From: Andries.Brouwer @ 2004-11-28 16:56 UTC (permalink / raw) Cc: acm, Andries.Brouwer, rms, emacs-devel From mast@roxen.com Sun Nov 28 15:45:23 2004 From: Martin Stjernholm <mast@lysator.liu.se> For the languages where the standards mandate a trailing newline, CC Mode therefore sets require-final-newline to t by default, ... Do you think it would be appropriate for cc-mode to insert a semicolon in a context like label: } where the standard does not accept empty statements? For example automatically, when the file is saved? Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
[parent not found: <Andries.Brouwer@cwi.nl>]
* Re: cc-mode adds newlines [not found] ` <Andries.Brouwer@cwi.nl> @ 2004-11-28 17:17 ` Martin Stjernholm 2004-11-28 20:20 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: Martin Stjernholm @ 2004-11-28 17:17 UTC (permalink / raw) Cc: bug-cc-mode, monnier, acm, rms, emacs-devel <Andries.Brouwer@cwi.nl> wrote: > Do you think it would be appropriate for cc-mode to insert a > semicolon in a context like label: } where the standard does > not accept empty statements? For example automatically, when > the file is saved? I could respond to this with a lengthy discussion of how that analogy is different to the issue at hand. I could also challenge you with similar slightly flawed analogies which would in the same roundabout way defend the current behavior. But I don't have the time or the will to involve myself in such discussions, so you have to produce directly applicable arguments if you want to convince me. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-28 17:17 ` Martin Stjernholm @ 2004-11-28 20:20 ` Andries Brouwer 2004-11-29 0:14 ` Kim F. Storm 2004-11-30 7:01 ` Richard Stallman 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-28 20:20 UTC (permalink / raw) Cc: Andries.Brouwer, monnier, acm, rms, emacs-devel On Sun, Nov 28, 2004 at 06:17:42PM +0100, Martin Stjernholm wrote: > you have to produce directly applicable arguments > if you want to convince me. The basic point is that of data integrity. Files must not be changed unless the user asks for a change. When there has not been any such explicit request, and .emacs is empty, then emacs should not do any helpful polishing. The current situation, where (after 0 changes) save-buffer returns "(No changes need to be saved)" and write-file nevertheless writes a different file, is unfortunate and messy. Andries ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-28 20:20 ` Andries Brouwer @ 2004-11-29 0:14 ` Kim F. Storm 2004-11-30 7:01 ` Richard Stallman 1 sibling, 0 replies; 88+ messages in thread From: Kim F. Storm @ 2004-11-29 0:14 UTC (permalink / raw) Cc: bug-cc-mode, acm, emacs-devel, monnier, rms Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 28, 2004 at 06:17:42PM +0100, Martin Stjernholm wrote: > >> you have to produce directly applicable arguments >> if you want to convince me. > > The basic point is that of data integrity. > Files must not be changed unless the user asks for a change. > When there has not been any such explicit request, and .emacs > is empty, then emacs should not do any helpful polishing. > > The current situation, where (after 0 changes) save-buffer > returns "(No changes need to be saved)" and write-file > nevertheless writes a different file, is unfortunate and messy. I would say that such behaviour is a bug in require-final-newline, not in the way cc-mode uses it. IMO, require-final-newline should only be checked when saving a file which is already modified. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-28 20:20 ` Andries Brouwer 2004-11-29 0:14 ` Kim F. Storm @ 2004-11-30 7:01 ` Richard Stallman 2004-12-31 15:26 ` Richard Stallman 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-30 7:01 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-30 7:01 ` Richard Stallman @ 2004-12-31 15:26 ` Richard Stallman 2004-12-31 16:56 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-12-31 15:26 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-12-31 15:26 ` Richard Stallman @ 2004-12-31 16:56 ` Andries Brouwer 2005-01-02 16:05 ` Richard Stallman 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-12-31 16:56 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, monnier, emacs-devel On Fri, Dec 31, 2004 at 10:26:03AM -0500, Richard Stallman wrote: > The current situation, where (after 0 changes) save-buffer > returns "(No changes need to be saved)" and write-file > nevertheless writes a different file, is unfortunate and messy. > > I looked at changing this, but couldn't find a good way to do it. > I tried to provide values of require-final-newline > that only add a newline if the file is really changed. > > But it is hard to distinguish use of write-file from "really changed" > because write-file operates by marking the buffer as modified > (that is how it forces a save). > > Do you have any ideas? It would not be hard to make a further > change here. I do not have the source in front of me so can only make vague remarks. Also, I do not know precisely how much and in what way this final newline handling has changed. Maybe I would be tempted to invent a prepare-write-file-hook (if there is none already) that would do any required transformations before the file is actually written. Both save-buffer and write-file could call this hook. This hook could set file-changed in case it adds a final newline. Now if save-buffer only tests file-changed after calling prepare-write-file-hook it notices the change. Andries [And please, have defaults such that a file is never changed unless the user explicitly asks for the change. That is, newlines must be added only if .emacs contains settings that ask for such a behaviour.] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-12-31 16:56 ` Andries Brouwer @ 2005-01-02 16:05 ` Richard Stallman 2005-01-02 18:02 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: Richard Stallman @ 2005-01-02 16:05 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2005-01-02 16:05 ` Richard Stallman @ 2005-01-02 18:02 ` Andries Brouwer 0 siblings, 0 replies; 88+ messages in thread From: Andries Brouwer @ 2005-01-02 18:02 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries Brouwer, monnier, emacs-devel On Sun, Jan 02, 2005 at 11:05:56AM -0500, Richard Stallman wrote: A happy 2005 to you! > Maybe I would be tempted to invent a prepare-write-file-hook > (if there is none already) that would do any required transformations > before the file is actually written. > > Both save-buffer and write-file could call this hook. > > This hook could set file-changed in case it adds a final newline. > > Now if save-buffer only tests file-changed after calling > prepare-write-file-hook it notices the change. > > Actually, save-buffer doesn't add a newline, or do much of anything, > unless the buffer is already marked "modified". The present problem, > or at least you've considered it one, is that write-file adds the > newline unconditionally. That is because write-file marks the buffer > modified before it calls save-buffer. > > I don't think your proposal would alter what happens in this case. I was of the opinion that write-file and save-buffer should show consistent behaviour; if write-file changes the contents of a file by adding an additional byte, even when so far the file was not modified, then save-buffer should also do that - this consistency is what is obtained by the above suggestion. Of course I consider silently changing a user's files to be something terrible, so this prepare-write-file-hook should do this adding of a newline only when there is some very explicit evidence that this is what the user wants, like a setting in .emacs. Certainly the chosen filename alone should not suffice. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-28 16:56 cc-mode adds newlines Andries.Brouwer [not found] ` <Andries.Brouwer@cwi.nl> @ 2004-11-30 7:01 ` Richard Stallman 2004-11-30 8:11 ` David Kastrup 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-30 7:01 UTC (permalink / raw) Cc: bug-cc-mode, monnier, Andries.Brouwer, acm, emacs-devel Do you think it would be appropriate for cc-mode to insert a semicolon in a context like label: } where the standard does not accept empty statements? For example automatically, when the file is saved? Note that GCC accepts this too, as an extension. It is not valid ISO C, but it is valid GNU C. In designing GNU software, valid GNU C is a more important criterion than valid ISO C. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-30 7:01 ` Richard Stallman @ 2004-11-30 8:11 ` David Kastrup 2004-12-01 2:56 ` Richard Stallman 0 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-30 8:11 UTC (permalink / raw) Cc: Andries.Brouwer, bug-cc-mode, acm, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > Do you think it would be appropriate for cc-mode to insert a > semicolon in a context like label: } where the standard does > not accept empty statements? For example automatically, when > the file is saved? > > Note that GCC accepts this too, as an extension. No more. > It is not valid ISO C, but it is valid GNU C. > In designing GNU software, valid GNU C is a more > important criterion than valid ISO C. <URL:http://gcc.gnu.org/gcc-3.4/changes.html> [...] C/Objective-C/C++ [...] * The undocumented extension that allowed C programs to have a label at the end of a compound statement, which has been deprecated since GCC 3.0, has been removed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-30 8:11 ` David Kastrup @ 2004-12-01 2:56 ` Richard Stallman 0 siblings, 0 replies; 88+ messages in thread From: Richard Stallman @ 2004-12-01 2:56 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, monnier, emacs-devel > Note that GCC accepts this too, as an extension. No more. They were not supposed to do this! ^ permalink raw reply [flat|nested] 88+ messages in thread
[parent not found: <mailman.3671.1100818498.8225.bug-gnu-emacs@gnu.org>]
* Re: cc-mode adds newlines [not found] <mailman.3671.1100818498.8225.bug-gnu-emacs@gnu.org> @ 2004-11-18 23:31 ` Jari Aalto 2004-11-19 20:27 ` Alan Mackenzie 0 siblings, 1 reply; 88+ messages in thread From: Jari Aalto @ 2004-11-18 23:31 UTC (permalink / raw) Cc: emacs-devel This is your copy. Article has been posted to the newsgroup(s). <Andries.Brouwer@cwi.nl> writes: | Working with emacs 21.3. | Struggled for a while to get emacs to save a file without final newline. | ...The point is: emacs must not start changing my files without | being asked. I agree. The problem is not just in CC mode, but also in other modes as well. Could someone from the dev team address these below. Jari cd /usr/src/cvs-source/emacs/lisp/progmodes/ find .. -name '*l' -type f -print0 | xargs -0 -e grep -n -e require-final-new ../files.el:275:(defcustom require-final-newline nil ../files.el:1527:file due to `require-final-newline' is also disabled. ../files.el:3172: (or (eq require-final-newline t) ../files.el:3173: (and require-final-newline ../textmodes/text-mode.el:71: (set (make-local-variable 'require-final-newline\ ) t) ../textmodes/texinfo.el:583: (make-local-variable 'require-final-newline) ../textmodes/texinfo.el:584: (setq require-final-newline t) ../progmodes/mixal-mode.el:1307: (set (make-local-variable 'require-final-newl\ ine) t)) ../progmodes/modula2.el:153: (make-local-variable 'require-final-newline) ../progmodes/modula2.el:154: (setq require-final-newline t) ../progmodes/antlr-mode.el:2538: (make-local-variable 'require-final-newline) ../progmodes/antlr-mode.el:2652: (make-local-variable 'require-final-newline) ../progmodes/antlr-mode.el:2657: (setq require-final-newline t) ../progmodes/perl-mode.el:478: (make-local-variable 'require-final-newline) ../progmodes/perl-mode.el:479: (setq require-final-newline t) ../progmodes/simula.el:382: (make-local-variable 'require-final-newline) ../progmodes/simula.el:383: (setq require-final-newline t) ../progmodes/icon.el:179: (make-local-variable 'require-final-newline) ../progmodes/icon.el:180: (setq require-final-newline t) ../progmodes/ada-mode.el:1119: (set (make-local-variable 'require-final-newlin\ e) t) ../progmodes/cc-vars.el:834:(defcustom c-require-final-newline ../progmodes/cc-vars.el:844:the value to give to `require-final-newline' at mod\ e initialization; ../progmodes/cc-vars.el:847:`require-final-newline' in buffers for that languag\ e." ../progmodes/cc-vars.el:850: (symbol :format "%v" :value ,requir\ e-final-newline)) ../progmodes/cc-vars.el:853: (symbol :format "%v" :value ,requir\ e-final-newline)) ../progmodes/cc-vars.el:856: (symbol :format "%v" :value ,requir\ e-final-newline)) ../progmodes/cc-vars.el:859: (symbol :format "%v" :value ,requir\ e-final-newline)) ../progmodes/cc-vars.el:862: (symbol :format "%v" :value ,requir\ e-final-newline)) ../progmodes/cc-vars.el:865: (symbol :format "%v" :value ,requir\ e-final-newline))) ../progmodes/cfengine.el:225: (set (make-local-variable 'require-final-newline\ ) t) ../progmodes/fortran.el:677: (set (make-local-variable 'require-final-newline)\ t) ../progmodes/python.el:1720: (set (make-local-variable 'require-final-newline)\ t) ../progmodes/f90.el:815: (set (make-local-variable 'require-final-newline) t) ../progmodes/sh-script.el:496:(defcustom sh-require-final-newline ../progmodes/sh-script.el:499: (rc . require-final-newline) ../progmodes/sh-script.el:500: (sh . require-final-newline)) ../progmodes/sh-script.el:501: "*Value of `require-final-newline' in Shell-Scr\ ipt mode buffers. ../progmodes/sh-script.el:1312: (make-local-variable 'require-final-newline) ../progmodes/sh-script.el:1487: (let ((tem (sh-feature sh-require-final-newlin\ e))) ../progmodes/sh-script.el:1488: (unless (eq tem 'require-final-newline) ../progmodes/sh-script.el:1489: (setq require-final-newline tem))) ../progmodes/tcl.el:534: ;; (make-local-variable 'require-final-newline) ../progmodes/tcl.el:535: ;; (setq require-final-newline t) ../progmodes/vhdl-mode.el:4560: (set (make-local-variable 'require-final-newli\ ne) t) ../progmodes/cc-mode.el:557: (let ((rfn (assq mode c-require-final-newline))) ../progmodes/cc-mode.el:559: (make-local-variable 'require-final-newline) ../progmodes/cc-mode.el:560: (setq require-final-newline (cdr rfn))))) ../progmodes/cperl-mode.el:1464: (make-local-variable 'require-final-newline) ../progmodes/cperl-mode.el:1465: (setq require-final-newline t) ../progmodes/idlwave.el:1895: (set (make-local-variable 'require-final-newline\ ) t) ../net/snmp-mode.el:358: (make-local-variable 'require-final-newline) ../net/snmp-mode.el:359: (setq require-final-newline t)) ../mail/rmailout.el:149: (let ((require-final-newline nil) ../mail/rmail.el:1135: (make-local-variable 'require-final-newline) ../mail/rmail.el:1136: (setq require-final-newline nil) ../mail/rmail.el:1400: (delete-region (point) (point-max)) ; caused by r\ equire-final-newline ../emulation/viper-cmd.el:1881: ;; when requested otherwise (require-final\ -newline is nil) ../emulation/viper-cmd.el:1884: require-final-newline ../emulation/viper.el:625: (setq require-final-newline nil ../emulation/viper.el:666: require-final-newline ../emulation/viper.el:668: 'require-final-newline viper-saved-non-viper-vari\ ables) ../emulation/viper.el:685: (viper-delocalize-var 'require-final-newline) ../emulation/viper.el:977: require-final-newline t) ../emulation/viper.el:979: (make-variable-buffer-local 'require-final-newline) ../emulation/viper.el:1124: (cons 'require-final-newline (list require-f\ inal-newline)) ../emulation/tpu-edt.el:199:;; (setq require-final-newline t) ../gnus/gnus-util.el:874: (let ((require-final-newline nil) ../gnus/gnus-util.el:927: (let ((require-final-newline nil) ../gnus/mailcap.el:329: (require-final-newline nil)) ../emacs-lisp/elint.el:743: point-before-scroll require-final-newline selec\ tive-display ../eshell/esh-mode.el:369: ;; set require-final-newline to nil; otherwise, all\ redirected ../eshell/esh-mode.el:372: (set (make-local-variable 'require-final-newline) n\ il) ../arc-mode.el:542: (make-local-variable 'require-final-newline) ../arc-mode.el:543: (setq require-final-newline nil) ../hexl.el:106:(defvar hexl-mode-old-require-final-newline) ../hexl.el:249: (make-local-variable 'hexl-mode-old-require-final-newline) ../hexl.el:250: (setq hexl-mode-old-require-final-newline require-final-newl\ ine) ../hexl.el:251: (make-local-variable 'require-final-newline) .../hexl.el:252: (setq require-final-newline nil) ../hexl.el:356: (setq require-final-newline hexl-mode-old-require-final-newlin\ e) ../log-edit.el:101:(defvar cvs-commit-buffer-require-final-newline t) ../log-edit.el:102:(make-obsolete-variable 'cvs-commit-buffer-require-final-new\ line ../log-edit.el:103: 'log-edit-require-final-newline) ../log-edit.el:105:(defcustom log-edit-require-final-newline ../log-edit.el:106: cvs-commit-buffer-require-final-newline ../log-edit.el:367: (or (eq log-edit-require-final-newline t) ../log-edit.el:368: (and log-edit-require-final-newline ../url/url-history.el:139: (require-final-newline t)) ../tar-mode.el:574: (set (make-local-variable 'require-final-newline) nil) ; b\ inary data, dude... ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-18 23:31 ` Jari Aalto @ 2004-11-19 20:27 ` Alan Mackenzie 2004-11-19 23:13 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: Alan Mackenzie @ 2004-11-19 20:27 UTC (permalink / raw) Cc: Andries.Brouwer, emacs-devel On Fri, 19 Nov 2004, Jari Aalto wrote: >This is your copy. Article has been posted to the newsgroup(s). ><Andries.Brouwer@cwi.nl> writes: >| Working with emacs 21.3. >| Struggled for a while to get emacs to save a file without final newline. >| ...The point is: emacs must not start changing my files without >| being asked. >I agree. The problem is not just in CC mode, but also in other modes as >well. Could someone from the dev team address these below. In CC mode, there is the (customisable) variable c-require-final-newline, an association list, which you can set to either t, nil, or "don't touch!" for each language independently. The thinking is that some languages' syntaxes absolutely require a final newline (I haven't myself checked if this is true), and that only in those languages (C, C++, Objective-C) is c-require-final-newline set to t. >Jari -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-19 20:27 ` Alan Mackenzie @ 2004-11-19 23:13 ` Andries Brouwer 2004-11-20 0:13 ` Miles Bader 2004-11-20 15:14 ` Alan Mackenzie 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-19 23:13 UTC (permalink / raw) Cc: Andries.Brouwer, emacs-devel, Jari Aalto On Fri, Nov 19, 2004 at 08:27:48PM +0000, Alan Mackenzie wrote: > On Fri, 19 Nov 2004, Jari Aalto wrote: > > >| Working with emacs 21.3. > >| Struggled for a while to get emacs to save a file without final newline. > >| ...The point is: emacs must not start changing my files without > >| being asked. > > >I agree. The problem is not just in CC mode, but also in other modes as > >well. Could someone from the dev team address these below. > > In CC mode, there is the (customisable) variable c-require-final-newline, > an association list, which you can set to either t, nil, or "don't > touch!" for each language independently. The thinking is that some > languages' syntaxes absolutely require a final newline (I haven't myself > checked if this is true), and that only in those languages (C, C++, > Objective-C) is c-require-final-newline set to t. But of course this thinking is flawed. In many ways. It is not the goal of an editor to force the user to write syntactically correct programs. It is excellent if the editor helps the user, warns for things that often are mistakes, etc. But the user is the final authority. In this case of newlines emacs considers itself as final authority. That is a serious bug. It must ask by default. Andries # cat > hi.c main(){ printf("hi!\n");}# # cat hi.c main(){ printf("hi!\n");}# cc hi.c # a.out hi! # It is not true that all dialects of C require a final newline. The introduction of this alist was a bug. The introduction of c-require-final-newline was a bug. The variable require-final-newline expresses well what the user wants. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-19 23:13 ` Andries Brouwer @ 2004-11-20 0:13 ` Miles Bader 2004-11-20 15:14 ` Alan Mackenzie 1 sibling, 0 replies; 88+ messages in thread From: Miles Bader @ 2004-11-20 0:13 UTC (permalink / raw) Cc: Alan Mackenzie, Jari Aalto, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-19 23:13 ` Andries Brouwer 2004-11-20 0:13 ` Miles Bader @ 2004-11-20 15:14 ` Alan Mackenzie 2004-11-21 2:08 ` Andries Brouwer 2004-11-21 15:39 ` Richard Stallman 1 sibling, 2 replies; 88+ messages in thread From: Alan Mackenzie @ 2004-11-20 15:14 UTC (permalink / raw) Cc: emacs-devel, Jari Aalto Hi, Andries! On Sat, 20 Nov 2004, Andries Brouwer wrote: >On Fri, Nov 19, 2004 at 08:27:48PM +0000, Alan Mackenzie wrote: >> On Fri, 19 Nov 2004, Jari Aalto wrote: >> >| Working with emacs 21.3. >> >| Struggled for a while to get emacs to save a file without final newline. >> >| ...The point is: emacs must not start changing my files without >> >| being asked. >> >I agree. The problem is not just in CC mode, but also in other modes >> >as well. Could someone from the dev team address these below. >> In CC mode, there is the (customisable) variable >> c-require-final-newline, an association list, which you can set to >> either t, nil, or "don't touch!" for each language independently. The >> thinking is that some languages' syntaxes absolutely require a final >> newline (I haven't myself checked if this is true), and that only in >> those languages (C, C++, Objective-C) is c-require-final-newline set >> to t. >But of course this thinking is flawed. In many ways. ?? ;-) >It is not the goal of an editor to force the user to write syntactically >correct programs. Well, that is debateable. I'd tend to agree with you, whilst pointing out that in this case, there was no "force" used [see below]. An equally valid argument is that of the programmer who hacks through the night and sets off a build (which takes several hours to complete), goes home for some sleep, then comes back into the office the following afternoon. He then finds that the build failed for lack of a final newline in one of the files. Then he expostulates "FAQ! Why couldn't that stupid editor have put that stupid newline in for me?". >It is excellent if the editor helps the user, warns for things that >often are mistakes, etc. But the user is the final authority. You'll note that, for example, CC Mode warns you about unterminated strings and unterminated comments. [Don't laugh - before the days of syntax highlighting, unterminated comments were the utter devil to find - often the resulting source was syntactically valid, but the "else" bit of an "if" got commented out, for example.] >In this case of newlines emacs considers itself as final authority. That >is a serious bug. It must ask by default. No. It is _your_ copy of Emacs, and it is _your_ choice how you configure it. You can actually set Emacs up to ask about final-newlines first (see the Emacs manual, page "Saving", then use that information to set c-require-final-newline), but you've probably found that out already. You'd be surprised just how much people's ideas vary about what the Obviously Right Thing is. To me, it's inconceivable that anybody would want scrolling past the end of a file to add new lines to it, but that was the default Emacs behaviour until recently. Right at the moment, I'm having a discussion with somebody on gnu.emacs.help who can't understand why anybody would _choose_ to use a text console rather than an X windows display. This is the reason that Emacs is so highly customizable. I think your complaint here is that you didn't know about the setting, and had no reason to suspect it might exist, and therefore no reason to spend weeks meticulously searching through the manual for anything random which might mess up your files. That's a fair complaint. It's also fair for me to ask, did you suffer any actual damage (as opposed to having your sense of what's proper put out of joint) from this terminating newline? Something like the source file being an input to some scriptfile, rather than just being compiled, and that script fouling up? >It is not true that all dialects of C require a final newline. Yes, but _some_ of them do, and more importantly the C standard does. >The introduction of this alist was a bug. >The introduction of c-require-final-newline was a bug. >The variable require-final-newline expresses well what the user wants. Go out and either (i) spend the night at a disco; or (ii) go for a swim, or a game of squash; or (ii) get blind drunk for the evening. By the time you get back home, c-require-final-newline won't seem so important. All the best! >Andries -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-20 15:14 ` Alan Mackenzie @ 2004-11-21 2:08 ` Andries Brouwer 2004-11-21 10:00 ` Miles Bader ` (3 more replies) 2004-11-21 15:39 ` Richard Stallman 1 sibling, 4 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 2:08 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, Jari Aalto On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote: > >It is not the goal of an editor to force the user to write syntactically > >correct programs. > > Well, that is debateable. I'd tend to agree with you, whilst pointing > out that in this case, there was no "force" used [see below]. > > An equally valid argument is that of the programmer who hacks through the > night and sets off a build (which takes several hours to complete), goes > home for some sleep, then comes back into the office the following > afternoon. He then finds that the build failed for lack of a final > newline in one of the files. Then he expostulates "FAQ! Why couldn't > that stupid editor have put that stupid newline in for me?". That is a phantasy argument. Old compilers just accept the C source without final newline without any complaint. Some newer pedantic ones print a warning. > >It is excellent if the editor helps the user, warns for things that > >often are mistakes, etc. But the user is the final authority. > > You'll note that, for example, CC Mode warns you about unterminated > strings and unterminated comments. [Don't laugh - before the days of > syntax highlighting, unterminated comments were the utter devil to find - > often the resulting source was syntactically valid, but the "else" bit of > an "if" got commented out, for example.] I have been using C for thirty years or so. > >In this case of newlines emacs considers itself as final authority. That > >is a serious bug. It must ask by default. > > No. It is _your_ copy of Emacs, and it is _your_ choice how you > configure it. You can actually set Emacs up to ask about final-newlines > first (see the Emacs manual, page "Saving", then use that information to > set c-require-final-newline), but you've probably found that out already. That is a phantasy argument. If emacs dumps core when I do something, and there is a variable do-not-dump-core you cannot point out the existence of the variable to dismiss the bug. The alist c-require-final-newline was an extremely poor design decision. The single variable require-final-newline is excellent, especially if the default is ask. It is very poor design to add switches and variables just because it is a logical possibility that someone might want it. It is not true that emacs is getting better and better as the number of variables that can be customised increases. > I think your complaint here is that you didn't know about the setting, > and had no reason to suspect it might exist, and therefore no reason to > spend weeks meticulously searching through the manual for anything random > which might mess up your files. That's a fair complaint. Not precisely. The (stupid, buggy) variable that was added later does not yet exist in my version of emacs. For me the fastest would have been to save the file, rename it, delete the final newline, rename it back. Silly kludges showing the brokenness of emacs. > It's also fair for me to ask, did you suffer any actual damage > from this terminating newline? Something like the source file > being an input to some scriptfile, rather than just being compiled, > and that script fouling up? Yes. I needed a file without trailing newline. > >It is not true that all dialects of C require a final newline. > > Yes, but _some_ of them do, and more importantly the C standard does. But again - that is almost irrelevant. Emacs must enable me to do what I want to or need to do. It is nice if it warns me when it thinks something might be wrong. If emacs thinks that the file being edited perhaps is a C program (for example because the name ends in .c), and moreover that I perhaps want to create a file that satisfies the C99 standard, then it should warn. It should not do anything at all on its own accord behind my back. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 2:08 ` Andries Brouwer @ 2004-11-21 10:00 ` Miles Bader 2004-11-21 11:38 ` Andries Brouwer 2004-11-21 11:06 ` David Kastrup ` (2 subsequent siblings) 3 siblings, 1 reply; 88+ messages in thread From: Miles Bader @ 2004-11-21 10:00 UTC (permalink / raw) Cc: Alan Mackenzie, Jari Aalto, emacs-devel Feel free to change the setting in your .emacs. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 10:00 ` Miles Bader @ 2004-11-21 11:38 ` Andries Brouwer 2004-11-21 12:08 ` Alfred M. Szmidt 2004-11-21 12:53 ` Miles Bader 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 11:38 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 07:00:08PM +0900, Miles Bader wrote: > Feel free to change the setting in your .emacs. That is the typical defensive developer reaction that makes sure bugs stay for a long time. The next-line command is a cursor movement command, but it used to add lines to the file if you went past end-of-file. A bad bug, but for years people said that individual users could fix it in their individual .emacs files. And thus it happened that thousands of people had something like (global-set-key "\^N" 'my-next-line) (defun my-next-line (arg) "next-line, but do not go past end of buffer" (interactive "p") (if (not (eobp)) (next-line arg))) in their .emacs. And thousands of others were bitten. If there is a bug in emacs it must be fixed in emacs. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:38 ` Andries Brouwer @ 2004-11-21 12:08 ` Alfred M. Szmidt 2004-11-21 12:45 ` Andries Brouwer 2004-11-21 12:53 ` Miles Bader 1 sibling, 1 reply; 88+ messages in thread From: Alfred M. Szmidt @ 2004-11-21 12:08 UTC (permalink / raw) Cc: andries.brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles > 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! ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:08 ` Alfred M. Szmidt @ 2004-11-21 12:45 ` Andries Brouwer 2004-11-21 12:58 ` Alfred M. Szmidt 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 12:45 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles On Sun, Nov 21, 2004 at 01:08:50PM +0100, Alfred M. Szmidt wrote: > I for one consider it a good thing, and consider > files that do not have a final newline broken. And require-final-newline is not good enough for you? You need a separate c-require-final-newline? Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:45 ` Andries Brouwer @ 2004-11-21 12:58 ` Alfred M. Szmidt 2004-11-21 13:03 ` Andries Brouwer 2004-11-22 0:03 ` Stefan Monnier 0 siblings, 2 replies; 88+ messages in thread From: Alfred M. Szmidt @ 2004-11-21 12:58 UTC (permalink / raw) Cc: Andries.Brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:58 ` Alfred M. Szmidt @ 2004-11-21 13:03 ` Andries Brouwer 2004-11-21 13:09 ` Alfred M. Szmidt 2004-11-22 0:03 ` Stefan Monnier 1 sibling, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:03 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles On Sun, Nov 21, 2004 at 01:58:12PM +0100, Alfred M. Szmidt wrote: > And require-final-newline is not good enough for you? You need a > separate c-require-final-newline? > > Did it occur to you You did not answer the question. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:03 ` Andries Brouwer @ 2004-11-21 13:09 ` Alfred M. Szmidt 0 siblings, 0 replies; 88+ messages in thread From: Alfred M. Szmidt @ 2004-11-21 13:09 UTC (permalink / raw) Cc: Andries.Brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:58 ` Alfred M. Szmidt 2004-11-21 13:03 ` Andries Brouwer @ 2004-11-22 0:03 ` Stefan Monnier 1 sibling, 0 replies; 88+ messages in thread From: Stefan Monnier @ 2004-11-22 0:03 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, jari.aalto, acm, snogglethorpe, miles > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:38 ` Andries Brouwer 2004-11-21 12:08 ` Alfred M. Szmidt @ 2004-11-21 12:53 ` Miles Bader 2004-11-21 13:00 ` Andries Brouwer 1 sibling, 1 reply; 88+ messages in thread From: Miles Bader @ 2004-11-21 12:53 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, emacs-devel, miles > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:53 ` Miles Bader @ 2004-11-21 13:00 ` Andries Brouwer 2004-11-21 13:14 ` David Kastrup 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:00 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 09:53:07PM +0900, Miles Bader wrote: > > in their .emacs. And thousands of others were bitten. > > There's the difference, of course -- there probably aren't more than a > handful of people who object to Emacs making sure their .c files end > in a newline, and I expect their are far more people who _like_ the > feature. Emacs defaults are intended to be useful for the majority. Aha. So you left your previous sidetrack and now come to a new possible objection, namely the one that having a c-require-final-newline different from require-final-newline is useful for the majority. Is that really what you believe? Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:00 ` Andries Brouwer @ 2004-11-21 13:14 ` David Kastrup 2004-11-21 13:35 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 13:14 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, snogglethorpe, emacs-devel, miles Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 09:53:07PM +0900, Miles Bader wrote: > >> > in their .emacs. And thousands of others were bitten. >> >> There's the difference, of course -- there probably aren't more >> than a handful of people who object to Emacs making sure their .c >> files end in a newline, and I expect their are far more people who >> _like_ the feature. Emacs defaults are intended to be useful for >> the majority. > > Aha. So you left your previous sidetrack and now come to a new > possible objection, namely the one that having a > c-require-final-newline different from require-final-newline is > useful for the majority. Is that really what you believe? For what it's worth, that is what I believe. And obviously it is what the people responsible for the current behavior believe. Emacs is not written by lunatics randomly changing code and seeing whether people complain, even though you seem to have that impression. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:14 ` David Kastrup @ 2004-11-21 13:35 ` Andries Brouwer 2004-11-21 13:41 ` David Kastrup 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:35 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, Jari Aalto, Alan Mackenzie, snogglethorpe, miles On Sun, Nov 21, 2004 at 02:14:21PM +0100, David Kastrup wrote: > For what it's worth, that is what I believe. OK. > And obviously it is what the people responsible for > the current behavior believe. I do not think so. Most likely they are sorry that this happened. > Emacs is not written by lunatics Please ... don't start this type of silliness. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:35 ` Andries Brouwer @ 2004-11-21 13:41 ` David Kastrup 2004-11-21 13:54 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 13:41 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, snogglethorpe, emacs-devel, miles Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 02:14:21PM +0100, David Kastrup wrote: > >> For what it's worth, that is what I believe. > > OK. > >> And obviously it is what the people responsible for >> the current behavior believe. > > I do not think so. Most likely they are sorry that this happened. Variables are not introduced by accident. >> Emacs is not written by lunatics > > Please ... don't start this type of silliness. Oh, I am not starting it. It is just paraphrasing your statement that Emacs authors are sorry that when they introduce a variable that it happens to do just the job that it has been invented for in the first place. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:41 ` David Kastrup @ 2004-11-21 13:54 ` Andries Brouwer 2004-11-21 15:54 ` Thien-Thi Nguyen 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:54 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel, Jari Aalto, Alan Mackenzie, snogglethorpe, miles On Sun, Nov 21, 2004 at 02:41:24PM +0100, David Kastrup wrote: > > I do not think so. Most likely they are sorry that this happened. > > Variables are not introduced by accident. This is a side discussion, but let me answer once. Variables are often introduced out of ignorance. (Not the pejorative ignorance but the lack-of-information ignorance.) There is a certain behaviour, and it gets complaints. Now what? Shall we change it? But it could be that someone depends on it. Let us introduce an additional variable so that people can select both old and new behaviour. This procedure happens all the time. In many cases there is no evidence that there actually exist people who want the old behaviour. But introducing an additional choice is not an unconditional improvement. Each variable makes the system more complicated, and therefore more difficult to use. That is, each new variable makes the system a bit worse. New variables should be introduced only when they offer an important new choice. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:54 ` Andries Brouwer @ 2004-11-21 15:54 ` Thien-Thi Nguyen 0 siblings, 0 replies; 88+ messages in thread From: Thien-Thi Nguyen @ 2004-11-21 15:54 UTC (permalink / raw) Cc: emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: New variables should be introduced only when they offer an important new choice. the verbosity produced (or induced) by this topic indicates to me that there is lots of importance involved. either the importance is recognized and codified (even if awkwardly), or the importance is glossed over to re-emerge as bug reports. if you would characterize your observations as a bug-report, i think it is reasonable and responsible to describe to you the mechanisms you can use to achieve the desired behavior. if you would, on the other hand, characterize your observations as advice on how to design things, pointers to past discussion would also be appropriate. i see these kinds of responses, so it seems to me people are acting well. i think you have good ideas but it seems you do not accept that after a certain point, goodness is measured in many more ways than simply those that are based on the ideal. (this is fortunate for people who grow more ugly w/ age, like me. ;-) lthough it is a lot to ask, perhaps when the next issue comes along, could you involve yourself early on, so that what good advice you have to share has the best prospects of finding traction? thi ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 2:08 ` Andries Brouwer 2004-11-21 10:00 ` Miles Bader @ 2004-11-21 11:06 ` David Kastrup 2004-11-21 11:45 ` Andries Brouwer 2004-11-21 11:41 ` Alan Mackenzie 2004-11-21 14:47 ` Andreas Schwab 3 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 11:06 UTC (permalink / raw) Cc: Alan Mackenzie, Jari Aalto, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote: > >> >It is not the goal of an editor to force the user to write syntactically >> >correct programs. >> >> Well, that is debateable. I'd tend to agree with you, whilst pointing >> out that in this case, there was no "force" used [see below]. >> >> An equally valid argument is that of the programmer who hacks through the >> night and sets off a build (which takes several hours to complete), goes >> home for some sleep, then comes back into the office the following >> afternoon. He then finds that the build failed for lack of a final >> newline in one of the files. Then he expostulates "FAQ! Why couldn't >> that stupid editor have put that stupid newline in for me?". > > That is a phantasy argument. > Old compilers just accept the C source without final newline > without any complaint. Some newer pedantic ones print a warning. I would not be surprised if there were compilers that just dropped the last character of a line read in, assuming it to be a linefeed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:06 ` David Kastrup @ 2004-11-21 11:45 ` Andries Brouwer 2004-11-21 12:08 ` David Kastrup 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 11:45 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 12:06:24PM +0100, David Kastrup wrote: > Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > > On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote: > > > >> >It is not the goal of an editor to force the user to write syntactically > >> >correct programs. > >> > >> Well, that is debateable. I'd tend to agree with you, whilst pointing > >> out that in this case, there was no "force" used [see below]. > >> > >> An equally valid argument is that of the programmer who hacks through the > >> night and sets off a build (which takes several hours to complete), goes > >> home for some sleep, then comes back into the office the following > >> afternoon. He then finds that the build failed for lack of a final > >> newline in one of the files. Then he expostulates "FAQ! Why couldn't > >> that stupid editor have put that stupid newline in for me?". > > > > That is a phantasy argument. > > Old compilers just accept the C source without final newline > > without any complaint. Some newer pedantic ones print a warning. > > I would not be surprised if there were compilers that just dropped the > last character of a line read in, assuming it to be a linefeed. That is a phantasy argument, and you know it. But this is a completely irrevant side discussion. It is not the case that emacs has the goal to force users to only write syntactically correct programs - and, as said, there is no guarantee at all that a file with a name ending in .c is in fact a C99 program. In fact there is no guarantee that it is a C program at all. For example, I have old files where the .c extension means that it was compressed using the "compact" utility. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:45 ` Andries Brouwer @ 2004-11-21 12:08 ` David Kastrup 0 siblings, 0 replies; 88+ messages in thread From: David Kastrup @ 2004-11-21 12:08 UTC (permalink / raw) Cc: Alan Mackenzie, Jari Aalto, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > It is not the case that emacs has the goal to force users > to only write syntactically correct programs - > and, as said, there is no guarantee at all that a file > with a name ending in .c is in fact a C99 program. > > In fact there is no guarantee that it is a C program at all. > For example, I have old files where the .c extension means > that it was compressed using the "compact" utility. And you edit those files in C mode in Emacs and save them again? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 2:08 ` Andries Brouwer 2004-11-21 10:00 ` Miles Bader 2004-11-21 11:06 ` David Kastrup @ 2004-11-21 11:41 ` Alan Mackenzie 2004-11-21 12:26 ` Andries Brouwer ` (2 more replies) 2004-11-21 14:47 ` Andreas Schwab 3 siblings, 3 replies; 88+ messages in thread From: Alan Mackenzie @ 2004-11-21 11:41 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel [cc's have been changed] Hi, Andries On Sun, 21 Nov 2004, Andries Brouwer wrote: >On Sat, Nov 20, 2004 at 03:14:24PM +0000, Alan Mackenzie wrote: >> An equally valid argument is that of the programmer who hacks through >> the night and sets off a build (which takes several hours to >> complete), goes home for some sleep, then comes back into the office >> the following afternoon. He then finds that the build failed for lack >> of a final newline in one of the files. Then he expostulates "FAQ! >> Why couldn't that stupid editor have put that stupid newline in for >> me?". >That is a phantasy argument. >Old compilers just accept the C source without final newline >without any complaint. Some newer pedantic ones print a warning. Maybe you're right here. I don't know. I've had a search through the archives. I found your bug report in gnu.emacs.bug recently, and a previous bug report (strangely enough, with exactly the same subject, "cc-mode adds newlines" ;-), from Heinrich Rommerskirchen <heinrich.rommerskirchen@siemens.com> on Thu, 23 Jan 2003 13:17:12. Maybe you've read through that thread already. That also lead to discussion on the CC Mode mailing list (archived on <http://cc-mode.sourceforge.net> somewhere), which led to the introduction of `c-require-final-newline'. Heinrich Rommerskirchen's complaint was that c-mode silently set require-final-newline to t without him being able to do anything about it. c-require-final-newline was the answer to that, giving people a way to "do something about it". It was given the default value ((c-mode . t) (c++-mode .t) (objc-mode .t)) so as not to change the behaviour for users used to the old way. [ .... ] >I have been using C for thirty years or so. In which case, change my suggestions yesterday from "a disco" and "a game of squash" to "a concert" and "a game of bowls". ;-). I've been using C for about fifteen years, and I've been working on CC Mode for about three years. >> >In this case of newlines emacs considers itself as final authority. That >> >is a serious bug. It must ask by default. >> No. It is _your_ copy of Emacs, and it is _your_ choice how you >> configure it. You can actually set Emacs up to ask about >> final-newlines first (see the Emacs manual, page "Saving", then use >> that information to set c-require-final-newline), but you've probably >> found that out already. >That is a phantasy argument. If emacs dumps core when I do something, >and there is a variable do-not-dump-core you cannot point out the >existence of the variable to dismiss the bug. Of course not. Emacs dumping core (and it does happen) is absolutely a bug, to be fixed. Adding terminal newlines is a (mis)feature of dubious value. They're essentially different things. >The alist c-require-final-newline was an extremely poor design decision. >The single variable require-final-newline is excellent, especially if >the default is ask. The single variable require-final-newline was what led to Heinrich Rommerskirchen's difficulties. c-require-final-newline was the solution (or "solution"). Before that, c-mode silently set require-final-newline to t, and the only remedy was to write a hook function. That was surely worse. As from CC Mode 5.30, you can fix this by setting a customization variable. >It is very poor design to add switches and variables just because >it is a logical possibility that someone might want it. In this case, somebody (who had the same problem as you) actually needed it. Maybe the solution wasn't optimal. >It is not true that emacs is getting better and better as the number of >variables that can be customised increases. That's a whole different discussion. ;-) But it's worth pointing out that when Emacs 21.1 came out, it had the "fringe" to the left and right of each frame, and that was one of the few features that could not be turned off by a customisation variable. gnu.emacs.help was flooded with requests "how do I turn this damn thing off?". >> I think your complaint here is that you didn't know about the setting, >> and had no reason to suspect it might exist, and therefore no reason >> to spend weeks meticulously searching through the manual for anything >> random which might mess up your files. That's a fair complaint. >Not precisely. The (stupid, buggy) variable that was added later does >not yet exist in my version of emacs. For me the fastest would have >been to save the file, rename it, delete the final newline, rename it >back. Silly kludges showing the brokenness of emacs. That's somewhat unfair. `require-final-newline' is something that, with the benefit of hindsight, was perhaps a bad idea. Having major modes setting it was worse. But if the Emacs developers hadn't put in things like that, most of which have proven their worth, Emacs wouldn't be what it is. Please read through all the archives I mentioned above (if you haven't done so already), mull over all the issues, and if you still think things could be improved make a concrete suggestion. Either <bug-cc-mode@gnu.org> or <emacs-devel@gnu.org> would be the right place to send this. >> It's also fair for me to ask, did you suffer any actual damage from >> this terminating newline? Something like the source file being an >> input to some scriptfile, rather than just being compiled, and that >> script fouling up? >Yes. I needed a file without trailing newline. OK. Set c-require-final-newline to ((c-mode . ask) (c++-mode . ask) (objc-mode . ask)). You can do this either through M-x customize-group <CR> C <CR>, etc., or by putting it by hand into one of your hook functions in your .emacs file. Then, at the very least, _your_ Emacs will work properly. >> >It is not true that all dialects of C require a final newline. >> Yes, but _some_ of them do, and more importantly the C standard does. >But again - that is almost irrelevant. >Emacs must enable me to do what I want to or need to do. >It is nice if it warns me when it thinks something might be wrong. Somebody, sometime, wanted or needed the final newline inserted automatically. She got that. This feature is now in such a mess that it's difficult (or impossible) to fix so that it's right for everybody. >If emacs thinks that the file being edited perhaps is a C program >(for example because the name ends in .c), and moreover that I >perhaps want to create a file that satisfies the C99 standard, >then it should warn. It should not do anything at all on its own accord >behind my back. I can only apologise for myself and on behalf of the CC Mode maintainer (Martin Stjernholm) and the Emacs developers as a body. We don't get everything right every time. >Andries -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:41 ` Alan Mackenzie @ 2004-11-21 12:26 ` Andries Brouwer 2004-11-21 12:34 ` David Kastrup ` (2 more replies) 2004-11-22 0:12 ` Stefan Monnier 2004-11-22 14:07 ` Richard Stallman 2 siblings, 3 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 12:26 UTC (permalink / raw) Cc: bug-cc-mode, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 11:41:34AM +0000, Alan Mackenzie wrote: > I've had a search through the archives. I found your bug report in > gnu.emacs.bug recently, and a previous bug report (strangely enough, with > exactly the same subject, "cc-mode adds newlines" ;-), from > Heinrich Rommerskirchen <heinrich.rommerskirchen@siemens.com> on Thu, 23 > Jan 2003 13:17:12. Maybe you've read through that thread already. That > also lead to discussion on the CC Mode mailing list (archived on > <http://cc-mode.sourceforge.net> somewhere), which led to the > introduction of `c-require-final-newline'. > > Heinrich Rommerskirchen's complaint was that c-mode silently set > require-final-newline to t without him being able to do anything about > it. c-require-final-newline was the answer to that, giving people a way > to "do something about it". It was given the default value ((c-mode . t) > (c++-mode .t) (objc-mode .t)) so as not to change the behaviour for users > used to the old way. Yes, indeed. Heinrich Rommerskirchen wrote: cc-mode tries to be smart and adds newlines to a file without informing the user and without any easily found option to suppress it. You see - nobody wants c-require-final-newline. It is a misfeature. Heinrich Rommerskirchen hated getting a final newline added by emacs behind his back. I hate it. One does not become happier if there is a complicated way to make emacs not do it. Emacs should not do it in the first place. This misfeature was only added because cc-mode had another misfeature: it blindly overrides global variable settings. That makes life much more difficult for users. If they do something globally, they also have to make the same change locally for all major modes they will encounter, in order to have a uniform interface. require-final-newline is a beautiful variable. Set it to ask by default and some people will make it always true, some will make it always false. Many will leave it to ask. c-require-final-newline is an ugly bug. Who will change its value? Only people who have been bitten by the fact that emacs changed their files, spent time in debugging, spent time in searching the docs, spent time in searching the net. And when c-require-final-newline is just equal to require-final-newline and the latter has default ask, then nobody is ever bitten. If you insist that c-require-final-newline must exist, also that must have default ask. But there is really no reason why anybody would set it differently from require-final-newline. If one only edits text files, set require-final-newline to true. If one sometimes edits arbitrary files, set it to ask. Also an arbitrary file can have a name ending in .c. If one always knows what one is doing and never makes mistakes, set it to false. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:26 ` Andries Brouwer @ 2004-11-21 12:34 ` David Kastrup 2004-11-21 12:49 ` Andries Brouwer 2004-11-21 13:52 ` Alan Mackenzie [not found] ` <01c4d002$Blat.v2.2.2$50b57dc0@zahav.net.il> 2 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 12:34 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > Yes, indeed. Heinrich Rommerskirchen wrote: > > cc-mode tries to be smart and adds newlines to a file without > informing the user and without any easily found option to > suppress it. > > You see - nobody wants c-require-final-newline. Telling your opponents in a discussion that you consider them to be nobody is not exactly going to help get your point across. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:34 ` David Kastrup @ 2004-11-21 12:49 ` Andries Brouwer 2004-11-21 13:08 ` David Kastrup 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 12:49 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote: > Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > > Yes, indeed. Heinrich Rommerskirchen wrote: > > > > cc-mode tries to be smart and adds newlines to a file without > > informing the user and without any easily found option to > > suppress it. > > > > You see - nobody wants c-require-final-newline. > > Telling your opponents in a discussion that you consider them to be > nobody is not exactly going to help get your point across. So far I have not met anyone who required it. Must I assume from your reaction that you do require separate require-final-newline and c-require-final-newline variables? Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:49 ` Andries Brouwer @ 2004-11-21 13:08 ` David Kastrup 2004-11-21 13:28 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 13:08 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 01:34:07PM +0100, David Kastrup wrote: >> Andries Brouwer <Andries.Brouwer@cwi.nl> writes: >> >> > Yes, indeed. Heinrich Rommerskirchen wrote: >> > >> > cc-mode tries to be smart and adds newlines to a file without >> > informing the user and without any easily found option to >> > suppress it. >> > >> > You see - nobody wants c-require-final-newline. >> >> Telling your opponents in a discussion that you consider them to be >> nobody is not exactly going to help get your point across. > > So far I have not met anyone who required it. > Must I assume from your reaction that you do require separate > require-final-newline and c-require-final-newline variables? I was fine already with the previous behavior that unconditionally sets require-final-newline in C modes. But I don't mind that for the likes of you a customization variable c-require-final-newline has been added. I don't particularly like the idea that every mode that has particular requirements for a variable like that has to have a separately named variable of its own: this makes it more difficult to figure out what happens. I think that in the long run something more transparent for mode-specific defaults should be found. But at the moment, I don't have a good idea for that. Maybe it would be possible to have something like See also c-require-final-newline in the displayed documentation for require-final-newline automatically, by having the loading of c-require-final-newline place an appropriate property on require-final-newline that is then interpreted by the documentation printer. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:08 ` David Kastrup @ 2004-11-21 13:28 ` Andries Brouwer 2004-11-21 13:37 ` David Kastrup [not found] ` <01c4d003$Blat.v2.2.2$3d9a05c0@zahav.net.il> 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:28 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 02:08:41PM +0100, David Kastrup wrote: > I don't particularly like the idea that every mode that has particular > requirements for a variable like that has to have a separately named > variable of its own: this makes it more difficult to figure out what > happens. I think that in the long run something more transparent for > mode-specific defaults should be found. Yes, indeed. There is a general discussion here on the use of mode variables, but I am afraid of commenting on that right now - like to avoid blowing up this small discussion into too many threads. Maybe later. My point today is: emacs must never unexpectedly change a file behind the user's back. That is, the default settings must be so that emacs asks before changing. This general principle applied to the final newline leads to a require-final-newline with default ask. I do not believe that it is meaningful to have a separate c-require-final-newline, but should it turn out that people exist that really want different behaviours depending on major mode, then for all major modes the default must again be ask (or the value of the global variable). Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:28 ` Andries Brouwer @ 2004-11-21 13:37 ` David Kastrup 2004-11-21 13:43 ` Andries Brouwer [not found] ` <01c4d003$Blat.v2.2.2$3d9a05c0@zahav.net.il> 1 sibling, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 13:37 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > My point today is: > emacs must never unexpectedly change a file behind the user's back. It doesn't. Only when you edit and save a modified file, does it interpret the variable. > That is, the default settings must be so that emacs asks > before changing. I disagree. The default for most modes should be to keep the files as they are without asking. But since files without newline at the end are not valid C files, the default for C clearly should be different. > I do not believe that it is meaningful to have a separate > c-require-final-newline, but should it turn out that people exist > that really want different behaviours depending on major mode, then > for all major modes the default must again be ask (or the value of > the global variable). That's your opinion, as you have made abundantly clear already. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:37 ` David Kastrup @ 2004-11-21 13:43 ` Andries Brouwer 2004-11-21 13:51 ` David Kastrup 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 13:43 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 02:37:49PM +0100, David Kastrup wrote: > Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > > My point today is: > > emacs must never unexpectedly change a file behind the user's back. > > It doesn't. Only when you edit and save a modified file, does it > interpret the variable. That is not quite correct. Also when I save an unmodified file under a different name the "copy" gets an extra newline. > > That is, the default settings must be so that emacs asks > > before changing. > > I disagree. The default for most modes should be to keep the files as > they are without asking. But since files without newline at the end > are not valid C files, the default for C clearly should be different. You mean "are not valid C99 files". But they are valid C files for many other C dialects. The mode is not called c99 mode. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:43 ` Andries Brouwer @ 2004-11-21 13:51 ` David Kastrup 2004-11-21 14:03 ` Andries Brouwer 0 siblings, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 13:51 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 02:37:49PM +0100, David Kastrup wrote: >> >> I disagree. The default for most modes should be to keep the files >> as they are without asking. But since files without newline at the >> end are not valid C files, the default for C clearly should be >> different. > > You mean "are not valid C99 files". > But they are valid C files for many other C dialects. "happens to work" and "valid" are two different things. I don't know any C standard that would specify well-defined behavior for a file with a missing newline at the end. The term "valid" is defined by a language definition, not by the behavior of a particular implementation. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:51 ` David Kastrup @ 2004-11-21 14:03 ` Andries Brouwer 2004-11-21 15:01 ` David Kastrup 2004-11-21 15:18 ` Andreas Schwab 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 14:03 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote: > "happens to work" and "valid" are two different things. I don't know > any C standard that would specify well-defined behavior for a file > with a missing newline at the end. The term "valid" is defined by a > language definition, not by the behavior of a particular > implementation. Let me quote the Reference Manual in front of me. "Blanks, tabs, newlines, and comments (collectively, "white space") are ignored except as they serve to separate tokens." Not "happen to work" - it is the C definition. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 14:03 ` Andries Brouwer @ 2004-11-21 15:01 ` David Kastrup 2004-11-21 15:08 ` Andries Brouwer 2004-11-21 15:18 ` Andreas Schwab 1 sibling, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 15:01 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote: > >> "happens to work" and "valid" are two different things. I don't know >> any C standard that would specify well-defined behavior for a file >> with a missing newline at the end. The term "valid" is defined by a >> language definition, not by the behavior of a particular >> implementation. > > Let me quote the Reference Manual Which one? > in front of me. > > "Blanks, tabs, newlines, and comments (collectively, "white space") > are ignored except as they serve to separate tokens." > > Not "happen to work" - it is the C definition. Well, if you look in the wrong places... Both ANSI C and ANSI C++ standards contain the demand: "The program must end with a newline character." -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:01 ` David Kastrup @ 2004-11-21 15:08 ` Andries Brouwer 2004-11-22 19:21 ` Kevin Rodgers 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 15:08 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 04:01:57PM +0100, David Kastrup wrote: > Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > Let me quote the Reference Manual > > Which one? The original one. D.M. Ritchie, Bell Labs. "This manual describes the C language on the DEC PDP-11, the DEC VAX-11, the Honeywell 6000, the IBM System/370, and the Interdata 8/32." Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:08 ` Andries Brouwer @ 2004-11-22 19:21 ` Kevin Rodgers 0 siblings, 0 replies; 88+ messages in thread From: Kevin Rodgers @ 2004-11-22 19:21 UTC (permalink / raw) Andries Brouwer wrote: > On Sun, Nov 21, 2004 at 04:01:57PM +0100, David Kastrup wrote: > >>Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > >>>Let me quote the Reference Manual >> >>Which one? > > > The original one. D.M. Ritchie, Bell Labs. > > "This manual describes the C language on the DEC PDP-11, the DEC VAX-11, > the Honeywell 6000, the IBM System/370, and the Interdata 8/32." Which of those implementations are you using? -- Kevin Rodgers ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 14:03 ` Andries Brouwer 2004-11-21 15:01 ` David Kastrup @ 2004-11-21 15:18 ` Andreas Schwab 2004-11-21 15:36 ` Andries Brouwer 1 sibling, 1 reply; 88+ messages in thread From: Andreas Schwab @ 2004-11-21 15:18 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 02:51:49PM +0100, David Kastrup wrote: > >> "happens to work" and "valid" are two different things. I don't know >> any C standard that would specify well-defined behavior for a file >> with a missing newline at the end. The term "valid" is defined by a >> language definition, not by the behavior of a particular >> implementation. > > Let me quote the Reference Manual in front of me. > > "Blanks, tabs, newlines, and comments (collectively, "white space") > are ignored except as they serve to separate tokens." So you agree that adding a newline at the end of a valid C source file can never produce an invalid C source file? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:18 ` Andreas Schwab @ 2004-11-21 15:36 ` Andries Brouwer 0 siblings, 0 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 15:36 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 04:18:08PM +0100, Andreas Schwab wrote: > So you agree that adding a newline at the end of a valid C source file can > never produce an invalid C source file? I do not know of examples where that is the case. There are many changes of layout that would not change the semantics of a C program for most purposes. But there can be special reasons to wish for a file with special properties. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
[parent not found: <01c4d003$Blat.v2.2.2$3d9a05c0@zahav.net.il>]
* Re: cc-mode adds newlines [not found] ` <01c4d003$Blat.v2.2.2$3d9a05c0@zahav.net.il> @ 2004-11-21 21:28 ` Andries Brouwer 2004-11-22 4:35 ` Eli Zaretskii 2004-11-22 9:04 ` David Kastrup 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 21:28 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 09:48:38PM +0200, Eli Zaretskii wrote: > > Date: Sun, 21 Nov 2004 14:28:04 +0100 > > From: Andries Brouwer <Andries.Brouwer@cwi.nl> > > Cc: bug-cc-mode@gnu.org, Alan Mackenzie <acm@muc.de>, > > Andries Brouwer <Andries.Brouwer@cwi.nl>, emacs-devel@gnu.org > > > > My point today is: > > emacs must never unexpectedly change a file behind the user's back. > > Obviously, those of us who set require-final-newline to t disagree. > So what is the point of saying in yet another way what you've already > said so many times? People are slow in getting my point, that is why some repetition seems to be needed. For example, you think that setting require-final-newline to t means disagreeing with me. But I like the variable require-final-newline, absolutely nothing wrong with it, especially when the default is ask. If one changes it to t then one has asked emacs to change one's files. Probably one does so after considering what kind of files one usually edits. A conscious decision. So, if you set require-final-newline to true and emacs inserts the final newline then there is nothing unexpected about the change. But if you do not set require-final-newline to true, in fact set it to ask, and still emacs inserts a final newline without asking, that is really bad. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:28 ` Andries Brouwer @ 2004-11-22 4:35 ` Eli Zaretskii 2004-11-22 9:04 ` David Kastrup 1 sibling, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2004-11-22 4:35 UTC (permalink / raw) Cc: bug-cc-mode, acm, emacs-devel > Date: Sun, 21 Nov 2004 22:28:06 +0100 > From: Andries Brouwer <Andries.Brouwer@cwi.nl> > Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>, bug-cc-mode@gnu.org, acm@muc.de, > emacs-devel@gnu.org > > People are slow in getting my point That's because you are slow in getting theirs. > So, if you set require-final-newline to true and emacs inserts the > final newline then there is nothing unexpected about the change. You obviously think that people who customize Emacs remember by heart every single customization they do. It may come as a surprise to you, then, that I actually needed to look it up in my .emacs. So much for ``concious'' and ``nothing unexpected''. > But if you do not set require-final-newline to true, in fact set > it to ask, and still emacs inserts a final newline without asking, > that is really bad. Others tried to explain to you in so many words why it might be actually good. Perhaps you should re-read those messages. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:28 ` Andries Brouwer 2004-11-22 4:35 ` Eli Zaretskii @ 2004-11-22 9:04 ` David Kastrup 1 sibling, 0 replies; 88+ messages in thread From: David Kastrup @ 2004-11-22 9:04 UTC (permalink / raw) Cc: bug-cc-mode, acm, Eli Zaretskii, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 09:48:38PM +0200, Eli Zaretskii wrote: >> > Date: Sun, 21 Nov 2004 14:28:04 +0100 >> > From: Andries Brouwer <Andries.Brouwer@cwi.nl> >> > Cc: bug-cc-mode@gnu.org, Alan Mackenzie <acm@muc.de>, >> > Andries Brouwer <Andries.Brouwer@cwi.nl>, emacs-devel@gnu.org >> > >> > My point today is: >> > emacs must never unexpectedly change a file behind the user's back. >> >> Obviously, those of us who set require-final-newline to t disagree. >> So what is the point of saying in yet another way what you've already >> said so many times? > > People are slow in getting my point, that is why some repetition > seems to be needed. If you let go of the assumption that you are the only intelligent person on this planet, it might make communicating with you less unpleasant. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 12:26 ` Andries Brouwer 2004-11-21 12:34 ` David Kastrup @ 2004-11-21 13:52 ` Alan Mackenzie 2004-11-21 14:29 ` Andries Brouwer 2004-11-21 15:50 ` Kai Grossjohann [not found] ` <01c4d002$Blat.v2.2.2$50b57dc0@zahav.net.il> 2 siblings, 2 replies; 88+ messages in thread From: Alan Mackenzie @ 2004-11-21 13:52 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Hi, Andries! On Sun, 21 Nov 2004, Andries Brouwer wrote: >On Sun, Nov 21, 2004 at 11:41:34AM +0000, Alan Mackenzie wrote: >> I've had a search through the archives. I found your bug report in >> gnu.emacs.bug recently, and a previous bug report (strangely enough, with >> exactly the same subject, "cc-mode adds newlines" ;-), from >> Heinrich Rommerskirchen <heinrich.rommerskirchen@siemens.com> on Thu, 23 >> Jan 2003 13:17:12. Maybe you've read through that thread already. That >> also lead to discussion on the CC Mode mailing list (archived on >> <http://cc-mode.sourceforge.net> somewhere), which led to the >> introduction of `c-require-final-newline'. >> Heinrich Rommerskirchen's complaint was that c-mode silently set >> require-final-newline to t without him being able to do anything about >> it. c-require-final-newline was the answer to that, giving people a way >> to "do something about it". It was given the default value ((c-mode . t) >> (c++-mode .t) (objc-mode .t)) so as not to change the behaviour for users >> used to the old way. >Yes, indeed. Heinrich Rommerskirchen wrote: > cc-mode tries to be smart and adds newlines to a file without > informing the user and without any easily found option to suppress > it. >You see - nobody wants c-require-final-newline. Untrue - Alfred M. Szmidt, for one, wants it. If nobody wanted it, it wouldn't have been implemented. >It is a misfeature. Heinrich Rommerskirchen hated getting a final >newline added by emacs behind his back. I hate it. Yes, I think that's clear by now. ;-) The difference is, Heinrich had no easy way of disabling this "feature". Thanks to his bug report, you do (assuming you've got CC Mode >= 5.30. If you haven't, get 5.30.9 from <http://cc-mode.sourceforge.net.release.php>). >One does not become happier if there is a complicated way to make emacs >not do it. Emacs should not do it in the first place. It is a simple way. The only difficult thing about it is discovering its existence. >This misfeature was only added because cc-mode had another misfeature: >it blindly overrides global variable settings. Yes indeed, but not blindly. For example, it changes the paragraph-start and paragraph-separate variables to recognise comment-prefices (the "* " you have at the beginning of each comment line), so that when you do M-q in a block comment, it doesn't just jumble the entire comment into a compact mess. >That makes life much more difficult for users. If they do something >globally, they also have to make the same change locally for all >major modes they will encounter, in order to have a uniform interface. Users often want these things set differently in different modes. >require-final-newline is a beautiful variable. Set it to ask by default >and some people will make it always true, some will make it always false. >Many will leave it to ask. And some will want it t in C Mode and nil in Text Mode, and really don't want to be bothered answering the question "Add one? (y or n)" twenty times a day. >c-require-final-newline is an ugly bug. Who will change its value? _You_ will. By putting the correct (for you) setting of it in your .emacs file. >Only people who have been bitten by the fact that emacs changed their >files, spent time in debugging, spent time in searching the docs, spent >time in searching the net. And when c-require-final-newline is just >equal to require-final-newline and the latter has default ask, then >nobody is ever bitten. OK, you've been bitten. Sorry. It's happened already and it can't now be undone. The criticism in the previous paragraph is fair. But read the threads from January 2003, the ones that lead to the creation of that variable, and see if you can come up with a better solution, given the conflicting demands of (i) full customizability; (ii) the need to maintain compatibility with existing behaviour; (iii) the need to keep users informed about what's being done; (iv) the need not to irritate users with excessive "are you sure?" type questions; ..... >If you insist that c-require-final-newline must exist, also that >must have default ask. But there is really no reason why >anybody would set it differently from require-final-newline. Yes there is - To have appropriate (but different) values in Text Mode, C Mode and AWK Mode, to name just three. And if we changed the default value to ask, complaints from other people would start rolling in. That's guaranteed. ;-( >If one only edits text files, set require-final-newline to true. >If one sometimes edits arbitrary files, set it to ask. >Also an arbitrary file can have a name ending in .c. >If one always knows what one is doing and never makes mistakes, >set it to false. Other people see things differently. Emacs tries to cater for all different tastes and preferences, and deciding on the Right defaults is difficult. Configure your .emacs file so that you won't get caught out again. Other than that, I don't think anybody can offer you much more help. >Andries -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:52 ` Alan Mackenzie @ 2004-11-21 14:29 ` Andries Brouwer 2004-11-21 15:07 ` David Kastrup 2004-11-21 19:03 ` Alfred M. Szmidt 2004-11-21 15:50 ` Kai Grossjohann 1 sibling, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 14:29 UTC (permalink / raw) Cc: bug-cc-mode, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote: > >You see - nobody wants c-require-final-newline. > > Untrue - Alfred M. Szmidt, for one, wants it. Did he tell you in private mail? To me he wrote "It is not relevant what I want" > If nobody wanted it, it > wouldn't have been implemented. I think that implication is false. As I just wrote to dak, a lot of stuff is implemented out of ignorance. > >require-final-newline is a beautiful variable. Set it to ask by default > >and some people will make it always true, some will make it always false. > >Many will leave it to ask. > > And some will want it t in C Mode and nil in Text Mode, and really don't > want to be bothered answering the question "Add one? (y or n)" twenty > times a day. Possibly. So far we have not discovered such users. Maybe Alfred M. Szmidt has told you in private mail that he has such preferences. I see lots of people who are unhappy. Jari Aalto writes "I agree. The problem is not just in CC mode" Stefan Monnier writes "I'd tend to agree: setting it to `ask' is fine, but only the user should set it to t if she likes it, not the major mode." Richard Stallman writes "I tend to think it is wrong for major modes to set this at all." > OK, you've been bitten. Sorry. It's happened already and it can't now > be undone. And you see: nobody will discover the existence of this variable until they have been bitten. That is, the default is unsafe - files are changed that should have been left alone. I oppose against an unsafe default. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 14:29 ` Andries Brouwer @ 2004-11-21 15:07 ` David Kastrup 2004-11-21 15:20 ` Andries Brouwer 2004-11-21 19:03 ` Alfred M. Szmidt 1 sibling, 1 reply; 88+ messages in thread From: David Kastrup @ 2004-11-21 15:07 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote: > >> And some will want it t in C Mode and nil in Text Mode, and really >> don't want to be bothered answering the question "Add one? (y or >> n)" twenty times a day. > > Possibly. So far we have not discovered such users. So what am I? An alien? I already told you that I want just that behavior. In the interest of a civilized discussion, it would be nice if you stopped doing the equivalent of putting your fingers in your ears and singing "lalala, can't hear you". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:07 ` David Kastrup @ 2004-11-21 15:20 ` Andries Brouwer 0 siblings, 0 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 15:20 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 04:07:32PM +0100, David Kastrup wrote: > Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > > > On Sun, Nov 21, 2004 at 01:52:49PM +0000, Alan Mackenzie wrote: > > > >> And some will want it t in C Mode and nil in Text Mode, and really > >> don't want to be bothered answering the question "Add one? (y or > >> n)" twenty times a day. > > > > Possibly. So far we have not discovered such users. > > So what am I? An alien? I already told you that I want just that > behavior. OK. That letter never reached my mailbox. What came into my mailbox was >> Must I assume from your reaction that you do require separate >> require-final-newline and c-require-final-newline variables? > I was fine already with the previous behavior that unconditionally > sets require-final-newline in C modes. But I don't mind that for the > likes of you a customization variable c-require-final-newline has been > added. which is a rather different statement. But now you confirm Alan Mackenzie's claim that there exists at least one person who needs distinct require-final-newline and c-require-final-newline variables. Surprising, but OK. > In the interest of a civilized discussion, Must I remind you again... Please - we talk about emacs. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 14:29 ` Andries Brouwer 2004-11-21 15:07 ` David Kastrup @ 2004-11-21 19:03 ` Alfred M. Szmidt 2004-11-21 21:19 ` Andries Brouwer 1 sibling, 1 reply; 88+ messages in thread From: Alfred M. Szmidt @ 2004-11-21 19:03 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, emacs-devel > >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. `---- ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 19:03 ` Alfred M. Szmidt @ 2004-11-21 21:19 ` Andries Brouwer 2004-11-21 21:46 ` Alfred M. Szmidt 2004-11-22 11:54 ` Benjamin Riefenstahl 0 siblings, 2 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 21:19 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 08:03:55PM +0100, Alfred M. Szmidt wrote: > > >You see - nobody wants c-require-final-newline. > > > > Untrue - Alfred M. Szmidt, for one, wants it. > > Did he tell you in private mail? To me he wrote > > "It is not relevant what I want" > > I told this on this mailing list, that you are incapable reading, is > really not my problem. > > To quote myself: > > ,---- > | > Feel free to change the setting in your .emacs. > | > | That is the typical defensive developer reaction that makes sure > | bugs stay for a long time. > | > | I suppose that it didn't occur to you that this might not be a bug? > | But something that Miles, and the rest of the world, actually thinks > | is a good idea. I for one consider it a good thing, and consider > | files that do not have a final newline broken. > `---- Enough has been said already, and I consider the discussion over. We know what is wrong. Maybe it will be fixed. The current setup is broken because it does things behind the user's back. It is also broken because the CC major mode is documented as "C mode: Major mode for editing K&R and ANSI C code", while K&R C is explicitly documented as not requiring a final newline. That makes the case for C not stronger than the case for java where no sneaky insertions are done by default. But now that you query my reading comprehension - let me explain to you that I distinguish carefully between people who want all their edited files to end in a newline (and then setting require-final-newline to true suffices) and people who do not want that, but do want all edited C files to get an automatic final newline. The part you quote suggests that you might belong to the former category, and when I enquired further, to be sure, you said that your personal opinion was not relevant. Thus, so far you never stated that you actually do want a c-require-final-newline different from require-final-newline, more or less contradicting the part you quote here. But after a little provocation people will find themselves with opinions they never imagined they could have :-) Good luck - Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:19 ` Andries Brouwer @ 2004-11-21 21:46 ` Alfred M. Szmidt 2004-11-21 22:19 ` Andries Brouwer 2004-11-22 11:54 ` Benjamin Riefenstahl 1 sibling, 1 reply; 88+ messages in thread From: Alfred M. Szmidt @ 2004-11-21 21:46 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:46 ` Alfred M. Szmidt @ 2004-11-21 22:19 ` Andries Brouwer 0 siblings, 0 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 22:19 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 10:46:51PM +0100, Alfred M. Szmidt wrote: > Thus, so far you never stated that you actually do want a > c-require-final-newline different from require-final-newline, more > or less contradicting the part you quote here. > > There is no contradiction, _some_ people might want it. It happens > that for me they are the same. Good, thank you, that is what I thought. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:19 ` Andries Brouwer 2004-11-21 21:46 ` Alfred M. Szmidt @ 2004-11-22 11:54 ` Benjamin Riefenstahl 2004-11-22 15:54 ` Andries Brouwer 1 sibling, 1 reply; 88+ messages in thread From: Benjamin Riefenstahl @ 2004-11-22 11:54 UTC (permalink / raw) Cc: emacs-devel Hi Andries, Andries Brouwer writes: > It is also broken because the CC major mode is documented as "C > mode: Major mode for editing K&R and ANSI C code", while K&R C is > explicitly documented as not requiring a final newline. You mean the K&R book explicitly said so in it's pre-standard edition? Naturally there is not really a standard definition of pre-standard C. >From what I know about C89, like most restrictions, the requirement of a final newline was most likely made because one or more compilers required it that were already implemented and used before the standard. benny ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 11:54 ` Benjamin Riefenstahl @ 2004-11-22 15:54 ` Andries Brouwer 2004-11-22 16:56 ` Andreas Schwab 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-22 15:54 UTC (permalink / raw) Cc: Andries Brouwer, emacs-devel On Mon, Nov 22, 2004 at 12:54:24PM +0100, Benjamin Riefenstahl wrote: > > It is also broken because the CC major mode is documented as "C > > mode: Major mode for editing K&R and ANSI C code", while K&R C is > > explicitly documented as not requiring a final newline. > > You mean the K&R book explicitly said so in it's pre-standard edition? I do not have the K&R book here. I quoted an earlier source that I do have here. Google also finds it various places on the web, e.g. at http://www.freaknet.org/martin/tape/stuff/docs/cman/cman1 "Blanks, tabs, newlines, and comments as described below are ignored except as they serve to separate tokens." [C Reference Manual, Dennis M. Ritchie, May 1, 1977. Reprinted in "The C Programming language" by BWK & DMR, 1978.] > Naturally there is not really a standard definition of pre-standard C. > From what I know about C89, like most restrictions, the requirement of > a final newline was most likely made because one or more compilers > required it that were already implemented and used before the > standard. Yes. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 15:54 ` Andries Brouwer @ 2004-11-22 16:56 ` Andreas Schwab 0 siblings, 0 replies; 88+ messages in thread From: Andreas Schwab @ 2004-11-22 16:56 UTC (permalink / raw) Cc: Benjamin Riefenstahl, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > [C Reference Manual, Dennis M. Ritchie, May 1, 1977. > Reprinted in "The C Programming language" by BWK & DMR, 1978.] Yet there have been many K&R-C compilers out there that don't follow that manual word by word. Can you say bugs? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 13:52 ` Alan Mackenzie 2004-11-21 14:29 ` Andries Brouwer @ 2004-11-21 15:50 ` Kai Grossjohann 2004-11-22 19:20 ` Kevin Rodgers 1 sibling, 1 reply; 88+ messages in thread From: Kai Grossjohann @ 2004-11-21 15:50 UTC (permalink / raw) Alan Mackenzie <acm@muc.de> writes: > On Sun, 21 Nov 2004, Andries Brouwer wrote: > >> require-final-newline is a beautiful variable. Set it to ask by default >> and some people will make it always true, some will make it always false. >> Many will leave it to ask. > > And some will want it t in C Mode and nil in Text Mode, and really don't > want to be bothered answering the question "Add one? (y or n)" twenty > times a day. Perhaps it would be useful if there was an easy way to set require-final-newline buffer-locally. That would work for other variables as well, and it would work for other modes. What do people think about a "mode specific variables" feature where users can customize that they want the variable foo to have the value bar in quux-mode? ... after 21.4. Kai ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:50 ` Kai Grossjohann @ 2004-11-22 19:20 ` Kevin Rodgers 2004-11-24 10:12 ` Kai Grossjohann 0 siblings, 1 reply; 88+ messages in thread From: Kevin Rodgers @ 2004-11-22 19:20 UTC (permalink / raw) Kai Grossjohann wrote: > Perhaps it would be useful if there was an easy way to set > require-final-newline buffer-locally. What is not easy about (add-hook 'c-mode-hook (lambda () (set (make-local-variable 'require-final-newline) nil))) > That would work for other variables as well, and it would work for > other modes. Indeed it does. > What do people think about a "mode specific variables" feature where > users can customize that they want the variable foo to have the value > bar in quux-mode? What do you think about Stefan's custom-based proposal (later in the thread) and my response? -- Kevin Rodgers ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 19:20 ` Kevin Rodgers @ 2004-11-24 10:12 ` Kai Grossjohann 0 siblings, 0 replies; 88+ messages in thread From: Kai Grossjohann @ 2004-11-24 10:12 UTC (permalink / raw) Kevin Rodgers <ihs_4664@yahoo.com> writes: > Kai Grossjohann wrote: >> Perhaps it would be useful if there was an easy way to set >> require-final-newline buffer-locally. > > What is not easy about > > (add-hook 'c-mode-hook > (lambda () > (set (make-local-variable 'require-final-newline) nil))) I neglected to say "using Customize" somewhere. >> What do people think about a "mode specific variables" feature where >> users can customize that they want the variable foo to have the value >> bar in quux-mode? > > What do you think about Stefan's custom-based proposal (later in the > thread) and my response? Both are implementations of what I want, but I haven't looked at things in sufficient detail to figure out which of the implementations is better. Kai ^ permalink raw reply [flat|nested] 88+ messages in thread
[parent not found: <01c4d002$Blat.v2.2.2$50b57dc0@zahav.net.il>]
* Re: cc-mode adds newlines [not found] ` <01c4d002$Blat.v2.2.2$50b57dc0@zahav.net.il> @ 2004-11-21 21:21 ` Andries Brouwer 2004-11-22 4:31 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 21:21 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 09:42:00PM +0200, Eli Zaretskii wrote: > > You see - nobody wants c-require-final-newline. > > Please stop pretending that you and Heinrich are ``everybody'', and > all the rest of the world are ``nobody''. > > Personally, I've set require-final-newline to t many years ago, and > never looked back since then. How's that for ``nobody''? Ha, welcome! A new participant in the discussion. But you see - according to your own words, you do not want c-require-final-newline. You are quite satisfied with require-final-newline. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:21 ` Andries Brouwer @ 2004-11-22 4:31 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2004-11-22 4:31 UTC (permalink / raw) Cc: bug-cc-mode, acm, emacs-devel > Date: Sun, 21 Nov 2004 22:21:58 +0100 > From: Andries Brouwer <Andries.Brouwer@cwi.nl> > Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>, acm@muc.de, bug-cc-mode@gnu.org, > > Personally, I've set require-final-newline to t many years ago, and > > never looked back since then. How's that for ``nobody''? > > Ha, welcome! A new participant in the discussion. > > But you see - according to your own words, you do not want > c-require-final-newline. You are quite satisfied with > require-final-newline. I want both. And, somewhere in this tiresome discussion you said that Emacs should not change files ``behind the user's back''. The above is meant to tell you that I obviously disagree. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:41 ` Alan Mackenzie 2004-11-21 12:26 ` Andries Brouwer @ 2004-11-22 0:12 ` Stefan Monnier 2004-11-22 14:07 ` Richard Stallman 2 siblings, 0 replies; 88+ messages in thread From: Stefan Monnier @ 2004-11-22 0:12 UTC (permalink / raw) Cc: bug-cc-mode, Andries Brouwer, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 11:41 ` Alan Mackenzie 2004-11-21 12:26 ` Andries Brouwer 2004-11-22 0:12 ` Stefan Monnier @ 2004-11-22 14:07 ` Richard Stallman 2004-11-22 15:52 ` Stefan Monnier 2 siblings, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-22 14:07 UTC (permalink / raw) Cc: bug-cc-mode, Andries.Brouwer, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 14:07 ` Richard Stallman @ 2004-11-22 15:52 ` Stefan Monnier 2004-11-22 19:16 ` Kevin Rodgers 2004-11-24 2:27 ` Richard Stallman 0 siblings, 2 replies; 88+ messages in thread From: Stefan Monnier @ 2004-11-22 15:52 UTC (permalink / raw) Cc: bug-cc-mode, Alan Mackenzie, Andries.Brouwer, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 15:52 ` Stefan Monnier @ 2004-11-22 19:16 ` Kevin Rodgers 2004-11-22 20:06 ` Stefan Monnier 2004-11-24 2:27 ` Richard Stallman 1 sibling, 1 reply; 88+ messages in thread From: Kevin Rodgers @ 2004-11-22 19:16 UTC (permalink / raw) Stefan Monnier wrote: >>I think we should add a variable require-final-newline-modes which >>would be a list of mode names. run-mode-hook could see if the current >>mode is in require-final-newline-modes, and if so, set >>require-final-newline to require-final-newline-mode-value. The >>default for require-final-newline-mode-value would be :ask, but if a >>user sets it to t, then all the appriate modes would set >>require-final-newline to t. > > > I think that would be silly. Tons of variable might want to be set > differently in different modes. Do we really want to add all the > corresponding foo-modes side-variables? > I think we'd be better off with a more generic solution. I agree, but I would like to see it implemented outside of customize. Custom would of course provide an interface to it, but wouldn't be the only way to specify a mode-specific value. For example, what if you just stored those values in each variable's property list? E.g. (put 'require-final-newline 'c-mode t) would be equivalent to (add-hook 'c-mode-hook (lambda () (set (make-local-variable 'require-final-newline) t)) > I.e. we should aim for a way to specify per-mode settings in custom. > That would be a lot more useful and wouldn't require adding any > new variable. > > Here is one way it could work: > > - instead of `:type foo' use `:type (per-mode foo)' where (per-mode foo) > stands for something like (repeat (cons mode foo)) where the list of modes > can be obtained doing > > (let ((modes nil) mode) > (mapatoms (lambda (s) > (if (and (string-match "-mode-hook\\'" (symbol-name s)) > (fboundp (intern (concat (setq mode (substring (symbol-name s) 0 (match-beginning 0))) "-mode")))) > (push mode modes)))) > modes) Minor improvement (eliminate concat): (when (and (string-match "\\(-mode\\)-hook\\'" (symbol-name s)) (fboundp (intern (setq mode (substring (symbol-name s) 0 (match-end 1)))))) (push mode modes)))) Why is it better to look for -mode-hook variables and derive the -mode function, than to just look for -mode functions? > - set custom-get and custom-set functions could look like: > > (defun custom-set-per-mode (var vals) > (put var 'custom-per-mode vals) > (dolist (setting vals) > (let ((mode (car setting)) > (value (cdr setting))) > (if (eq t mode) > (set-default var value) > (let ((fun (intern (concat "custom-set-" mode "-" (symbol-name var))))) > (unless (fboundp fun) > (fset fun > `(lambda () > (let ((val (assoc ',mode (get ',var 'custom-per-mode)))) > (if val (set (make-local-variable ',var) (cdr val))))))) > (add-hook (intern (concat mode "-mode-hook")) fun)))))) > > (defun custom-get-per-mode (var) > (let* ((val (get var 'custom-per-mode)) > (defval (assq t val))) > (unless (eq (cdr defval) (default-value var)) > ;; It was changed somehow... > (setcdr defval (default-value var))) > val)) Ah, we're talking about almost exactly the same thing. You've collected all the mode-specific values into an association list keyed by the mode symbol, and put that on the variable's custom-per-mode property; whereas I put each value on a separate property. But the main difference is that I imagined the mode-specific value being set by normal-mode instead of the mode's hook (which would be preserved as a user option, not a system variable). > Ideally we should even provide such per-mode settings for *all* custom > variables, without having to change the `defcustom'. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 19:16 ` Kevin Rodgers @ 2004-11-22 20:06 ` Stefan Monnier 0 siblings, 0 replies; 88+ messages in thread From: Stefan Monnier @ 2004-11-22 20:06 UTC (permalink / raw) Cc: emacs-devel > I agree, but I would like to see it implemented outside of customize. > Custom would of course provide an interface to it, but wouldn't be the > only way to specify a mode-specific value. I think `add-hook' is perfectly fine for non-custom uses. People have used it for years without any problems. > (put 'require-final-newline 'c-mode t) > would be equivalent to > (add-hook 'c-mode-hook > (lambda () > (set (make-local-variable 'require-final-newline) t)) I recommend (defun my-c-mode-hook () (set (make-local-variable 'require-final-newline) t)) (add-hook 'c-mode-hook 'my-c-mode-hook) It's better behaved when you reload your .emacs. If you think the above is too scary, we can provide functions/macros to make it less so. E.g. a macro `setq-local'. > Ah, we're talking about almost exactly the same thing. You've collected > all the mode-specific values into an association list keyed by the mode > symbol, and put that on the variable's custom-per-mode property; whereas > I put each value on a separate property. I actually dislike this property in my sample code because it duplicate some info. A better way would be to hard-code the result of `assq' inthe definition of the functions we put on the hooks, and then in custom-get-per-mode we'd rebuild the alist by looking at the hooks and extracting the value from the body of the function. But that's pretty ugly. The reason for doing that would be that if a user does (remove-hook 'foo-mode-hook 'custom-set-foo-some-var) it should properly update the corresponding value returned by custom-get-per-mode. Stefan ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-22 15:52 ` Stefan Monnier 2004-11-22 19:16 ` Kevin Rodgers @ 2004-11-24 2:27 ` Richard Stallman 2004-11-24 4:27 ` Stefan Monnier 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-24 2:27 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-24 2:27 ` Richard Stallman @ 2004-11-24 4:27 ` Stefan Monnier 2004-11-28 14:45 ` Martin Stjernholm 0 siblings, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2004-11-24 4:27 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, emacs-devel > I think that would be silly. Tons of variable might want to be set > differently in different modes. Do we really want to add all the > corresponding foo-modes side-variables? > This is an example of taking something to an extreme and then > criticizing the extreme. This particular variable seems to be a special > issue. I'm not proposing this for all variables, only for this one. Looking at my own .emacs, I see that I never set require-final-newline in a mode-dependent way. After all, the final-newline is an extremely minor detail, so setting the global value of require-final-newline is already a lot of effort compared to the potential benefit. On the other hand, there are several other variables that I set differently depending on the major mode. Now I'm not the canonical user, but I still think it's a good indication that if we add require-final-newline-in-modes, we should also add many other similar variables for fill-column, fill-prefix, comment-start, comment-auto-fill-only-in-comments, comment-end, left-margin, tab-width, indent-tabs-mode, font-lock-keyword-face, font-lock-function-name-face, fill-indent-according-to-mode, c-basic-offset, ... > However, we could also just add a single new variable > require-final-newline-in-modes which says what to do in certain > modes that ask for it. The modes that now bind require-final-newline > to t would bind it to require-final-newline-in-modes instead. I can't believe we're spending so much time on a miserable final newline which is very rarely missing and even more rarely a source of problem. > If we do this, I think we should do this in a way that doesn't require > a special custom type, so that it would work for any variable. Agreed, Stefan ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-24 4:27 ` Stefan Monnier @ 2004-11-28 14:45 ` Martin Stjernholm 2004-11-29 6:11 ` Richard Stallman 0 siblings, 1 reply; 88+ messages in thread From: Martin Stjernholm @ 2004-11-28 14:45 UTC (permalink / raw) Cc: bug-cc-mode, acm, Andries.Brouwer, rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-28 14:45 ` Martin Stjernholm @ 2004-11-29 6:11 ` Richard Stallman 2004-11-30 10:51 ` Martin Stjernholm 0 siblings, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-29 6:11 UTC (permalink / raw) Cc: monnier, bug-cc-mode, acm, Andries.Brouwer, emacs-devel There are great many dialects of these languages, so CC Mode uses the current language standards as the authorative sources to determine its settings. The standard is very useful as a guide to what to do, but don't let the word "authoritative" suggest that it is some kind of authority that we must follow. It is not. CC mode should take full account of what standards say, but that does not mean trying to "comply" with them. For the languages where the standards mandate a trailing newline, CC Mode therefore sets require-final-newline to t by default, This is not the right basis for making the decision. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-29 6:11 ` Richard Stallman @ 2004-11-30 10:51 ` Martin Stjernholm 2004-12-01 2:56 ` Richard Stallman 0 siblings, 1 reply; 88+ messages in thread From: Martin Stjernholm @ 2004-11-30 10:51 UTC (permalink / raw) Cc: bug-cc-mode, monnier, acm, Andries.Brouwer, emacs-devel Richard Stallman <rms@gnu.org> wrote: > For the languages where the standards mandate a trailing newline, CC > Mode therefore sets require-final-newline to t by default, > > This is not the right basis for making the decision. I believe it is, indirectly: The default settings should be suitable for the most common editing situations. It's reasonable to assume that a commonly accepted standard (which is the case with ANSI C) describe the common ground between implementations. Hence the standard is a very good source when finding out what the most common editing situations are. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-30 10:51 ` Martin Stjernholm @ 2004-12-01 2:56 ` Richard Stallman 0 siblings, 0 replies; 88+ messages in thread From: Richard Stallman @ 2004-12-01 2:56 UTC (permalink / raw) Cc: bug-cc-mode, monnier, acm, Andries.Brouwer, emacs-devel I believe it is, indirectly: The default settings should be suitable for the most common editing situations. It's reasonable to assume that a commonly accepted standard (which is the case with ANSI C) describe the common ground between implementations. Hence the standard is a very good source when finding out what the most common editing situations are. It tells us what some of the common editing situations are, yes. So it is useful to look at the standard for many purposes, including this one. However, being a useful source of suggestions and insight is quite different from laying down the law. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 2:08 ` Andries Brouwer ` (2 preceding siblings ...) 2004-11-21 11:41 ` Alan Mackenzie @ 2004-11-21 14:47 ` Andreas Schwab 2004-11-21 15:03 ` Andries Brouwer 3 siblings, 1 reply; 88+ messages in thread From: Andreas Schwab @ 2004-11-21 14:47 UTC (permalink / raw) Cc: Alan Mackenzie, Jari Aalto, emacs-devel Andries Brouwer <Andries.Brouwer@cwi.nl> writes: > That is a phantasy argument. Not at all. > Old compilers just accept the C source without final newline > without any complaint. Some newer pedantic ones print a warning. [...] > I have been using C for thirty years or so. If you've really been using C for thirty years then you should have known that C source files without final newline are a _real_ problem. See <http://groups.google.com/groups?hl=de&lr=&selm=304%40mtuni.ATT.COM> for an example. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 14:47 ` Andreas Schwab @ 2004-11-21 15:03 ` Andries Brouwer 0 siblings, 0 replies; 88+ messages in thread From: Andries Brouwer @ 2004-11-21 15:03 UTC (permalink / raw) Cc: Jari Aalto, Alan Mackenzie, Andries Brouwer, emacs-devel On Sun, Nov 21, 2004 at 03:47:54PM +0100, Andreas Schwab wrote: > > Old compilers just accept the C source without final newline > > without any complaint. Some newer pedantic ones print a warning. > > If you've really been using C for thirty years then you should have known > that C source files without final newline are a _real_ problem. > > See <http://groups.google.com/groups?hl=de&lr=&selm=304%40mtuni.ATT.COM> > for an example. Hi Andreas - Thanks - you are always good for solid facts. So, yes, there exists, or has existed, a compiler or compilation setup where an error was returned for a missing final newline. (1988 "Gnu on 386 running UNIX" is not very specific.) That makes it extra clear why it is very useful to have the warning provided by setting require-final-newline to ask. Andries ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-20 15:14 ` Alan Mackenzie 2004-11-21 2:08 ` Andries Brouwer @ 2004-11-21 15:39 ` Richard Stallman 2004-11-21 21:47 ` Alan Mackenzie 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-21 15:39 UTC (permalink / raw) Cc: jari.aalto, Andries.Brouwer, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 15:39 ` Richard Stallman @ 2004-11-21 21:47 ` Alan Mackenzie 2004-11-23 16:30 ` Richard Stallman 2004-11-25 2:21 ` Richard Stallman 0 siblings, 2 replies; 88+ messages in thread From: Alan Mackenzie @ 2004-11-21 21:47 UTC (permalink / raw) Cc: emacs-devel Hi! On Sun, 21 Nov 2004, Richard Stallman wrote: > An equally valid argument is that of the programmer who hacks through the > night and sets off a build (which takes several hours to complete), goes > home for some sleep, then comes back into the office the following > afternoon. He then finds that the build failed for lack of a final > newline in one of the files. Then he expostulates "FAQ! Why couldn't > that stupid editor have put that stupid newline in for me?". >He should use GCC--then this will never happen. <OFF TOPIC> Actually, in my (paid) work, our project got hit recently by a GCC newlines problem: A string which was sent as a command from one box along a comms channel to another box had an embedded newline in it. This was fine and worked. That is, it worked until a mix up with our proprietory version control system, so that one day we got the source code with "proprietory" line terminators. It compiled without errors or warnings. The command string with the proprietory EOL _didn't_ work. It didn't cause an error message either, since it was still valid syntax (yes, that's a design bug on our part.) It took us ~40 hours of work to track it down. :-( Accepting such strings is a violation of the C++ standard, I think. I'll need to complain about this to GCC. Possibly, I'll not be the first. <\OFF TOPIC> >It would be useful to warn about missing final newlines in C, but Emacs >should not by default add them blindly. It's good to get such firm guidance. Thanks. I'll forward this to Martin (assuming he hasn't got the message some other way), and maybe we can bring out a CC Mode 5.30.10 with this in it "quite soon". -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:47 ` Alan Mackenzie @ 2004-11-23 16:30 ` Richard Stallman 2004-11-25 2:21 ` Richard Stallman 1 sibling, 0 replies; 88+ messages in thread From: Richard Stallman @ 2004-11-23 16:30 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-21 21:47 ` Alan Mackenzie 2004-11-23 16:30 ` Richard Stallman @ 2004-11-25 2:21 ` Richard Stallman 2004-11-25 20:35 ` Alan Mackenzie 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2004-11-25 2:21 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: cc-mode adds newlines 2004-11-25 2:21 ` Richard Stallman @ 2004-11-25 20:35 ` Alan Mackenzie 0 siblings, 0 replies; 88+ messages in thread From: Alan Mackenzie @ 2004-11-25 20:35 UTC (permalink / raw) Cc: emacs-devel Hi, Richard, Hi, Emacs developers, Hi, gcc maintainers! On Wed, 24 Nov 2004, Richard Stallman wrote: [Subject: gcc's acceptance of string constants which straddle lines.] > Accepting such strings is a violation of the C++ standard, I think. I'll > need to complain about this to GCC. Possibly, I'll not be the first. >We do not "violate" the C++ standard, we diverge from it. We do not >regard standards as authorities. We make our own decisions. OK. That's fine by me, but ..... The situation which bit me was this: In our embedded system, commands get sent from device to device as strings of ASCII, a fairly normal thing. One particular command string was, in essence, coded thus: const char *command = "aaaa bbbb" ; which normally compiles to "aaaa<LF> bbbb". The receiving device ignores the white space. However, due to a mixup with proprietory version control systems and editors, this source file somehow got to the build process with "proprietory" line terminators. gcc compiled the file without complaint (on QNX, a proprietory Posix system), but the command string ended up as "aaaa<CR><LF> bbbb". To the receiving device, the <CR> meant something like "do not process the rest of this command". To track the resulting bug down took about 40 hours of work, all told. This is, I think, the reason why the C and C++ standards don't allow strings to straddle lines: the meaning of a source file can change with the EOL convention. Now, I like proprietory file formats almost as little as you do, and over the decades, in projects like ours, they must have wasted untold billions of dollars, pounds, Marks, Yen, Francs, ...., not to mention trillions of Lira and Pesetas ;-). It would have been nice to have got at least a warning message here. Of course, the Right Thing is for me to put the appropriate option (perhaps -traditional-cpp?) into the build scripts. The solution I actually adopted was to purge all such strings from the source files (all ~2200 of them - it's a very slackly written program :-( It took me ~half a day to write a regular expression to find them). However, those 40 hours of work are lost forever :-(. But I _do_ understand the need for having strings straddling lines, too. It's would be a pain in the donkey to have to end every line of, for example, the doc string in a DEFUN macro with ....\n", and things like that. And I _do_ understand that it's desirable, sometimes, to compile those strings with the target OS's EOL convention. >Complain if you wish, but I will not agree to the absurd limitation of >string constants to a single line. By "complain", I meant simply to draw my experiences to the attention of the gcc maintainers, and ask them to consider, perhaps, whether the gcc options (or their defaults) might be modified in some way so as to help other projects avoid falling into the same trap as mine did, whilst at the same time not inconveniencing those who positively need such strings. I was not proposing throwing some sort of temper fit. I think you know me better than that by now. ;-) So, gcc people: is there a way? Thanks in advance! -- Alan Mackenzie (Munich, Germany) ^ permalink raw reply [flat|nested] 88+ messages in thread
end of thread, other threads:[~2005-01-02 18:02 UTC | newest] Thread overview: 88+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-11-28 16:56 cc-mode adds newlines Andries.Brouwer [not found] ` <Andries.Brouwer@cwi.nl> 2004-11-28 17:17 ` Martin Stjernholm 2004-11-28 20:20 ` Andries Brouwer 2004-11-29 0:14 ` Kim F. Storm 2004-11-30 7:01 ` Richard Stallman 2004-12-31 15:26 ` Richard Stallman 2004-12-31 16:56 ` Andries Brouwer 2005-01-02 16:05 ` Richard Stallman 2005-01-02 18:02 ` Andries Brouwer 2004-11-30 7:01 ` Richard Stallman 2004-11-30 8:11 ` David Kastrup 2004-12-01 2:56 ` Richard Stallman [not found] <mailman.3671.1100818498.8225.bug-gnu-emacs@gnu.org> 2004-11-18 23:31 ` Jari Aalto 2004-11-19 20:27 ` Alan Mackenzie 2004-11-19 23:13 ` Andries Brouwer 2004-11-20 0:13 ` Miles Bader 2004-11-20 15:14 ` Alan Mackenzie 2004-11-21 2:08 ` Andries Brouwer 2004-11-21 10:00 ` Miles Bader 2004-11-21 11:38 ` Andries Brouwer 2004-11-21 12:08 ` Alfred M. Szmidt 2004-11-21 12:45 ` Andries Brouwer 2004-11-21 12:58 ` Alfred M. Szmidt 2004-11-21 13:03 ` Andries Brouwer 2004-11-21 13:09 ` Alfred M. Szmidt 2004-11-22 0:03 ` Stefan Monnier 2004-11-21 12:53 ` Miles Bader 2004-11-21 13:00 ` Andries Brouwer 2004-11-21 13:14 ` David Kastrup 2004-11-21 13:35 ` Andries Brouwer 2004-11-21 13:41 ` David Kastrup 2004-11-21 13:54 ` Andries Brouwer 2004-11-21 15:54 ` Thien-Thi Nguyen 2004-11-21 11:06 ` David Kastrup 2004-11-21 11:45 ` Andries Brouwer 2004-11-21 12:08 ` David Kastrup 2004-11-21 11:41 ` Alan Mackenzie 2004-11-21 12:26 ` Andries Brouwer 2004-11-21 12:34 ` David Kastrup 2004-11-21 12:49 ` Andries Brouwer 2004-11-21 13:08 ` David Kastrup 2004-11-21 13:28 ` Andries Brouwer 2004-11-21 13:37 ` David Kastrup 2004-11-21 13:43 ` Andries Brouwer 2004-11-21 13:51 ` David Kastrup 2004-11-21 14:03 ` Andries Brouwer 2004-11-21 15:01 ` David Kastrup 2004-11-21 15:08 ` Andries Brouwer 2004-11-22 19:21 ` Kevin Rodgers 2004-11-21 15:18 ` Andreas Schwab 2004-11-21 15:36 ` Andries Brouwer [not found] ` <01c4d003$Blat.v2.2.2$3d9a05c0@zahav.net.il> 2004-11-21 21:28 ` Andries Brouwer 2004-11-22 4:35 ` Eli Zaretskii 2004-11-22 9:04 ` David Kastrup 2004-11-21 13:52 ` Alan Mackenzie 2004-11-21 14:29 ` Andries Brouwer 2004-11-21 15:07 ` David Kastrup 2004-11-21 15:20 ` Andries Brouwer 2004-11-21 19:03 ` Alfred M. Szmidt 2004-11-21 21:19 ` Andries Brouwer 2004-11-21 21:46 ` Alfred M. Szmidt 2004-11-21 22:19 ` Andries Brouwer 2004-11-22 11:54 ` Benjamin Riefenstahl 2004-11-22 15:54 ` Andries Brouwer 2004-11-22 16:56 ` Andreas Schwab 2004-11-21 15:50 ` Kai Grossjohann 2004-11-22 19:20 ` Kevin Rodgers 2004-11-24 10:12 ` Kai Grossjohann [not found] ` <01c4d002$Blat.v2.2.2$50b57dc0@zahav.net.il> 2004-11-21 21:21 ` Andries Brouwer 2004-11-22 4:31 ` Eli Zaretskii 2004-11-22 0:12 ` Stefan Monnier 2004-11-22 14:07 ` Richard Stallman 2004-11-22 15:52 ` Stefan Monnier 2004-11-22 19:16 ` Kevin Rodgers 2004-11-22 20:06 ` Stefan Monnier 2004-11-24 2:27 ` Richard Stallman 2004-11-24 4:27 ` Stefan Monnier 2004-11-28 14:45 ` Martin Stjernholm 2004-11-29 6:11 ` Richard Stallman 2004-11-30 10:51 ` Martin Stjernholm 2004-12-01 2:56 ` Richard Stallman 2004-11-21 14:47 ` Andreas Schwab 2004-11-21 15:03 ` Andries Brouwer 2004-11-21 15:39 ` Richard Stallman 2004-11-21 21:47 ` Alan Mackenzie 2004-11-23 16:30 ` Richard Stallman 2004-11-25 2:21 ` Richard Stallman 2004-11-25 20:35 ` Alan Mackenzie
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).