GNU bug report logs - #2379
[PATCH?] lisp.el: beginning-of-defun

Previous Next

Full log

Message #32 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Aaron S. Hawley" <aaron.s.hawley <at> gmail.com>
Cc: 2379 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2379: [PATCH?] lisp.el: beginning-of-defun
Date: Fri, 20 Feb 2009 10:25:40 -0500

>> AFAICT, proper support for 0 would require a serious rethink of BOD's
>> semantics: currently if you're inside defun number N, then (BOD i) moves
>> to (N-(i-1)) is i is positive and to (N-i) if i is negative.  I.e. it
>> moves to N if i=1 and to N+1 if i=-1, so where should 0 move to: there
>> is no other defun between those two.

> Fair enough.

> I notice that C-0 M-x end-of-defun is the same as just regular M-x
> end-of-defun.

Yes, I also noticed it when I rewrite end-of-defun, but just as is the
case for BOD, making it to "TRT" for 0 would require more significant
changes I think.  So I figured I may as well preserve the old broken
behavior rather than change it to some other broken behavior.

> Also, It's worth citing beginning-of-line's behavior
> here, since it departs by moving in the opposite direction --  N-1+i.
> Anyway, I'm just surprised this critical code for Lisp support is
> this sloppy.

We're all surprised.  But remember: Emacs is mostly made up of
"sloppy" code.  And there's a good reaon for that: it's often very
difficult to figure out what is "the right behavior", so the first
implementations just do an approximate job, which gets somewhat refined
over time, but backward compatibility means that it often can't be
refined to the point of being correct.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.