[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57400: 29.0.50; Support sending patches from VC directly
From: |
Philip Kaludercic |
Subject: |
bug#57400: 29.0.50; Support sending patches from VC directly |
Date: |
Thu, 06 Oct 2022 12:38:25 +0000 |
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Wed, 05 Oct 2022 17:34:22 +0000, Philip Kaludercic
> <philipk@posteo.net> said:
>
> Philip> +@code{vc-prepare-patch} command. This will prompt you
> Philip> which revisions
> Philip> +you wish to share and who the addressee is. The command
> Philip> will then use
> Philip> +your @abbr{MUA, Mail User Agent} for you to review and send out.
> Philip> +
>
> How about
>
> --begin--
> This will prompt you for the revisions you wish to share, and which
> destination email address(es) to use. The command will then prepare
> those revisions using your @abbr{MUA, Mail User Agent} for you to
> review and send.
> --end--
I like it.
> The semantics is 'one-or-more addresses', right?
Yes, right.
> Philip> +@vindex vc-prepare-patches-inline
> Philip> +Depending on configuration of the user option
>
> "Depending on the value of the user option"
Sounds better.
> Philip> +@code{vc-prepare-patches-inline}, @code{vc-prepare-patch}
> Philip> will either
> Philip> +generate a single or multiple messages. A @code{nil}
> Philip> value (the default)
> Philip> +will prepare and display a message for each revision, one after
> Philip> +another. A non-@code{nil} value will have all patches
> Philip> attached to the
> Philip> +body of a single message.
> Philip> +
>
> --begin--
> @code{vc-prepare-patches-inline}, @code{vc-prepare-patch} will
> generate one or more messages. The default value @code{nil} means
> prepare and display a message for each revision, one after another. A
> non-@code{nil} value means to generate a single message with all
> patches attached in the body.
> --end--
Sounds a lot better.
> Philip> +@vindex vc-default-patch-addressee
> Philip> +If you expect to contribute patches on a regular basis, you can
> set
> Philip> +the user option @code{vc-default-patch-addressee} to the address
> you
> Philip> +wish to use. This will be used as the default value when
> invoking
> Philip> +@code{vc-prepare-patch}. Project maintainers may consider
> setting
> Philip> +this as a directory local variable (@pxref{Directory Variables}).
> Philip> +
>
> This can contain multiple addresses, I think, in which case it should
> say so.
Would replacing "address" with "address(es)" suffice?
> Philip> +** Subr-x
> Philip> +
> Philip> +---
> Philip> +*** New macro 'with-funcall-substitutions'.
> Philip> +The macro can be used to generically substitute function symbols
> in
> Philip> +expressions.
> Philip> +
> Philip> ** Ansi-color
>
> That sounds interesting, but I donʼt see it in the patch :-)
As mentioned in another response, this is from a different patch I hope
to submit soon. I just had it lying around in etc/NEWS.
> Philip> +(defcustom vc-prepare-patches-inline nil
> Philip> + "Non-nil means that `vc-prepare-patch' creates a single
> Philip> message.
>
> "Whether `vc-prepare-patch' attaches all revision in a single message."
>
> Iʼm not sure this should have the suffix '-inline', because you can
> have inline attachments and attached attachments, but itʼs not a big
> deal.
If you have a better name, there is no better time to change it than now.
> I also wonder about the default. Creating 100 mail buffers by accident
> is harder to recover from than a single one with 100 attachments, but
> I guess experience will inform us.
The only case where this might happen by accident is when someone
invokes `vc-prepare-patch' in a log-edit buffer where all (or at least a
lot) of revisions have been marked. In that case, one could add a
"safely check" and make sure that the user actually wants to proceed.
> Philip> +A single message is created by attaching all patches to the body
> Philip> +of a single message. If nil, each patch will be sent out in a
> Philip> +separate message, which will be prepared sequentially."
> Philip> + :type 'boolean
> Philip> + :safe #'booleanp
> Philip> + :version "29.1")
> Philip> +
>
> (I didnʼt check, can this do the [PATCH n/m] stuff with the
> subject that 'git format-patch' can do?)
Yes, as the Git backend just copies the subject name that
git-format-patch generates.
> Philip> +(defcustom vc-default-patch-addressee nil
> Philip> + "Default addressee for `vc-prepare-patch'.
> Philip> +If nil, no default will be used. This option may be set
> locally."
> Philip> + :type '(choice (const :tag "No default" nil) string)
> Philip> + :safe #'stringp
> Philip> + :version "29.1")
> Philip> +
>
> Again, I think this can be multiple addresses. Either as a string
> with commas or as a list of strings perhaps?
As this is just the default value for `read-multiple-choice' a list with
commae should do. That being said, how common is it to have multiple
people you consistently want to send a patch to? Usually you'd have a
central mailing list or something like that, I'd assume.
> Philip> +;;;###autoload
> Philip> +(defun vc-prepare-patch (addressee subject revisions)
> Philip> + "Compose an Email sending patches for REVISIONS to ADDRESSEE.
> Philip> +If `vc-prepare-patches-inline' is non-nil, SUBJECT will be used
> Philip> +as the default subject for the message. Otherwise a separate
> Philip> +message will be composed for each revision.
> Philip> +
>
> ? What does `vc-prepare-patches-inline' have to do with the SUBJECT?
Because the subject for an "inline patch" is extracted from the commit
message.
> Philip> It includes
>
> Philip> - some documentation for the Emacs manual and etc/NEWS,
>
> Philip> - a revised "prepare-patch" interface that uses buffers instead of
> Philip> temporary files (I hope this improves the encoding issue),
>
> If itʼs all buffers now then I think you need to update this comment:
>
> +;;
> +;; - prepare-patch (rev)
> +;;
> +;; Prepare a patch and return a property list with the keys
> +;; `:subject' indicating the patch message as a string, `:body'
> +;; containing the contents of the patch as a string (excluding the
> +;; header) and `:filename' pointing to a file where the patch has
> +;; been stored.
You are right, thanks for the reminder!
> I have no firm opinion on if there should be a default binding nor
> what it should be 😺
>
> Thanks for this, it will be useful
I'm glad to hear that. Here is the updated patch:
0001-Add-a-VC-command-to-prepare-patches.patch
Description: Text Data
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- bug#57400: 29.0.50; Support sending patches from VC directly, Lars Ingebrigtsen, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Richard Stallman, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly,
Philip Kaludercic <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/09