GNU bug report logs - #64574
[PATCH] Support not jumping to bol in beginning-of-defun

Previous Next

To reply to this bug, email your comments to 64574 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Support not jumping to bol in beginning-of-defun
Date: Tue, 11 Jul 2023 14:15:35 -0400

[Message part 1 (text/plain, inline)]

Tags: patch


As mentioned in the commit, this default behavior by
beginning-of-defun is undesirable in some languages and major modes.
I'm thinking of OCaml in particular here, but it's also arguably
unwanted in Python and C++ as well, where defs may be indented inside
class definitions.  Let's let users and major modes make this decision
on a case-by-case basis.

In GNU Emacs 29.0.92 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-07-10 built on
 igm-qws-u22796a
Repository revision: dd15432ffacbeff0291381c0109f5b1245060b1d
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --config-cache --with-x-toolkit=lucid
 --with-gif=ifavailable'

[0001-Support-not-jumping-to-bol-in-beginning-of-defun.patch (text/patch, attachment)]

Message #8 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Tue, 11 Jul 2023 21:50:58 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Tue, 11 Jul 2023 14:15:35 -0400
> 
> As mentioned in the commit, this default behavior by
> beginning-of-defun is undesirable in some languages and major modes.
> I'm thinking of OCaml in particular here, but it's also arguably
> unwanted in Python and C++ as well, where defs may be indented inside
> class definitions.  Let's let users and major modes make this decision
> on a case-by-case basis.

Such optional behavior is fine by me, but is there any evidence enough
people will want it?  Can you gather some feedback about that?

> +(defvar beginning-of-defun-go-beginning-of-line t

Why not defcustom?

And I would use a shorter name, like beginning-of-defun-go-bol.

> +  "If non-nil, `beginning-of-defun' runs `beginning-of-line' at the end.

This describes implementation, not the behavior.  It also assumes
everyone knows what exactly beginning-of-line does (think RTL text).

> +By default, `beginning-of-defun' jumps to the beginning of the
> +line with `beginning-of-line' after finding the start of the
> +defun.

I see no reason to tell in the doc string how exactly the function
goes to BOL.  It can even be a problem if at some future point we
decide to change the implementation.

> +For languages where defuns may be indented inside nested
> +structures like classes or modules, this behavior may be
> +undesirable.  Major modes for such languages can set this
> +variable to nil to avoid it.")

Not sure we should leave this to major modes and not to the individual
users.

Thanks.

Message #11 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Tue, 11 Jul 2023 19:27:55 -0700

On 7/11/2023 11:50 AM, Eli Zaretskii wrote:
> Such optional behavior is fine by me, but is there any evidence enough
> people will want it?  Can you gather some feedback about that?

For what it's worth, I'd probably use this.

Message #14 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Wed, 12 Jul 2023 10:57:50 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Tue, 11 Jul 2023 14:15:35 -0400
>> 
>> As mentioned in the commit, this default behavior by
>> beginning-of-defun is undesirable in some languages and major modes.
>> I'm thinking of OCaml in particular here, but it's also arguably
>> unwanted in Python and C++ as well, where defs may be indented inside
>> class definitions.  Let's let users and major modes make this decision
>> on a case-by-case basis.
>
> Such optional behavior is fine by me, but is there any evidence enough
> people will want it?  Can you gather some feedback about that?

Users at my site have expressed a preference for this (including me,
once I thought about it enough to realize I don't like the default
behavior).  And Jim Porter just mentioned that they would prefer this
too.

>> +(defvar beginning-of-defun-go-beginning-of-line t
>
> Why not defcustom?
>
> And I would use a shorter name, like beginning-of-defun-go-bol.

Can do.

>> +  "If non-nil, `beginning-of-defun' runs `beginning-of-line' at the end.
>
> This describes implementation, not the behavior.  It also assumes
> everyone knows what exactly beginning-of-line does (think RTL text).
>
>> +By default, `beginning-of-defun' jumps to the beginning of the
>> +line with `beginning-of-line' after finding the start of the
>> +defun.
>
> I see no reason to tell in the doc string how exactly the function
> goes to BOL.  It can even be a problem if at some future point we
> decide to change the implementation.

Can do.

>> +For languages where defuns may be indented inside nested
>> +structures like classes or modules, this behavior may be
>> +undesirable.  Major modes for such languages can set this
>> +variable to nil to avoid it.")
>
> Not sure we should leave this to major modes and not to the individual
> users.
>
> Thanks.

Sure, I'm fine with having it be a defcustom that users can set.

Revised patch:

[0001-Support-not-jumping-to-bol-in-beginning-of-defun.patch (text/x-patch, inline)]

From be03d6e994303c3f32d676194f6f31e89917013e Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 11 Jul 2023 14:14:34 -0400
Subject: [PATCH] Support not jumping to bol in beginning-of-defun

As mentioned in the commit, this default behavior by
beginning-of-defun may be undesirable in some languages and major
modes.  I'm thinking of OCaml in particular here, but it's also
arguably unwanted in Python and C++ as well, where defs may be
indented inside class definitions.  Let's let the user make this
decision.

* lisp/emacs-lisp/lisp.el (beginning-of-defun-go-bol): Add defcustom.
(beginning-of-defun): Check beginning-of-defun-go-bol.
---
 lisp/emacs-lisp/lisp.el | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/lisp/emacs-lisp/lisp.el b/lisp/emacs-lisp/lisp.el
index b91d56cfb4f..e5b024b19a6 100644
--- a/lisp/emacs-lisp/lisp.el
+++ b/lisp/emacs-lisp/lisp.el
@@ -335,6 +335,17 @@ kill-backward-up-list
           (insert current-sexp))
       (user-error "Not at a sexp"))))
 
