Re: cc-mode adds newlines

    > Note that GCC accepts this too, as an extension.

    No more.

They were not supposed to do this!

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

Re: cc-mode adds newlines

    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/

nomenclature minor mode

c-forward-into-nomenclature and c-backward-into-nomenclature are
very useful. I'm surprised that there is no standard keybind for
them and no minor mode for them in cc-mode.

I write the minor mode for thme with enhancements.

The enhancements are following.
1. handling a sequence of upcase chars as a word. e.g.
   GType => G Type
   NSGraphicsContext => NS Graphics Context
   GNUStep => GNU Step

2. adding more nomenclature functions
   `c-capitalize-word', `c-downcase-word', `c-upcase-word',
   `c-kill-word', `c-backward-kill-word', `c-transpose-words',
   `c-mark-word', `c-ispell-word', `c-ispell-complete-word'

3. making C-w in isearch nomenclature'ive

Enjoy,

Masatake YAMATO

  

;;; cc-word.el --- Moving point next/previous to capitalized sub-word in a word
;;
;; Copyright (C) 2004 Masatake YAMATO
;;

Re: awk-mode not defined in current CVS Emacs

Alan Mackenzie wrote:

> Here is a patch which should fix the problem. Could you check that
> the patch is OK and confirm (or refute) this on bug-cc-mode <at> gnu.org.

Yes, this fixes it. Thanks.

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

[gmorris+emacs <at> ast.cam.ac.uk: awk-mode not defined in current CVS Emacs]

I sent you this message two weeks ago but did not get a response.
Someone else sent a fix, which I have now installed, so this problem
is now resolved.  But how come you didn't respond?

======================================================================
Would you please fix this and ack?

------- Start of forwarded message -------
To: emacs-pretest-bug <at> gnu.org
From: Glenn Morris <gmorris+emacs <at> ast.cam.ac.uk>
X-Spook: hack suicide bombing gold bullion Aum Supreme Truth
X-Ran: pbYI~b7ZD14FXWh8t87j.,#`y0z`9Fq*)KS).icRzwwTPakEx$1(/4g*Ccj[*]e3*9<8$~
X-Hue: medium spring green
Mail-Followup-To: emacs-pretest-bug <at> gnu.org, bug-cc-mode <at> gnu.org
Date: Wed, 17 Nov 2004 18:03:22 +0000
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Cc: bug-cc-mode <at> gnu.org
Subject: awk-mode not defined in current CVS Emacs
Sender: emacs-pretest-bug-bounces+rms=gnu.org <at> gnu.org
X-Spam-Status: No, hits=0.5 required=5.0
	tests=RCVD_IN_ORBS,USER_AGENT
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

With the current CVS GNU Emacs, started as `emacs -q --no-site-file',
the function `awk-mode' is not defined, until one explicitly does
(require 'cc-mode).

Re: catastrophic failure under MMM

Joe Kelsey <joe <at> zircon.seattle.wa.us> wrote:

> Currently, mmm-mode does not do nested subregions.  There has been some
> effort to make it do such things, but no real major work.

Ok. I'll consider that an issue in the current implementation. An API
for interaction with the major modes should handle arbitrary nesting,
so that the implementation can be fixed in the future.

> You set up a particular default major-mode for each buffer, depending on
> the various modes. /.../

Yes, you've told me already. All I can say about that is that it'd be
good if the API doesn't require the major mode to know whether it's on
the top level or nested. The major mode just needs to know the buffer
region it should act on; it's just a special case if that region is
from (point-min) to (point-max).

> noweb programming works to string together named regions into specific
> output pieces.  You can choose to output the pieces into one or more
> files.  I commonly put .h and .cc files into a single noweb file to
> document everything in one place.  The other common literate programming
> trick involves breaking up a single function with interspersed latex
> documentation.  In this case, the separate overlays appear on a named
> list.

Sorry but I still can't see from this noweb example what those related
overlays entails for the major mode. I'm interested in general terms
here, i.e. to map the complexities that the major mode writer has to
be involved with.

Re: nomenclature minor mode

Masatake YAMATO <jet <at> gyve.org> wrote:

> c-forward-into-nomenclature and c-backward-into-nomenclature are
> very useful. I'm surprised that there is no standard keybind for
> them

That's because there are no free bindings that are convenient enough.
For functions like those, I think it's necessary that the bindings
require no more than two keypresses, e.g. a modifier and some other
key. Anything more complicated gets too clumsy.

> and no minor mode for them in cc-mode.

Now that's a very good idea I haven't thought of. ;)

