[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57400: 29.0.50; Support sending patches from VC directly
From: |
Juri Linkov |
Subject: |
bug#57400: 29.0.50; Support sending patches from VC directly |
Date: |
Mon, 10 Oct 2022 22:03:11 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) |
> Again, regarding `crm-separator' I don't know if this is a value that
> people change or not (perhaps it should be changed to a defconst).
At least, it's not defcustom, so it's not intended for user customization.
> I can also imagine that the initial input outside of a log buffer ought
> to just be the last commit.
Depends on whether this is one of the most popular workflows.
>> Additional question: shouldn't the behavior of
>> vc-prepare-patches-separately=nil be equivalent to
>> vc-prepare-patches-separately=t when only one revision is given? Both
>> cases create just one mail. So when vc-prepare-patches-separately is
>> nil, could it extract the subject from the single revision? Or maybe
>> vc-prepare-patches-separately should support a new customization value
>> for this?
>
> Yes, but the formatting is different. In the one case you attach a
> patch to a regular message, while in the other case the message is
> prepared in such a way that (at least when using Git) the entire message
> is a valid patch, where we can use "git am".
Hmm, I tried both variants, and still not sure which is better
for the 1-patch case. However, what I definitely suggest to do is
to get rid of recursive-edit, that also Robert noticed on emacs-devel.
recursive-edit is too fragile for modal editing, because such
commands as keyboard-escape-quit can easily break it. Without
recursive-edit you can just create all mail buffers at once.
Then after sending one mail, its buffer gets buried, and the
next mail buffer will be shown instead, etc.
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- 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
- bug#57400: 29.0.50; Support sending patches from VC directly,
Juri Linkov <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/11
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/11
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/15
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/16
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/11
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/11
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/11
- bug#57400: 29.0.50; Support sending patches from VC directly, Richard Stallman, 2022/10/12
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/13
- bug#57400: 29.0.50; Support sending patches from VC directly, Richard Stallman, 2022/10/13