+(defcustom beginning-of-defun-go-bol t
+  "If non-nil, `beginning-of-defun' moves to beginning of line.
+
+By default, `beginning-of-defun' point moves to the beginning of
+the line where a defun starts.  For languages where defuns may be
+indented inside nested structures like classes or modules, this
+behavior may be undesirable."
+  :type '(choice (const :tag "Don't go to BOL in beginning-of-defun" nil)
+                 (const :tag "Go to BOL in beginning-of-defun" t))
+  :group 'lisp)
+
 (defvar beginning-of-defun-function nil
   "If non-nil, function for `beginning-of-defun-raw' to call.
 This is used to find the beginning of the defun instead of using the
@@ -367,16 +378,17 @@ beginning-of-defun
 value is called as a function, with argument ARG, to find the
 defun's beginning.
 
-Regardless of the values of `defun-prompt-regexp' and
-`beginning-of-defun-function', point always moves to the
-beginning of the line whenever the search is successful."
+If `beginning-of-defun-go-bol' is non-nil, point moves to the
+beginning of the line if the search is successful."
   (interactive "^p")
   (or (not (eq this-command 'beginning-of-defun))
       (eq last-command 'beginning-of-defun)
       (and transient-mark-mode mark-active)
       (push-mark))
   (and (beginning-of-defun-raw arg)
-       (progn (beginning-of-line) t)))
+       (progn (when beginning-of-defun-go-bol
+                (beginning-of-line))
+              t)))
 
 (defun beginning-of-defun-raw (&optional arg)
   "Move point to the character that starts a defun.
-- 
2.39.3

Message #17 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sat, 22 Jul 2023 16:17:25 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 64574 <at> debbugs.gnu.org
> Date: Wed, 12 Jul 2023 10:57:50 -0400
> 
> Revised patch:

Thanks.  Please add a NEWS entry, and we can install this then.

Message #20 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 3 Sep 2023 04:44:30 -0700

Spencer Baugh <sbaugh <at> janestreet.com> writes:

> Users at my site have expressed a preference for this (including me,
> once I thought about it enough to realize I don't like the default
> behavior).  And Jim Porter just mentioned that they would prefer this
> too.

I'd use it too.

>>> +(defvar beginning-of-defun-go-beginning-of-line t
>>
>> Why not defcustom?
>>
>> And I would use a shorter name, like beginning-of-defun-go-bol.
>
> Can do.

Perhaps `beginning-of-defun-jumps-to-bol'?

>>From be03d6e994303c3f32d676194f6f31e89917013e Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Tue, 11 Jul 2023 14:14:34 -0400
> Subject: [PATCH] Support not jumping to bol in beginning-of-defun
>
> As mentioned in the commit, this default behavior by
> beginning-of-defun may be undesirable in some languages and major
> modes.  I'm thinking of OCaml in particular here, but it's also
> arguably unwanted in Python and C++ as well, where defs may be
> indented inside class definitions.  Let's let the user make this
> decision.

Your patch still lacks a NEWS item before it can be installed.

Message #25 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 23 Feb 2025 06:40:44 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 64574 <at> debbugs.gnu.org
>> Date: Wed, 12 Jul 2023 10:57:50 -0400
>>
>> Revised patch:
>
> Thanks.  Please add a NEWS entry, and we can install this then.

Actually, thinking about this, we use this function not just as a
command, but also in a lot of code that is built on the assumption that
point moves to point zero.

So wouldn't installing this, as proposed, risk leading to a lot of
things breaking?

Message #30 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: sbaugh <at> janestreet.com, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 23 Feb 2025 09:15:03 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 23 Feb 2025 06:40:44 +0000
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 64574 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: 64574 <at> debbugs.gnu.org
> >> Date: Wed, 12 Jul 2023 10:57:50 -0400
> >>
> >> Revised patch:
> >
> > Thanks.  Please add a NEWS entry, and we can install this then.
> 
> Actually, thinking about this, we use this function not just as a
> command, but also in a lot of code that is built on the assumption that
> point moves to point zero.

What do you mean by "point zero"?

> So wouldn't installing this, as proposed, risk leading to a lot of
> things breaking?

The default behavior is unchanged.  As for when users change the
default, the only difference is that beginning-of-defun will end not
necessarily at column zero, but at some other column in the same line,
where the function's declaration begins.  I don't see how this could
break things, but maybe I'm missing something?  Can you point to
places where we assume pointy is at column zero after calling
beginning-of-defun?

Message #33 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 23 Feb 2025 14:15:55 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Actually, thinking about this, we use this function not just as a
>> command, but also in a lot of code that is built on the assumption that
>> point moves to point zero.
>
> What do you mean by "point zero"?

Sorry, typo.  I meant to say "column zero".

>> So wouldn't installing this, as proposed, risk leading to a lot of
>> things breaking?
>
> The default behavior is unchanged.  As for when users change the
> default, the only difference is that beginning-of-defun will end not
> necessarily at column zero, but at some other column in the same line,
> where the function's declaration begins.  I don't see how this could
> break things, but maybe I'm missing something?  Can you point to
> places where we assume pointy is at column zero after calling
> beginning-of-defun?

I can't point to any specific such places no, but grepping for
`beginning-of-defun` yields a concerning number of hits, especially in
progmodes.  Note that the assumption that it always goes to column zero
has been documented since forever.  Who knows how this is used in the wild.

IOW, yes, the behavior is optional, but my concern is that when users
set it, modes will start breaking.  I still think it could be useful,
but perhaps it should be a defvar and under the control of major modes?
OTOH, then we have minor modes, but maybe it's used less frequently
there?

If someone could look into this more and run some experiments, perhaps
we can convince ourselves that this is fine after all, but to me this
currently feels a bit risky.

Message #36 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: sbaugh <at> janestreet.com, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 23 Feb 2025 16:30:42 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 23 Feb 2025 14:15:55 +0000
> Cc: sbaugh <at> janestreet.com, 64574 <at> debbugs.gnu.org
> 
> > The default behavior is unchanged.  As for when users change the
> > default, the only difference is that beginning-of-defun will end not
> > necessarily at column zero, but at some other column in the same line,
> > where the function's declaration begins.  I don't see how this could
> > break things, but maybe I'm missing something?  Can you point to
> > places where we assume pointy is at column zero after calling
> > beginning-of-defun?
> 
> I can't point to any specific such places no, but grepping for
> `beginning-of-defun` yields a concerning number of hits, especially in
> progmodes.  Note that the assumption that it always goes to column zero
> has been documented since forever.  Who knows how this is used in the wild.
> 
> IOW, yes, the behavior is optional, but my concern is that when users
> set it, modes will start breaking.

I hope the users who Spencer say like it tested that in at least some
situations?

> I still think it could be useful, but perhaps it should be a defvar
> and under the control of major modes?  OTOH, then we have minor
> modes, but maybe it's used less frequently there?

Is this major-mode specific?

> If someone could look into this more and run some experiments, perhaps
> we can convince ourselves that this is fine after all, but to me this
> currently feels a bit risky.

I suggested to make it a user option because Spencer indicated users
liked that behavior.  User preferences should be expressed in user
options, not in just variables.

But if you feel uneasy, I won't object to making it a simple variable.

Message #39 received at 64574 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 64574 <at> debbugs.gnu.org
Subject: Re: bug#64574: [PATCH] Support not jumping to bol in
 beginning-of-defun
Date: Sun, 23 Feb 2025 15:07:47 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> I hope the users who Spencer say like it tested that in at least some
> situations?

I would like to hear specific reports, to be honest.

For example, when I said that "I'll probably use it", I hadn't really
tested it.  Hopefully not everyone is as irresponsible as I was.  :-)

>> I still think it could be useful, but perhaps it should be a defvar
>> and under the control of major modes?  OTOH, then we have minor
>> modes, but maybe it's used less frequently there?
>
> Is this major-mode specific?

I believe that it might be, e.g. in C and Lisp functions almost always
start at column 0, but in C++, Python, OCaml and so on you can have
additional indentation.  This might be true for any language that has
classes, so Ruby, JavaScript, etc.

> I suggested to make it a user option because Spencer indicated users
> liked that behavior.  User preferences should be expressed in user
> options, not in just variables.
>
> But if you feel uneasy, I won't object to making it a simple variable.

Maybe I forgot to mention this, but if we make it a variable, then major
mode authors that use it will also have a chance to adapt to it and fix
any potential bugs.

We can also keep the option to turn it into a defcustom later.  Perhaps
my concerns will turn out to be overblown with more experience.

Previous Next

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