emacs-devel
[Top][All Lists]
Advanced

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

Re: simplifying beginning-of-defun


From: Stefan Monnier
Subject: Re: simplifying beginning-of-defun
Date: Sun, 27 Sep 2009 14:53:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

> I agree with the basic mechanics of what Andreas is providing here, not
> any specific feature change involved in the patch.  If there were some
> function like the -raw functions he proposed that program modes would
> use if they wanted exactly that behavior, and a separate interactive
> function, then that opens the door for improvements on the interactive
> function.

We already have beginning-of-defun and beginning-of-defun-raw exactly
for these kinds of reasons.

> This comes up specifically with CEDET, where I can use parser
> information to do a real `beginning-of-defun' for langauges whos defuns
> don't happen to start with a ( in the first column.  From an interactive
> point of view, a total win.

So you mean you'd want both beginning-of-defun-raw-function and
beginning-of-defun-function (additionally to (define-key map [remap
beginning-of-defun] ...), of course)?
I'd have to think about it.

> From a programs point of view, this would mean disaster if all their
> code was expecting the cursor to show up on some opening {, and not on
> the text actually starting the defun.  For modes like cc-mode that
> write their own correct `beginning-of-defun', they would use that
> internally anyway, so no loss.

So you mean we should provide a default-beginning-of-defun which is not
subject to any *-function fiddling and change some of the calls to
beginning-of-defun to use that function instead, so they're more robust
in cases where something like CEDET sets beginning-of-defun-function?
That makes sense, yet.

> Right now, the feature I describe in CEDET/Semantic is done with advice
> and various if statements making sure not to do the modification in
> non-interactive cases.  The code is in senator.el.

I think that interactive/noninteractive is not the right distinction
(there are non-interactive cases which would also benefit from using an
improved implementation).  It's probably the best (conservative)
solution you could use, because the right solution requires more changes
to other packages.


        Stefan




reply via email to

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