[Top][All Lists]

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

Re: end-of-defun is fubsr.

From: Alan Mackenzie
Subject: Re: end-of-defun is fubsr.
Date: Sat, 14 Feb 2009 23:25:35 +0000
User-agent: Mutt/1.5.9i

Hi, Stefan,

On Sat, Feb 14, 2009 at 04:16:53PM -0500, Stefan Monnier wrote:
> >> I don't think the return result is ever used as of now.  So I'd rather
> >> not document such a thing.
> > Emacs 22 and 21 end-of-defun return end-of-defun's result as
> > EOD-function's own return value, even if it wasn't documented.

It was documented, sort of, in that the `beginning-of-defun' documents
its own return value, and `end-of-defun' says "see function

The doc-string of `end-of-defun' (very nearly) explicitly states that it
is only for use in languages which have close parentheses at EODs.

> It wasn't documented and should stay that way.

> > We shouldn't change this, surely?

> We have changed this.

Should I put an entry into NEWS for it?

> > How about this, then:?

> I prefer the current text.

Was my patch really that bad?

Look, I'm as sick of all this as you must be.  This whole area of
beginning/end-of-defuns is riven with vagueness of documentation and
inconsistencies between fine manuals and doc strings, between doc strings
and code, between beginning- and end-.

Defun movement commands are _important_ in major modes for programming

I have solid experience with writing and maintaining
beginning/end-of-defun functions, and the frustration over several years
of trying to link them smoothly into Emacs, something which should be
utterly trivial, has been intense in the extreme.  Basically, I've pretty
much given up trying to hook in the CC Mode defun stuff.  Not good.

I won't say it's unusable to a major mode maintainer, because it clearly
isn't.  I will say that it's a wretched experience - you can't write
B/EOD-functions without reading the fine source code in its finest
detail, which for something which should be so easy, is lacking fun in
the extreme.

How about me collecting together the existing work, rendering it
consistent, logical, backward compatible (in so far as that is possible),
as usable as possible, sprucing up all the pertinent doc strings and
manual pages, and submitting a patch for it to emacs-devel?

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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