> I write the minor mode for thme with enhancements.

Thanks, this is nice stuff. I'd like to include it. Only one thing is
required first, and that is that you sign copyright assignment or
disclaimer papers with the FSF. Are you prepared to do that, or do you
have an applicable agreement already?

Some other small stuff I noted are below. Consider them enhancement
suggestions.

o  You use "word" instead of "nomenclature" in function names etc. I
   guess you think the latter is too long and clumsy. However, "word"
   already has a different meaning in Emacs lingo, so it's a bit
   confusing to reuse it this way. Coming up with a good alternative
   isn't easy, though.

Re: catastrophic failure under MMM

Martin Stjernholm <mast <at> lysator.liu.se> writes:

>> The overlay contains its own limits, by definition. /.../
>
> I know, but from the looks of it those limits can include some padding
> stuff that doesn't follow the syntax of the submode. In MMM terms,
> they give the "front start" and "back end" of the region, which
> includes the "front" and "back delimiters". In the major mode I don't
> want to see those delimiters, i.e. I want the "front end" and "back
> start" positions. Or have I misunderstood the meaning of "delimiters"
> here?

It depends on the nature of the delimiters...  I'm not familiar with
noweb syntax, but consider Javascript embedded in HTML: the delimiters
are "<script>" and "</script>".  Clearly these should be treated as
HTML, not Javascript.  Contrariwise, in the mode I'm trying to write
(for GCC machine descriptions) the delimiters are "^{" and "^}", and
*should* be treated as C, or at least that makes the most sense to me.

MMM handles this with the :include-front and :include-back tags on its
classes.  If they are true, the delimiters are included in the region;
if they are false, they aren't.  I'd think that you could rely on the
class author to set these correctly, and assume that the overlay
limits were sane.

> However, it's unfortunately not a feasible way to find out the
> subregions that CC Mode should ignore. It must be possible to match
> them inside a generic regexp. I can adapt all searches inside CC Mode
> to heed whitespace syntax, as well as the generic string and comment
> delimiter syntaxes. I'd prefer the latter, though.

Re: catastrophic failure under MMM

Zack Weinberg <zack <at> codesourcery.com> wrote:

> /.../ consider Javascript embedded in HTML: the delimiters are
> "<script>" and "</script>". Clearly these should be treated as HTML,
> not Javascript. Contrariwise, in the mode I'm trying to write (for
> GCC machine descriptions) the delimiters are "^{" and "^}", and
> *should* be treated as C, or at least that makes the most sense to
> me.

I guess a third possibility could be that the delimiters - or some
part of them - has a syntax that neither the outer nor the inner mode
understands, and that thus should be handled by neither of them.

> MMM handles this with the :include-front and :include-back tags on its
> classes.  If they are true, the delimiters are included in the region;
> if they are false, they aren't.  I'd think that you could rely on the
> class author to set these correctly, and assume that the overlay
> limits were sane.

As long as all this complexity is contained within MMM Mode so I just
have to call some functions that return the beginning and the end of
the region that really contains C code, I'm happy.

> Um, why is it not feasible to limit searches to the overlay bounds? If
> nothing else, wouldn't it work to wrap all searches in (save-excursion
> (narrow-to-region (overlay-start ...) (overlay-end ...))  ...)  [I may
> be misremembering the function names, but you get the idea.]

That's a different issue. I'm talking about the _sub_regions that CC
Mode should ignore here. It's important to have this distinction

Re: catastrophic failure under MMM

Martin Stjernholm <mast <at> lysator.liu.se> writes:
...
> I guess a third possibility could be that the delimiters - or some
> part of them - has a syntax that neither the outer nor the inner mode
> understands, and that thus should be handled by neither of them.

Yes, IIRC this is a new feature in the most recent version of MMM.

>> MMM handles this with the :include-front and :include-back tags on its
>> classes.  If they are true, the delimiters are included in the region;
>> if they are false, they aren't.  I'd think that you could rely on the
>> class author to set these correctly, and assume that the overlay
>> limits were sane.
>
> As long as all this complexity is contained within MMM Mode so I just
> have to call some functions that return the beginning and the end of
> the region that really contains C code, I'm happy.

Right, what I was saying is I'm pretty sure the overlay limits will be
accurate.

...
> o  There's one region that the major mode should work within. I'd like
>    to be able to call some functions that return the start and end of
>    that region.
>
> o  Inside the region mentioned above, there might be any number of
>    regions that should be handled by other modes and that CC Mode
>    should ignore. Those regions must be treated properly by the many
>    syntax handling routines in Emacs that do the low level work: It