Re: simplifying beginning-of-defun

[Stefan Monnier]

>> I can't think of a reason why #3 wouldn't want to be affected by #4.
>> Note that for #2, it's not just the interactive form, since it also
>> affects #3 (e.g. mark-defun, send-defun-to-inferior-process, younameit,
>> ...).
> Hmmm.  A dilemma.  Given this C code:

I'm not sure what problem/dilemma you're alluding to.

> Of course, perhaps I am wrong in thinking that stopping on 'int' is
> preferred, but I do know it is preferred by me.  Would this make the
> CEDET behavior as found in 'senator' completely new in some way?

I guess it would, but then again I have no idea why it would matter
whether it's completely new or not (i.e. I don't understand what you're
trying to say, I guess).

>> What about programs that want to use CEDET but that also want to work
>> when CEDET is not available?  They would most likely want to use
>> beginning-of-defun.
> I had not contemplated this in the context of beginning-of-defun.
> Ideally they would not need some if statement to deal with the issue.

Exactly.

> Of course, the need here would be pretty basic stuff too if it was
> robust to the actual landing place being different for different
> situations, sort of the way narrow-to-defun might not care exactly where
> it lands, so long as it goes somewhere.

Very much so, indeed.
I'd say that pretty much all calls to beginning-of-defun(-raw) should
follow this principle.


        Stefan