From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#57400: 29.0.50; Support sending patches from VC directly Date: Tue, 04 Oct 2022 07:10:15 +0000 Message-ID: <87a66cukrs.fsf@posteo.net> References: <84v8qgn1z9.fsf@iki.fi> <87h71zo3p8.fsf@posteo.net> <87sfljmgwz.fsf@posteo.net> <87y1twvima.fsf@posteo.net> <878rlw681a.fsf@gnus.org> <87r0zovbzr.fsf@posteo.net> <87mtacvag8.fsf@posteo.net> <83r0zow0nl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2208"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 57400@debbugs.gnu.org, ane@iki.fi To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 04 09:26:48 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ofcKF-0000Q8-H1 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Oct 2022 09:26:47 +0200 Original-Received: from localhost ([::1]:60264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofcKE-0002lu-DX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Oct 2022 03:26:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofc50-0001ap-5C for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 03:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53146) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofc4z-00014T-TR for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 03:11:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ofc4z-0004J9-JQ for bug-gnu-emacs@gnu.org; Tue, 04 Oct 2022 03:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Oct 2022 07:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57400 X-GNU-PR-Package: emacs Original-Received: via spool by 57400-submit@debbugs.gnu.org id=B57400.166486742416501 (code B ref 57400); Tue, 04 Oct 2022 07:11:01 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 4 Oct 2022 07:10:24 +0000 Original-Received: from localhost ([127.0.0.1]:52223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofc4O-0004I3-0n for submit@debbugs.gnu.org; Tue, 04 Oct 2022 03:10:24 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:55053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofc4M-0004Hg-81 for 57400@debbugs.gnu.org; Tue, 04 Oct 2022 03:10:23 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B8929240027 for <57400@debbugs.gnu.org>; Tue, 4 Oct 2022 09:10:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1664867416; bh=o9yfTlKK+/o+2dEUe2Zni0tVnlDep0SMAIlzD2iJj2c=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=UNHhSqG6f+oChqOx7r3pD3LRy1WFfL99MnqblyxDrrDBX5Lr1upjQMyRA3t0X1/q8 /8iisR0sdpmaI0dC0y/TSQ9tycTWK6uuAweSEdciCQfvDCsyQkeLu2iA9FWx4Lu5g6 KO5MbHutm1+bZshbSsu9lS7VVWaxkhZ1hGoW5Vbc125nUhJR9ZI1yJMvZg9BjfLO+1 f9Bt8fs6nfgUxd0f9uIKLdiF+jxHd+gFZEDDSYnzll7wgZewwC0dVQi6rlUTw4PWQe 0XLoJZCnZuZYhRoo//PZtKaXAB+lHTLf9LceP9AGh+iXtK1DZtTeb1+VIEP0wJyo6g n6yH1TpNl8lEg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MhTP333wPz6tmN; Tue, 4 Oct 2022 09:10:15 +0200 (CEST) In-Reply-To: <83r0zow0nl.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Oct 2022 09:41:50 +0300") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244369 Archived-At: Eli Zaretskii writes: >> Cc: 57400@debbugs.gnu.org, Antoine Kalmbach >> From: Philip Kaludercic >> Date: Mon, 03 Oct 2022 21:55:35 +0000 >> >> >> Others should indeed run vc-diff, I >> >> think. >> > >> > That seem possible, but for that to work I will need a generic way to >> > detect the predecessor of a commit and extract a commit message. >> > Currently, I am not sure if this can be done. >> >> I had forgotten about `previous-revision', so that was easy and I >> decided to fall back to a generic subject as that can be easily revised: > > Thanks. A few comments below. > >> +(defun vc-git-prepare-patch (rev) >> + (with-temp-buffer >> + (call-process vc-git-program nil t nil "format-patch" >> + "--no-numbered" "--stdout" >> + ;; From gitrevisions(7): ^ means the th parent >> + ;; (i.e. ^ is equivalent to ^1). As a >> + ;; special rule, ^0 means the commit itself and >> + ;; is used when is the object name of a tag >> + ;; object that refers to a commit object. >> + (concat rev "^0")) > > This needs to set up decoding of the stuff Git outputs, because it is > usually in UTF-8 (but could be in some other encoding), and the > defaults could be different, depending on the locale. See > vc-git-log-output-coding-system and its use elsewhere. > > Or maybe you should just use vc-git--call here, which handles that > already, and uses process-file instead of call-process, so this will > work via Tramp: an additional benefit. I will look into this. >> + (let (filename subject body) >> + ;; Save the patch in a temporary file if required >> + (when (bound-and-true-p vc-compose-patches-inline) >> + (setq filename (make-temp-file "vc-git-prepare-patch")) >> + (write-region nil nil filename)) ;FIXME: Clean up > > By "clean up" did you mean delete the temporary file? Yes. Another idea was to create buffers and attach those, but I still haven't decided which is preferable. >> + ;; Return the extracted data >> + (list :filename filename >> + :subject subject >> + :body body)))) > > I think this should include :encoding ENCODING, to provide the > temporary file's encoding to the caller. The encoding should be the > same as buffer-file-coding-system in the buffer which you write above. OK. >> -(defun vc-read-revision (prompt &optional files backend default initial-input) >> +(defun vc-read-revision (prompt &optional files backend default initial-input multiple) > > This API change warrants a NEWS entry, I think. More NEWS entries that just this one will be necessary. >> (cond >> ((null files) >> (let ((vc-fileset (vc-deduce-fileset t))) ;FIXME: why t? --Stef >> @@ -1920,9 +1928,16 @@ vc-read-revision >> (let ((completion-table >> (vc-call-backend backend 'revision-completion-table files))) >> (if completion-table >> - (completing-read prompt completion-table >> - nil nil initial-input 'vc-revision-history default) >> - (read-string prompt initial-input nil default)))) >> + (funcall >> + (if multiple #'completing-read-multiple #'completing-read) >> + prompt completion-table nil nil initial-input 'vc-revision-history default) >> + (let ((answer (read-string prompt initial-input nil default))) >> + (if multiple >> + (split-string answer "[ \t]*,[ \t]*") >> + answer))))) >> + >> +(defun vc-read-multiple-revisions (prompt &optional files backend default initial-input) >> + (vc-read-revision prompt files backend default initial-input t)) >> >> (defun vc-diff-build-argument-list-internal (&optional fileset) >> "Build argument list for calling internal diff functions." >> @@ -3243,6 +3258,73 @@ vc-update-change-log >> (vc-call-backend (vc-responsible-backend default-directory) >> 'update-changelog args)) >> >> +(defcustom vc-compose-patches-inline nil >> + "Non-nil means that `vc-compose-patch' creates a single message." > > This is rather cryptic, IMO, and will benefit from more detailed > description, after the initial line. Also, I suggest a slight > rewording of the above sentence: > > If non-nil, `vc-compose-patch' will create a single email message. You are right, the docstring was just a temporary fill-in so that I could specify the following user option attributes. It has to be expanded anyway. >> + :type 'boolean >> + :safe #'booleanp) > > The :version tag is missing. Thanks for the reminder. >> +(declare-function message-goto-body "message" (&optional interactive)) >> +(declare-function message--name-table "message" (orig-string)) > > Can we not force the use of message.el? Can we use mail-user-agent > instead, and use its properties to find out the compose function the > user has set up, like "C-x m" does? This would probably eliminate > quite a few problems with user email setup, which might not support > message.el. I'd like to avoid that if possible, but I don't see how. >> +(defun vc-compose-patch (addressee subject revisions) >> + "Compose a message sending REVISIONS to ADDRESSEE with SUBJECT." > > "Compose an email message to send REVISIONS to ADDRESSEE with SUBJECT." > > The "email" part is important, because we cannot assume the reader of > the doc string is necessarily aware of the context. Good point. >> + (interactive (save-current-buffer >> + (require 'message) >> + (vc-ensure-vc-buffer) >> + (let ((revs (vc-read-multiple-revisions "Revisions: ")) to) >> + (while (null (setq to (completing-read-multiple >> + "Whom to send: " > > Instead "Whom to send:" I suggest just "Addressee:" or maybe even > "Send patches to:" You are right, that sounds better. >> + (compose-mail addressee >> + (or (plist-get patch :subject) >> + (concat >> + "Patch for " ;guess >> + (file-name-nondirectory >> + (directory-file-name >> + (vc-root-dir))))) >> + nil nil nil nil >> + `((exit-recursive-edit))) >> + (message-goto-body) > > compose-mail doesn't necessarily invoke message.el functions, so > message-goto-body is not necessarily appropriate here. Oh, I thought it was because `submit-emacs-patch' did the same. Again, do you have any suggestions what else could be done to keep this generic?