From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 64574@debbugs.gnu.org
Subject: bug#64574: [PATCH] Support not jumping to bol in beginning-of-defun
Date: Wed, 12 Jul 2023 10:57:50 -0400 [thread overview]
Message-ID: <ierjzv5qis1.fsf@janestreet.com> (raw)
In-Reply-To: <83edle704t.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 11 Jul 2023 21:50:58 +0300")
[-- 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
next prev parent reply other threads:[~2023-07-12 14:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2023-07-22 13:17 ` Eli Zaretskii
2023-09-03 11:44 ` Stefan Kangas
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=ierjzv5qis1.fsf@janestreet.com \
--to=sbaugh@janestreet.com \
--cc=64574@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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).