Re: HELP, PLEASE! Syntax problem!

[Alan Mackenzie]

Hi, Stefan!

On Wed, Nov 25, 2009 at 09:43:01AM -0500, Stefan Monnier wrote:
> > In the following fragment of code:

> > 1   int a = foo (
> > 2       1);
> > 3   #define X(A, B)                                 \
> > 4       do {                                        \
> > 5           printf (A, B);                          \
> > 6       } while (0)

> > 7   int a = foo (
> > 8       1);

> > , there is a C macro between lines 3 and 6.  The syntax-table
> > properties here have been manipulated (see below).  Putting point at
> > the "(" in L5 and doing C-M-n takes point to after ")" ON LINE 8.
> > Similar things happen with C-M-p, C-M-u from various places inside
> > the macro

> > Evidently, all syntactic properties inside the macro have been
> > suppressed.  This is not wanted.

> The first problem is most likely that `syntax-table' is only special for
> text-properties, not for char-properties in general (i.e. when placed
> on an overlay, it has no effect).

Ah.  OK, that's a shame, but life is like that sometimes.  I'd assumed
that the special properties in text properties would be the same as in
overlays (modulo any which are specific to the mechanism).

> Of course, the real problem is that the syntax-table hacking you're
> doing here is just that: a hack.

We're hackers.  ;-)

> Maybe another hack would have fewer shortcomings?  E.g. maybe you
> could place a syntax-table property on the # that says "beginning of
> comment" and a matching "end of comment" on the newline that
> terminates line 6?

Wow!  That's one of these "why didn't I think of that?" ideas.  It's
much simpler and more effective than individually marking each
paren/brace/bracket.  But the thing to do is to set a category property
value 'c-cpp-delimiter at the boundaries of each macro.  All that I have
to do now is to give that symbol the syntax-table property value
"generic comment delimiter", and all these pesky parens vanish just like
that, like switching a (n old fashioned tungsten) light bulb off.  ;-)

> Then again, our syntax-tables are too limited in their comment
> handling, so given that CC already uses most forms of comments, it'll
> be difficult to make sure that # only matches that particular comment
> ender and not just "any \n" or "*/", but maybe just marking the "\\\n"
> that get in the way as "punctuation" would solve it?

One or two little things to sort out, and c-parse-state will run like
greased lightning, like "this of a spade" (or something like that).  To
appreciate why I'm doing this, download
<http://www.muc.de/~acm/AT91SAM9263_inc.h> and try scrolling around near
EOB.  :-(  My fix to this problem speeds up scrolling speed by an order
of magnitude in such ill-conditioned files.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).