Semantic parser uses c-forward-conditional

Semantic parser uses c-forward-conditional

[Chong Yidong]

Hi Alan,

Semantic's C parser calls c-forward-conditional while it's parsing C
files.  This happens frequently, often at idle time, if you visit a
large C file.

The trouble is that c-forward-conditional sets the mark.  The call to it
is wrapped in a save-excursion, so it doesn't clobber the user's mark,
but it does lead to a stream of ugly "Mark set" messages.

Would it be possible to change c-forward-conditional so that it pushes
the mark only if called interactively?

Re: Semantic parser uses c-forward-conditional

[Chong Yidong]

> Would it be possible to change c-forward-conditional so that it pushes
> the mark only if called interactively?

Or to call `push-mark' with a non-nil NOMSG argument if called
non-interactively.  That may be safer, I don't know.

Re: Semantic parser uses c-forward-conditional

[Alan Mackenzie]

Hi, Yidong!

On Mon, Sep 21, 2009 at 03:19:10PM -0400, Chong Yidong wrote:
> Hi Alan,

> Semantic's C parser calls c-forward-conditional while it's parsing C
> files.  This happens frequently, often at idle time, if you visit a
> large C file.

Ah.  c-forward-conditional is really intended as an interactive command
rather than for use in a lisp function - a bit like beginning-of-buffer.

> The trouble is that c-forward-conditional sets the mark.  The call to it
> is wrapped in a save-excursion, so it doesn't clobber the user's mark,
> but it does lead to a stream of ugly "Mark set" messages.

> Would it be possible to change c-forward-conditional so that it pushes
> the mark only if called interactively?

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".

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Semantic parser uses c-forward-conditional

[Eric M. Ludlam]

On Tue, 2009-09-22 at 10:57 +0000, Alan Mackenzie wrote:
> Hi, Yidong!
> 
> On Mon, Sep 21, 2009 at 03:19:10PM -0400, Chong Yidong wrote:
> > Hi Alan,
> 
> > Semantic's C parser calls c-forward-conditional while it's parsing C
> > files.  This happens frequently, often at idle time, if you visit a
> > large C file.
> 
> Ah.  c-forward-conditional is really intended as an interactive command
> rather than for use in a lisp function - a bit like beginning-of-buffer.
> 
> > The trouble is that c-forward-conditional sets the mark.  The call to it
> > is wrapped in a save-excursion, so it doesn't clobber the user's mark,
> > but it does lead to a stream of ugly "Mark set" messages.
> 
> > Would it be possible to change c-forward-conditional so that it pushes
> > the mark only if called interactively?
> 
> 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.

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

Eric

Re: Semantic parser uses c-forward-conditional

[Richard Stallman]

    The trouble is that c-forward-conditional sets the mark.  The call to it
    is wrapped in a save-excursion, so it doesn't clobber the user's mark,
    but it does lead to a stream of ugly "Mark set" messages.

Perhaps the clean solution is to break out most of the code into a
lower-level function that doesn't set the mark.

Re: Semantic parser uses c-forward-conditional

[Alan Mackenzie]

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).

Re: Semantic parser uses c-forward-conditional

[Richard Stallman]

    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?

Since that would be meant as a command for other programs to use,
and not merely a subroutine, it would be better to give it a name
that fits.

Re: Semantic parser uses c-forward-conditional

[Alan Mackenzie]

Hi, Richard and Eric!

On Wed, Sep 23, 2009 at 02:30:18AM -0400, Richard Stallman 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?

> Since that would be meant as a command for other programs to use,
> and not merely a subroutine, it would be better to give it a name
> that fits.

Um, well, thanks for the suggestion.  ;-)

How about `c-scan-conditionals', since the function does the same as
scan-lists, more or less?  Actually, more, since it moves point to the
end position, unlike scan-lists.  Maybe the new c-scan-conditionals
shouldn't move point?

Eric, what do you think?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Semantic parser uses c-forward-conditional

[Eric M. Ludlam]

On Wed, 2009-09-23 at 09:24 +0000, Alan Mackenzie wrote:
> Hi, Richard and Eric!
> 
> On Wed, Sep 23, 2009 at 02:30:18AM -0400, Richard Stallman 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?
> 
> > Since that would be meant as a command for other programs to use,
> > and not merely a subroutine, it would be better to give it a name
> > that fits.
> 
> Um, well, thanks for the suggestion.  ;-)
> 
> How about `c-scan-conditionals', since the function does the same as
> scan-lists, more or less?  Actually, more, since it moves point to the
> end position, unlike scan-lists.  Maybe the new c-scan-conditionals
> shouldn't move point?
> 
> Eric, what do you think?
> 

For your reference, here is the file in which I use
c-forward-conditional, and any other c specific functions:

http://cedet.cvs.sourceforge.net/viewvc/*checkout*/cedet/cedet/semantic/bovine/semantic-c.el

It would not greatly affect my code if some new function moved the
point, or just returned where the end is.  In
semantic-c-skip-conditional-section it is trying to do more than just
skip a conditional.  It is trying to skip only parts of a conditional,
and allow other parts to be analyzed regularly.  (ie - execute the
effects of the preprocessor.)  The c-forward-conditional call is used on
nested ifs so I don't have to deal with the balancing of the conditional
commands.

For all I know, there may be some additional cc-mode features I could
take advantage of to help solve this problem.

Eric

Re: Semantic parser uses c-forward-conditional

[Alan Mackenzie]

Hi, Eric!

On Wed, Sep 23, 2009 at 07:22:56AM -0400, Eric M. Ludlam wrote:
> On Wed, 2009-09-23 at 09:24 +0000, Alan Mackenzie wrote:
> > Hi, Richard and Eric!

> > How about `c-scan-conditionals', since the function does the same as
> > scan-lists, more or less?  Actually, more, since it moves point to the
> > end position, unlike scan-lists.  Maybe the new c-scan-conditionals
> > shouldn't move point?

> > Eric, what do you think?


> For your reference, here is the file in which I use
> c-forward-conditional, and any other c specific functions:

> http://cedet.cvs.sourceforge.net/viewvc/*checkout*/cedet/cedet/semantic/bovine/semantic-c.el

Thanks, I had a look at that.

> It would not greatly affect my code if some new function moved the
> point, or just returned where the end is.

OK.  I just committed a change to .../lisp/progmodes/cc-cmds.el with the
new function c-scan-conditionals which doesn't set the mark, and doesn't
move point, instead returning the final position, much like scan-lists.

> In semantic-c-skip-conditional-section it is trying to do more than
> just skip a conditional.  It is trying to skip only parts of a
> conditional, and allow other parts to be analyzed regularly.  (ie -
> execute the effects of the preprocessor.)  The c-forward-conditional
> call is used on nested ifs so I don't have to deal with the balancing
> of the conditional commands.

> For all I know, there may be some additional cc-mode features I could
> take advantage of to help solve this problem.

Possibly the WITH-ELSE parameter to c-scan-conditionals might be useful.

> Eric

-- 
Alan Mackenzie (Nuremberg, Germany).