From xemacs-m  Wed Dec 25 05:08:50 1996
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id FAA25464 for <xemacs-beta@xemacs.org>; Wed, 25 Dec 1996 05:08:50 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA11372; Wed, 25 Dec 1996 03:08:21 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id DAA28402; Wed, 25 Dec 1996 03:08:19 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id DAA16505; Wed, 25 Dec 1996 03:08:17 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id DAA28666; Wed, 25 Dec 1996 03:08:15 -0800
Date: Wed, 25 Dec 1996 03:08:15 -0800
Message-Id: <199612251108.DAA28666@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Neal Becker <neal@ctd.comsat.com>,
        "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>,
        Torbjorn Norbye <tor@Eng.Sun.COM>
Subject: Re: Should // comments be recognized in C mode?
In-Reply-To: <u9wwue1xr6.fsf@chekov.ctd.comsat.com>
References: <199612190628.WAA06077@xemacs.eng.sun.com>
	<u9wwue1xr6.fsf@chekov.ctd.comsat.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.97)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Neal" == Neal Becker <neal@ctd.comsat.com> writes:

Neal> Of course, you can call your header '.H' and that will also
Neal> prevent problems.

Most professional programmers don't have any control over the
extensions used for their source files.  My last 2 C++ projects used
`.h' as the header file extension.

>>>>> "BAW" == Barry A Warsaw <bwarsaw@CNRI.Reston.VA.US> writes:

>>>>> "MB" == Martin Buchholz <mrb@Eng.Sun.COM> writes:

MB> Folks at Sun were complaining that `//' comments in their C++
MB> header files (.h) were not being recognized as comment
MB> delimiters.

BAW> If these header files really contained C++ code and not C code, then
BAW> you need to find a way to make sure that those files are edited in
BAW> c++-mode and not c-mode.  The fact that .h is used as a suffix for
BAW> both C and C++ means that you need something more intelligent (or
BAW> expressive) than auto-mode-alist to make that determination.  I agree
BAW> that Emacs cruft in the file (first-line or local-var section) is
BAW> disgusting.

Hmmmmm.  Here's an idea: make the presence of // comments a hint to
use C++ mode automagically?

MB> Rather than change auto-mode-alist to set the mode of .h files
MB> to C++, I discovered after some digging that

MB> (c-enable-//-in-c-mode)

MB> does what I want.  Why don't we make this the default?

MB> Some users will lose because of code like this: double x =
MB> 1//*divide*/2; but they deserve to lose.

MB> I checked gcc, and it accepts `//' comments in C code unless
MB> the -ansi flag is set.

BAW> Exactly.  // isn't a comment in ANSI C and I don't want to encourage
BAW> sneaking these C++'isms into C code.  I recognize the utility of it so
BAW> I'm not prohibiting it obviously; and it's easy enough to call
BAW> c-enable-//-in-c-mode in your mode hook.  Note that this causes a
BAW> *global* c-mode change BTW, which cannot be made buffer local --
BAW> another reason not to like making this the default.

Barry, I'd like you to reconsider this point.  If the user erroneously
puts // iin their code, and then tries to use a C compiler that does
not accept it (and a vanishing breed of C compilers it is), they will
see quickly enough that their code is non-portable and it will be
trivial to change via, e.g., sed script.  In any case, they will not
have code that changes behavior silently in the transition to another
compiler (this line of argument borrowed from Stroustrup).  Using
another compiler is always a port, and the comments style is the least
of the portability problems to address.

In general, Emacs should be optimized to accept and work with whatever
the user has, and not to preach the `proper way'.

Martin

