From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andries Brouwer Newsgroups: gmane.emacs.devel Subject: Re: cc-mode adds newlines Date: Sun, 21 Nov 2004 03:08:52 +0100 Message-ID: <20041121020850.GA20436@apps.cwi.nl> References: <20041119231343.GA19603@apps.cwi.nl> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1101002968 2346 80.91.229.6 (21 Nov 2004 02:09:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 21 Nov 2004 02:09:28 +0000 (UTC) Cc: Andries Brouwer , emacs-devel@gnu.org, Jari Aalto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 21 03:09:13 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CVhA8-00045w-00 for ; Sun, 21 Nov 2004 03:09:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CVhJ7-00022R-1Z for ged-emacs-devel@m.gmane.org; Sat, 20 Nov 2004 21:18:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CVhIz-00022L-2X for emacs-devel@gnu.org; Sat, 20 Nov 2004 21:18:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CVhIy-000229-Ke for emacs-devel@gnu.org; Sat, 20 Nov 2004 21:18:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CVhIy-000226-Gx for emacs-devel@gnu.org; Sat, 20 Nov 2004 21:18:20 -0500 Original-Received: from [192.16.191.8] (helo=hera.cwi.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CVh9t-0001Dm-Dc for emacs-devel@gnu.org; Sat, 20 Nov 2004 21:08:57 -0500 Original-Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id iAL28tOX001594 for ; Sun, 21 Nov 2004 03:08:55 +0100 (MET) Original-Received: (from aeb@localhost) by apps.cwi.nl (8.11.7p1+Sun/8.12.2) id iAL28qN09699; Sun, 21 Nov 2004 03:08:52 +0100 (MET) Original-To: Alan Mackenzie Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30136 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30136 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