GNU bug report logs - #75355
[PATCH 0/1] Improve comment cycling in log-edit

Previous Next

To reply to this bug, email your comments to 75355 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: Jonas Bernoulli <jonas <at> bernoul.li>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH 0/1] Improve comment cycling in log-edit
Date: Sat,  4 Jan 2025 17:28:59 +0100

Hello,

In https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg00041.html
we are discussing adding git-commit.el to Emacs.  This change is triggered
by that discussion but what I suggest here is to first move some code out
of git-commit.el and into log-edit.el.

Previously git-commit.el wrapped around some commands from log-edit.el
to provide better variants.  The following patch instead modifies the
existing commands.  It also adds a new command and a new helper function.

     Cheers,
     Jonas


Jonas Bernoulli (1):
  Improve comment cycling in log-edit

 lisp/vc/log-edit.el | 62 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 59 insertions(+), 3 deletions(-)

-- 
2.47.1

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: 75355 <at> debbugs.gnu.org
Subject: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sat,  4 Jan 2025 18:11:08 +0100

Save the current message before cycling to older messages, making it
possible to cycle back to that initial message.

* lisp/vc/log-edit.el (log-edit-buffer-comment): New function.
(log-edit-save-comment): New command, using new function.
(log-edit-mode-map, log-edit-menu): Bind new command.
(log-edit-previous-comment): Use new function.

Port log-edit-comment-ring improvements from git-commit.el
---
 lisp/vc/log-edit.el | 62 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/lisp/vc/log-edit.el b/lisp/vc/log-edit.el
index e23e7414a18..79ea89bc728 100644
--- a/lisp/vc/log-edit.el
+++ b/lisp/vc/log-edit.el
@@ -61,6 +61,7 @@ log-edit-mode-map
   "C-c C-d" #'log-edit-show-diff
   "C-c C-f" #'log-edit-show-files
   "C-c C-k" #'log-edit-kill-buffer
+  "C-c C-s" #'log-edit-save-comment
   "M-n"     #'log-edit-next-comment
   "M-p"     #'log-edit-previous-comment
   "M-r"     #'log-edit-comment-search-backward
@@ -86,6 +87,8 @@ log-edit-menu
     ["List files" log-edit-show-files
      :help "Show the list of relevant files."]
     "--"
+    ["Save comment"		log-edit-save-comment
+     :help "Save the current comment to comment history"]
     ["Previous comment"		log-edit-previous-comment
      :help "Cycle backwards through comment history"]
     ["Next comment"		log-edit-next-comment
@@ -280,15 +283,68 @@ log-edit-new-comment-index
 	(t stride))
        len))
 
