unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: eric@siege-engine.com
Cc: emacs-devel@gnu.org, Andreas Roehler <andreas.roehler@online.de>,
	XEmacs-Beta@xemacs.org
Subject: Re: simplifying beginning-of-defun
Date: Sun, 27 Sep 2009 14:53:41 -0400	[thread overview]
Message-ID: <jwvy6o0b58h.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <1254050248.6168.30.camel@projectile.siege-engine.com> (Eric M. Ludlam's message of "Sun, 27 Sep 2009 07:17:28 -0400")

> 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	other threads:[~2009-09-27 18:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-26 17:52 simplifying beginning-of-defun Andreas Roehler
2009-09-26 21:44 ` Stefan Monnier
2009-09-27  8:10   ` Andreas Roehler
2009-09-27 18:40     ` Stefan Monnier
2009-09-28  6:50       ` Andreas Roehler
2009-09-28 22:46         ` Stefan Monnier
2009-09-29  6:53           ` Andreas Roehler
2009-09-29  8:29           ` Andreas Roehler
2009-09-27 10:26   ` Andreas Roehler
2009-09-27 11:17     ` Eric M. Ludlam
2009-09-27 18:53       ` Stefan Monnier [this message]
2009-09-27 20:07         ` Eric M. Ludlam
2009-09-27 22:52           ` Stefan Monnier
2009-09-28  2:04             ` Eric M. Ludlam
2009-09-28  4:06               ` Stefan Monnier
2009-09-28 11:20                 ` Eric M. Ludlam
2009-09-29  6:50               ` Alan Mackenzie
2009-09-27 19:06 ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvy6o0b58h.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=XEmacs-Beta@xemacs.org \
    --cc=andreas.roehler@online.de \
    --cc=emacs-devel@gnu.org \
    --cc=eric@siege-engine.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).