unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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


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