unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
@ 2023-07-11 18:15 Spencer Baugh
  2023-07-11 18:50 ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Spencer Baugh @ 2023-07-11 18:15 UTC (permalink / raw)
  To: 64574

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

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'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Support-not-jumping-to-bol-in-beginning-of-defun.patch --]
[-- Type: text/patch, Size: 2136 bytes --]

From 12c4f80e046c3c6dd6996e13f332d0eb41d1f1dd Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@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 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.

* lisp/emacs-lisp/lisp.el (beginning-of-defun-go-beginning-of-line):
Add variable.
(beginning-of-defun): Check variable.
---
 lisp/emacs-lisp/lisp.el | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/lisp.el b/lisp/emacs-lisp/lisp.el
index b91d56cfb4f..70c296b2c31 100644
--- a/lisp/emacs-lisp/lisp.el
+++ b/lisp/emacs-lisp/lisp.el
@@ -335,6 +335,18 @@ kill-backward-up-list
           (insert current-sexp))
       (user-error "Not at a sexp"))))
 \f
+(defvar beginning-of-defun-go-beginning-of-line t
+  "If non-nil, `beginning-of-defun' runs `beginning-of-line' at the end.
+
+By default, `beginning-of-defun' jumps to the beginning of the
+line with `beginning-of-line' after finding the start of the
+defun.
+
+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.")
+
 (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
@@ -376,7 +388,9 @@ 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-beginning-of-line
+                (beginning-of-line))
+              t)))
 
 (defun beginning-of-defun-raw (&optional arg)
   "Move point to the character that starts a defun.
-- 
2.39.3


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
  2023-07-11 18:15 bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun Spencer Baugh
@ 2023-07-11 18:50 ` Eli Zaretskii
  2023-07-12  2:27   ` Jim Porter
  2023-07-12 14:57   ` Spencer Baugh
  0 siblings, 2 replies; 6+ messages in thread
From: Eli Zaretskii @ 2023-07-11 18:50 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 64574

> From: Spencer Baugh <sbaugh@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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
  2023-07-11 18:50 ` Eli Zaretskii
@ 2023-07-12  2:27   ` Jim Porter
  2023-07-12 14:57   ` Spencer Baugh
  1 sibling, 0 replies; 6+ messages in thread
From: Jim Porter @ 2023-07-12  2:27 UTC (permalink / raw)
  To: Eli Zaretskii, Spencer Baugh; +Cc: 64574

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
  2023-07-11 18:50 ` Eli Zaretskii
  2023-07-12  2:27   ` Jim Porter
@ 2023-07-12 14:57   ` Spencer Baugh
  2023-07-22 13:17     ` Eli Zaretskii
  2023-09-03 11:44     ` Stefan Kangas
  1 sibling, 2 replies; 6+ messages in thread
From: Spencer Baugh @ 2023-07-12 14:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 64574

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Support-not-jumping-to-bol-in-beginning-of-defun.patch --]
[-- Type: text/x-patch, Size: 2618 bytes --]

From be03d6e994303c3f32d676194f6f31e89917013e Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@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"))))
 \f
+(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


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
  2023-07-12 14:57   ` Spencer Baugh
@ 2023-07-22 13:17     ` Eli Zaretskii
  2023-09-03 11:44     ` Stefan Kangas
  1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2023-07-22 13:17 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 64574

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 64574@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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
  2023-07-12 14:57   ` Spencer Baugh
  2023-07-22 13:17     ` Eli Zaretskii
@ 2023-09-03 11:44     ` Stefan Kangas
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Kangas @ 2023-09-03 11:44 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: Eli Zaretskii, 64574

Spencer Baugh <sbaugh@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@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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-09-03 11:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-11 18:15 bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun Spencer Baugh
2023-07-11 18:50 ` Eli Zaretskii
2023-07-12  2:27   ` Jim Porter
2023-07-12 14:57   ` Spencer Baugh
2023-07-22 13:17     ` Eli Zaretskii
2023-09-03 11:44     ` Stefan Kangas

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).