+(defun log-edit-buffer-comment ()
+  "Return the comment in the current buffer.
+Remove lines after the scissors line (\"------- >8 ------\") and
+commented lines from the returned string.  Also remove leading and
+trailing whitespace.  If the comment consists solely of whitespace,
+return nil."
+  (let ((flush (concat "^" comment-start))
+        (str (buffer-substring-no-properties (point-min) (point-max))))
+    (with-temp-buffer
+      (insert str)
+      (goto-char (point-min))
+      (when (re-search-forward (concat flush " -+ >8 -+$") nil t)
+        (delete-region (line-beginning-position) (point-max)))
+      (goto-char (point-min))
+      (flush-lines flush)
+      (goto-char (point-max))
+      (unless (eq (char-before) ?\n)
+        (insert ?\n))
+      (setq str (buffer-string)))
+    (and (not (string-match "\\`[ \t\n\r]*\\'" str))
+         (progn
+           (when (string-match "\\`\n\\{2,\\}" str)
+             (setq str (replace-match "\n" t t str)))
+           (when (string-match "\n\\{2,\\}\\'" str)
+             (setq str (replace-match "\n" t t str)))
+           str))))
+
+(defun log-edit-save-comment ()
+  "Save current comment to `log-edit-comment-ring'."
+  (interactive)
+  (if-let* ((comment (log-edit-buffer-comment)))
+      (progn
+        (when-let* ((index (ring-member log-edit-comment-ring comment)))
+          (ring-remove log-edit-comment-ring index))
+        (ring-insert log-edit-comment-ring comment)
+        ;; This hook can be used, e.g., to store this in an alternative,
+        ;; repository-local ring.
+        (run-hooks 'log-edit-save-comment-hook)
+        (message "Comment saved"))
+    (message "Only whitespace and/or comments; message not saved")))
+
 (defun log-edit-previous-comment (arg)
   "Cycle backwards through VC commit comment history.
 With a numeric prefix ARG, go back ARG comments."
   (interactive "*p")
   (let ((len (ring-length log-edit-comment-ring)))
     (if (<= len 0)
-	(progn (message "Empty comment ring") (ding))
-      ;; Don't use `erase-buffer' because we don't want to `widen'.
-      (delete-region (point-min) (point-max))
+        (progn (message "Empty comment ring") (ding))
+      (when-let* ((comment (log-edit-buffer-comment))
+                  ((not (ring-member log-edit-comment-ring comment))))
+        (ring-insert log-edit-comment-ring comment)
+        (cl-incf arg)
+        (setq len (ring-length log-edit-comment-ring)))
+      ;; Delete the message but not the instructions at the end.
+      (save-restriction
+        (goto-char (point-min))
+        (narrow-to-region
+         (point)
+         (if (re-search-forward (concat "^" comment-start) nil t)
+             (max 1 (- (point) 2))
+           (point-max)))
+        (delete-region (point-min) (point)))
       (setq log-edit-comment-ring-index (log-edit-new-comment-index arg len))
       (message "Comment %d" (1+ log-edit-comment-ring-index))
       (insert (ring-ref log-edit-comment-ring log-edit-comment-ring-index)))))
-- 
2.47.1

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sat, 04 Jan 2025 20:39:30 +0200

> Date: Sat,  4 Jan 2025 18:11:08 +0100
> From:  Jonas Bernoulli via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Save the current message before cycling to older messages, making it
> possible to cycle back to that initial message.

Thanks, but can you provide some rationale for this?  Is the
assumption that users need to make several commits that all share the
same comment or something?

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sat, 04 Jan 2025 23:29:34 +0100

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

>> Date: Sat,  4 Jan 2025 18:11:08 +0100
>> From:  Jonas Bernoulli via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Save the current message before cycling to older messages, making it
>> possible to cycle back to that initial message.
>
> Thanks, but can you provide some rationale for this?  Is the
> assumption that users need to make several commits that all share the
> same comment or something?

That is one use-case for the feature as it exists now, yes.  Messages
are already automatically saved once the user either finished or aborts
the commit.

These changes don't really affect that.  I consider this additional
automatic saving a bugfix.  Without it, a user may start typing a new
message, decide to use a recent message instead, navigate to it but then
change their mind about that, and then they would not be able to go back
to the new message they had already started typing, because it was
discarded when they moved a way from it.  By saving the new message when
we move away from it, we make it possible to navigate back to it.

By additionally defining log-edit-save-comment as a command we gain the
ability to save the message at random point.  This could, for example,
be useful if we have to use very similar messages in different commits,
potentially across multiple repositories.  We could then write the
common part, save it as a "template", edit it some more, and finally
create a first commit.  Without the save command we could rely on the
automatic saving at the very end of that process, which would mean that
when creating the second commit we could not use the template as such,
but only template with the modifications for the first commit already
filled in.  More editing could be required to go from that to what we
actually want to use in the second commit.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sun, 05 Jan 2025 09:28:29 +0200

> From: Jonas Bernoulli <jonas <at> bernoul.li>
> Cc: 75355 <at> debbugs.gnu.org
> Date: Sat, 04 Jan 2025 23:29:34 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Sat,  4 Jan 2025 18:11:08 +0100
> >> From:  Jonas Bernoulli via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> Save the current message before cycling to older messages, making it
> >> possible to cycle back to that initial message.
> >
> > Thanks, but can you provide some rationale for this?  Is the
> > assumption that users need to make several commits that all share the
> > same comment or something?
> 
> That is one use-case for the feature as it exists now, yes.  Messages
> are already automatically saved once the user either finished or aborts
> the commit.
> 
> These changes don't really affect that.  I consider this additional
> automatic saving a bugfix.  Without it, a user may start typing a new
> message, decide to use a recent message instead, navigate to it but then
> change their mind about that, and then they would not be able to go back
> to the new message they had already started typing, because it was
> discarded when they moved a way from it.  By saving the new message when
> we move away from it, we make it possible to navigate back to it.

What do you mean by "move away" and "navigate", in the context of
log-edit?

> By additionally defining log-edit-save-comment as a command we gain the
> ability to save the message at random point.  This could, for example,
> be useful if we have to use very similar messages in different commits,
> potentially across multiple repositories.

Is this a frequent use case?  Why would the same log message be used
for different commits?

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sun, 05 Jan 2025 12:37:38 +0100

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

>> From: Jonas Bernoulli <jonas <at> bernoul.li>
>> Cc: 75355 <at> debbugs.gnu.org
>> Date: Sat, 04 Jan 2025 23:29:34 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Date: Sat,  4 Jan 2025 18:11:08 +0100
>> >> From:  Jonas Bernoulli via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >> 
>> >> Save the current message before cycling to older messages, making it
>> >> possible to cycle back to that initial message.
>> >
>> > Thanks, but can you provide some rationale for this?  Is the
>> > assumption that users need to make several commits that all share the
>> > same comment or something?
>> 
>> That is one use-case for the feature as it exists now, yes.  Messages
>> are already automatically saved once the user either finished or aborts
>> the commit.
>> 
>> These changes don't really affect that.  I consider this additional
>> automatic saving a bugfix.  Without it, a user may start typing a new
>> message, decide to use a recent message instead, navigate to it but then
>> change their mind about that, and then they would not be able to go back
>> to the new message they had already started typing, because it was
>> discarded when they moved a way from it.  By saving the new message when
>> we move away from it, we make it possible to navigate back to it.
>
> What do you mean by "move away" and "navigate", in the context of
> log-edit?

The buffer contains a draft to be used as the message for the commit
you are about to create.  "Moving away" from the message means using
the commands log-edit-previous/next-comment to "navigate" to another
message.  Doing so erased the contents of the buffer, and another
recently used message is inserted in its place.

>> By additionally defining log-edit-save-comment as a command we gain the
>> ability to save the message at random point.  This could, for example,
>> be useful if we have to use very similar messages in different commits,
>> potentially across multiple repositories.
>
> Is this a frequent use case?  Why would the same log message be used
> for different commits?

Using the same or very similar commit messages across different
repositories is a very frequent occurrence for me.  The last such
message was "Bump copyright years", but through out the year I also use
messages such as "Fix spelling errors", after running a spell-checker on
all my packages.

Granted, those two examples didn't need a "template".  I also frequently
fix some class of error across many third-party packages, as part of my
work on Melpa and the Emacsmirror.  In such cases I often write a long,
message explaining why something should be done a certain way.  The
message is almost the same for every repository/package but I try to use
the names of the files in each particular repository, to make things more
engaging and actionable for each individual package maintainer.

Note that the command log-edit-save-comment is also used in code twice,
so the cost of making it a command is just the line " (interactive)".
If you feel this command is not useful enough to receive a default key
bindings, we can drop that, but the interactive form should remain.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Fri, 24 Jan 2025 18:50:59 +0000

Hello,

On Sun 05 Jan 2025 at 12:37pm +01, Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Note that the command log-edit-save-comment is also used in code twice,
> so the cost of making it a command is just the line " (interactive)".
> If you feel this command is not useful enough to receive a default key
> bindings, we can drop that, but the interactive form should remain.

I would like to drop the default binding for now, but keep the command.

I have a couple of questions about the rest of the patch:

- I don't think Log Edit buffers ever contain commented lines or
  scissors lines at present.  So I'm not sure why you included that
  functionality.  Is it because you want to reuse this function in the
  hypothetical simplified git-commit-mode?

- I think some people might prefer not to have their half-written
  comment saved.  What do you think about doing everything in entries in
  log-edit-save-comment-hook, so that someone could customise that to
  remove the default behaviour, if they wanted?  Or perhaps a simple
  boolean defcustom to turn this new behaviour on and off.

-- 
Sean Whitton

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Thu, 13 Feb 2025 01:48:08 -0800

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> - I think some people might prefer not to have their half-written
>   comment saved.  What do you think about doing everything in entries in
>   log-edit-save-comment-hook, so that someone could customise that to
>   remove the default behaviour, if they wanted?  Or perhaps a simple
>   boolean defcustom to turn this new behaviour on and off.

What would be the use case for not saving it?  IIUC, this is anyways
just saved in memory, so is there any real drawback to just keeping it
there?  If you don't care, you don't care, so to speak.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Fri, 14 Feb 2025 07:36:53 +0800

Hello,

On Thu 13 Feb 2025 at 01:48am -08, Stefan Kangas wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> - I think some people might prefer not to have their half-written
>>   comment saved.  What do you think about doing everything in entries in
>>   log-edit-save-comment-hook, so that someone could customise that to
>>   remove the default behaviour, if they wanted?  Or perhaps a simple
>>   boolean defcustom to turn this new behaviour on and off.
>
> What would be the use case for not saving it?  IIUC, this is anyways
> just saved in memory, so is there any real drawback to just keeping it
> there?  If you don't care, you don't care, so to speak.

If M-p unexpectedly scrolls you into your half-finished comment instead
of into one you expect, you might hit C-c C-c before you realise and
create a broken commit.

I think sometimes one knows what the latest entry of one's comment ring
is (e.g. when you know you *just* cancelled a commit) and so it would be
jarring if M-p produced something else.

-- 
Sean Whitton

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Eli Zaretskii <eliz <at> gnu.org>,
 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Fri, 14 Feb 2025 20:54:42 +0100

> - I don't think Log Edit buffers ever contain commented lines or
>   scissors lines at present.

When you use "git commit" instead of "git commit -m "the message that
was prepared earlier", then Git inserts useful information into the
COMMIT_EDITMSG (or similar) file.

>   So I'm not sure why you included that
>   functionality.  Is it because you want to reuse this function in the
>   hypothetical simplified git-commit-mode?

Magit has been wrapping these functions for many years.  That's
perfectly fine for our needs and I am happy to continue to do so.  But
there was some interest in adding "git-commit.el" or parts thereof to
Emacs.  I figured this was the easiest and least controversial part to
integrate, so I started with that.

Even if this is merged as-is, that is not going to make it easier to
provide this functionality in Magit; it will have to continue to support
older Emacs releases for many years, so it will have to continue to keep
the wrapper code, but only for older releases.  That's going to make it
harder, not easier, for me.

I.e., I suggested this functionality because I though it would be
considered a clear improvement.  If that is not the case, that is okay
with me, and Magit will just keep doing what it has been doing.  If you
want to improve/change the proposed patch, please feel free to do so.
I hope that if/when you do, I can continue to wrap log-edit's functions
as I do now, but if I instead have to copy the implementations from an
older release and then modify that, I'll have to live with that.

> - I think some people might prefer not to have their half-written
>   comment saved.  What do you think about doing everything in entries in
>   log-edit-save-comment-hook, so that someone could customise that to
>   remove the default behaviour, if they wanted?  Or perhaps a simple
>   boolean defcustom to turn this new behaviour on and off.

So far no Magit user has asked me to add that, but if you want to
proactively add that in Emacs' implementation, please do.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75355 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sun, 23 Feb 2025 05:43:56 +0000

Jonas Bernoulli <jonas <at> bernoul.li> writes:

>> - I don't think Log Edit buffers ever contain commented lines or
>>   scissors lines at present.
>
> When you use "git commit" instead of "git commit -m "the message that
> was prepared earlier", then Git inserts useful information into the
> COMMIT_EDITMSG (or similar) file.
>
>>   So I'm not sure why you included that
>>   functionality.  Is it because you want to reuse this function in the
>>   hypothetical simplified git-commit-mode?
>
> Magit has been wrapping these functions for many years.  That's
> perfectly fine for our needs and I am happy to continue to do so.  But
> there was some interest in adding "git-commit.el" or parts thereof to
> Emacs.  I figured this was the easiest and least controversial part to
> integrate, so I started with that.
>
> Even if this is merged as-is, that is not going to make it easier to
> provide this functionality in Magit; it will have to continue to support
> older Emacs releases for many years, so it will have to continue to keep
> the wrapper code, but only for older releases.  That's going to make it
> harder, not easier, for me.
>
> I.e., I suggested this functionality because I though it would be
> considered a clear improvement.  If that is not the case, that is okay
> with me, and Magit will just keep doing what it has been doing.  If you
> want to improve/change the proposed patch, please feel free to do so.
> I hope that if/when you do, I can continue to wrap log-edit's functions
> as I do now, but if I instead have to copy the implementations from an
> older release and then modify that, I'll have to live with that.
>
>> - I think some people might prefer not to have their half-written
>>   comment saved.  What do you think about doing everything in entries in
>>   log-edit-save-comment-hook, so that someone could customise that to
>>   remove the default behaviour, if they wanted?  Or perhaps a simple
>>   boolean defcustom to turn this new behaviour on and off.
>
> So far no Magit user has asked me to add that, but if you want to
> proactively add that in Emacs' implementation, please do.

No further comments within one week.  Does that mean to say that any
remaining concerns have been addressed, and that we can therefore
install this change?  Or is there more to discuss here?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sun, 23 Feb 2025 15:10:54 +0800

Hello,

On Sun 23 Feb 2025 at 05:43am GMT, Stefan Kangas wrote:

> No further comments within one week.  Does that mean to say that any
> remaining concerns have been addressed, and that we can therefore
> install this change?  Or is there more to discuss here?

I have a TODO to work through Jonas's message soon.  Please allow me
some more time.

-- 
Sean Whitton

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Thu, 06 Mar 2025 12:27:43 +0800

Hello Jonas,

I took another look at this.  Sorry for the delay.
I don't think that we should install the patch as-is.

- I now agree with adding a default binding, but let's just rebind
  C-x C-s, like how C-x C-s in Gnus messages is rebound to save a draft?

  If the user wants to write our their log entry to a file, C-x C-w
  remains available to do that.

  I think though that we should bind log-edit-remember-comment, not
  log-edit-save-comment -- see below.

- I think the code in log-edit-buffer-comment is too Git-specific to go
  in log-edit.el.

- On the other hand, the changes to log-edit-previous-comment are more
  general, and I think we should install those.

- There is already log-edit-remember-comment.  It seems like some or all
  of your log-edit-save-comment should be integrated into
  log-edit-remember-comment.

How does this sound?

-- 
Sean Whitton

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sat, 08 Mar 2025 03:00:41 +0100

Hello Sean,

> - I now agree with adding a default binding, but let's just rebind
>   C-x C-s, like how C-x C-s in Gnus messages is rebound to save a
>   draft?

I think I used C-c C-s, both here and in Magit, because all the other
log-edit/git-commit commands, which use a prefix, use this prefix.
Since log-edit did not have a binding for this until now, it is a
good time to reconsider the binding.

> - I think the code in log-edit-buffer-comment is too Git-specific to go
>   in log-edit.el.

It would be a good idea to add a dedicated function.  It doesn't have to
do the proposed git-specific things, but it would be nice to be able to
provide one's own implementation, using an override advice.  You could
add a log-edit-buffer-comment-function option, but that would probably
be overkill until we know that there are users who actually want to
override the default.

> - On the other hand, the changes to log-edit-previous-comment are more
>   general, and I think we should install those.

Yay! ;D

> - There is already log-edit-remember-comment.  It seems like some or all
>   of your log-edit-save-comment should be integrated into
>   log-edit-remember-comment.

I did not notice this command exists; probably I only searched for
"save", not also "remember" or any other synonym.  Yes, it makes more
sense to replace the current implementation, instead of adding a new
implementation under a new name.

> How does this sound?

Sounds reasonable.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 75355 <at> debbugs.gnu.org
Subject: Re: bug#75355: [PATCH 1/1] Improve comment cycling in log-edit
Date: Sat, 08 Mar 2025 10:31:21 +0800

Hello,

On Sat 08 Mar 2025 at 03:00am +01, Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> It would be a good idea to add a dedicated function.  It doesn't have to
> do the proposed git-specific things, but it would be nice to be able to
> provide one's own implementation, using an override advice.  You could
> add a log-edit-buffer-comment-function option, but that would probably
> be overkill until we know that there are users who actually want to
> override the default.

Cool.  I would suggest you revise and we install your other changes
first and come back to this.

-- 
Sean Whitton

Previous Next

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