[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Semantic parser uses c-forward-conditional

From: Alan Mackenzie
Subject: Re: Semantic parser uses c-forward-conditional
Date: Tue, 22 Sep 2009 22:08:52 +0000
User-agent: Mutt/1.5.9i

Hi, Eric,

On Tue, Sep 22, 2009 at 07:43:47AM -0400, Eric M. Ludlam wrote:
> On Tue, 2009-09-22 at 10:57 +0000, Alan Mackenzie wrote:

> > I'm not very keen on that, but how about this instead: a new defun
> > c-forward-conditional-1 which does the same, except it doesn't push a
> > mark, doesn't throw errors like "No following conditional at this
> > level", and returns the final point, or nil?

> > Then all occurances inside CEDET can be changed to
> > (cedet-forward-c-conditional), where the following macro goes into
> > CEDET:

> >     (require 'cc-cmds)
> >     (defmacro forward-cedet-c-conditional (count &optional target-depth 
> > with-else)
> >        ....
> >       (if (fboundp 'c-forward-conditional-1) ...)
> >       ....
> >     )

> > This will avoid complexifying cc-cmds.el, whilst still allowing CEDET
> > and friends to work with older CC MODE versions.  It would also be good
> > for CC MODE to separate out the "engine" part of the command from the
> > "wrapper".

> The above seems like a fine solution to me.

I've had a closer look at it, and it seems it would be better to let
c-forward-conditional just signal errors (which it does when there aren't
enough conditional to go over/out of/into).  c-f-c (which is patterned on
scan-lists) also does all the work for c-backward-conditional etc., so
returning some sort of error status would mean having to throw
identically in the other five defuns.  Callers can catch the error if
they need to, just as they do at the moment.

I'll just take out the setting of the mark.

> > As a matter of interest, have you grepped CEDET to find other similar
> > problems?

> All the C support for the parser is in one.  It also uses c-end-of-macro
> which stands out for me.

Thanks!  c-end-of-macro isn't a problem, it just goes forward past
escaped EOLs.

> Eric

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]