bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

I've started using `debbugs-gnu-apply-patch' regularly, and find it
enormously useful -- it's particularly nice that it handles both inline
patches and attachments.

I don't love the automatic compilation step, though. I pretty much never
want to go straight to compilation; it is very long; and the windows are
a mess until it finishes. Even the magit/vc step afterwards is often not
what I want, as I have Magit already open on Emacs somewhere else.

How about some sort of custom option to control this? Either
specifically compile-after-apply, or maybe a list of post-apply-actions,
something like that?

Thanks,
Eric

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

Hi Eric,

> I've started using `debbugs-gnu-apply-patch' regularly, and find it
> enormously useful -- it's particularly nice that it handles both inline
> patches and attachments.
>
> I don't love the automatic compilation step, though. I pretty much never
> want to go straight to compilation; it is very long; and the windows are
> a mess until it finishes. Even the magit/vc step afterwards is often not
> what I want, as I have Magit already open on Emacs somewhere else.
>
> How about some sort of custom option to control this? Either
> specifically compile-after-apply, or maybe a list of post-apply-actions,
> something like that?

I don't use `debbugs-gnu-apply-patch' by myself, so I have no opinion
about. It was written by Lars for his own workflow.

No objections from my side, if you make some optional changes. And
please document them in debbugs-ug.texi.

> Thanks,
> Eric

Best regards, Michael.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

On 02/10/24 19:54 PM, Michael Albinus wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>> I've started using `debbugs-gnu-apply-patch' regularly, and find it
>> enormously useful -- it's particularly nice that it handles both inline
>> patches and attachments.
>>
>> I don't love the automatic compilation step, though. I pretty much never
>> want to go straight to compilation; it is very long; and the windows are
>> a mess until it finishes. Even the magit/vc step afterwards is often not
>> what I want, as I have Magit already open on Emacs somewhere else.
>>
>> How about some sort of custom option to control this? Either
>> specifically compile-after-apply, or maybe a list of post-apply-actions,
>> something like that?
>
> I don't use `debbugs-gnu-apply-patch' by myself, so I have no opinion
> about. It was written by Lars for his own workflow.

Out of curiosity, do you use any convenience functions for applying
patches from email->repository?

> No objections from my side, if you make some optional changes. And
> please document them in debbugs-ug.texi.

Okay! Thanks. I have a quick question: the :version tags on the
defcustoms in debbug-gnu.el all seem to refer to Emacs versions,
shouldn't they refer to debbugs package versions? Or is this also a Lars
thing?

Thanks,
Eric

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eli Zaretskii]

> Cc: 69017@debbugs.gnu.org
> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 10 Feb 2024 11:23:30 -0800
> 
> Out of curiosity, do you use any convenience functions for applying
> patches from email->repository?

I use M-|, FWIW.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 69017@debbugs.gnu.org
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sat, 10 Feb 2024 11:23:30 -0800
>> 
>> Out of curiosity, do you use any convenience functions for applying
>> patches from email->repository?
>
> I use M-|, FWIW.

That's what I was trying to avoid! You're the one who has to handle
attachments vs inline, type out the directory location, decide between
"git am" and "git apply", etc...

If you're doing it 50 times a day, maybe the muscle memory (or command
history) means it's not a big deal.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: michael.albinus@gmx.de,  69017@debbugs.gnu.org
> Date: Sat, 10 Feb 2024 11:58:56 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: 69017@debbugs.gnu.org
> >> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> >> Date: Sat, 10 Feb 2024 11:23:30 -0800
> >> 
> >> Out of curiosity, do you use any convenience functions for applying
> >> patches from email->repository?
> >
> > I use M-|, FWIW.
> 
> That's what I was trying to avoid! You're the one who has to handle
> attachments vs inline, type out the directory location, decide between
> "git am" and "git apply", etc...
> 
> If you're doing it 50 times a day, maybe the muscle memory (or command
> history) means it's not a big deal.

Emacs remembers the command history, so all I have to do is press <UP>
a few times, after I type M-|, then type RET.

And some figuring out is still up to you, because patches could be for
the release branch or for the master (and maybe for a few more
branches), so you'd need some "cd foo" before "git am".  I have a
command for master and for the release branch, and I need to decide
which one to use in each case.  That cannot be automated.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: michael.albinus@gmx.de,  69017@debbugs.gnu.org
>> Date: Sat, 10 Feb 2024 11:58:56 -0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Cc: 69017@debbugs.gnu.org
>> >> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> >> Date: Sat, 10 Feb 2024 11:23:30 -0800
>> >> 
>> >> Out of curiosity, do you use any convenience functions for applying
>> >> patches from email->repository?
>> >
>> > I use M-|, FWIW.
>> 
>> That's what I was trying to avoid! You're the one who has to handle
>> attachments vs inline, type out the directory location, decide between
>> "git am" and "git apply", etc...
>> 
>> If you're doing it 50 times a day, maybe the muscle memory (or command
>> history) means it's not a big deal.
>
> Emacs remembers the command history, so all I have to do is press <UP>
> a few times, after I type M-|, then type RET.
>
> And some figuring out is still up to you, because patches could be for
> the release branch or for the master (and maybe for a few more
> branches), so you'd need some "cd foo" before "git am".  I have a
> command for master and for the release branch, and I need to decide
> which one to use in each case.  That cannot be automated.

Yup, that makes plenty of sense. Your situation is more complicated than
mine, no surprise there!

I've attached the minimum workable approach, which just lets the user
set the compile command to nil to skip compilation, and the relevant
window rearrangements afterwards.

A fuller solution might be a "after-apply-patch-actions" option, that takes a
list like '(compile vc). That could obviate
`debbugs-gnu-apply-patch-prefers-magit' because you could just set the
list to '(compile magit) instead. But that would require a pretty
thorough reworking of the window munging code that comes at the end, and
I'd like to just keep this simple.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-compile-after-applying-a-patch-if-compile-comm.patch --]
[-- Type: text/x-patch, Size: 1877 bytes --]

From 861d000d35f8ed90ed47ce7cff980157d1329408 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sat, 10 Feb 2024 12:38:31 -0800
Subject: [PATCH] Don't compile after applying a patch, if compile command is
 nil

* debbugs-gnu.el (debbugs-gnu-apply-patch): Allow the user to set
debbugs-gnu-compile-command to nil to skip the compile step.
---
 debbugs-gnu.el | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/debbugs-gnu.el b/debbugs-gnu.el
index a5453334cd..f4f1fce7da 100644
--- a/debbugs-gnu.el
+++ b/debbugs-gnu.el
@@ -2612,12 +2612,13 @@ If SELECTIVELY, query the user before applying the patch."
       (insert-file-contents-literally rej))
     (goto-char (point-max))
     (save-some-buffers t)
-    (require 'compile)
-    (mapc #'kill-process compilation-in-progress)
-    (compile
-     (format "cd %s; %s"
-	     debbugs-gnu-current-directory
-	     debbugs-gnu-compile-command))
+    (when debbugs-gnu-compile-command
+      (require 'compile)
+      (mapc #'kill-process compilation-in-progress)
+      (compile
+       (format "cd %s; %s"
+	       debbugs-gnu-current-directory
+	       debbugs-gnu-compile-command)))
     (let (buf)
       (if (debbugs-gnu-apply-patch-prefers-magit)
           (progn
@@ -2637,11 +2638,12 @@ If SELECTIVELY, query the user before applying the patch."
       (delete-other-windows)
       (switch-to-buffer output-buffer)
       (split-window)
-      (split-window)
-      (other-window 1)
-      (switch-to-buffer "*compilation*")
-      (goto-char (point-max))
-      (other-window 1)
+      (when debbugs-gnu-compile-command
+       (split-window)
+       (other-window 1)
+       (switch-to-buffer "*compilation*")
+       (goto-char (point-max))
+       (other-window 1))
       (switch-to-buffer buf)
       (goto-char (point-min)))))
 
-- 
2.43.0

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

Hi Eric,

> I've attached the minimum workable approach, which just lets the user
> set the compile command to nil to skip compilation, and the relevant
> window rearrangements afterwards.

Looks OK in general. You need to adapt the :type of
debbugs-gnu-compile-command, and also to add some few words about in
debbugs-ug.texi.

Best regards, Michael.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>> I've attached the minimum workable approach, which just lets the user
>> set the compile command to nil to skip compilation, and the relevant
>> window rearrangements afterwards.
>
> Looks OK in general. You need to adapt the :type of
> debbugs-gnu-compile-command, and also to add some few words about in
> debbugs-ug.texi.

Sounds good, I'll do those things and close this up later today. Thanks!

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

Hi Eric,

>> Looks OK in general. You need to adapt the :type of
>> debbugs-gnu-compile-command, and also to add some few words about in
>> debbugs-ug.texi.
>
> Sounds good, I'll do those things and close this up later today. Thanks!

If there's nothing else to do, you might also increase the version in
debbugs.el to 0.40.

Best regards, Michael.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>>> Looks OK in general. You need to adapt the :type of
>>> debbugs-gnu-compile-command, and also to add some few words about in
>>> debbugs-ug.texi.
>>
>> Sounds good, I'll do those things and close this up later today. Thanks!
>
> If there's nothing else to do, you might also increase the version in
> debbugs.el to 0.40.

Done! Thanks.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

Hi Eric,

>> I don't use `debbugs-gnu-apply-patch' by myself, so I have no opinion
>> about. It was written by Lars for his own workflow.
>
> Out of curiosity, do you use any convenience functions for applying
> patches from email->repository?

I stupidly use ediff-patch-file (Tools → Apply Patch → To a File...).
vc-specific operations I perform in a vc-dir buffer afterwards. That's it.

> I have a quick question: the :version tags on the
> defcustoms in debbug-gnu.el all seem to refer to Emacs versions,
> shouldn't they refer to debbugs package versions? Or is this also a Lars
> thing?

No, this is a Michael thing :-)

We could add :package-version tags to the defcustoms, I've been too lazy
until now.

> Thanks,
> Eric

Best regards, Michael.

bug#69017: 30.0.50; [debbugs] Make compilation step optional in debbugs-gnu-apply-patch

[Eric Abrahamsen]

Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>>> I don't use `debbugs-gnu-apply-patch' by myself, so I have no opinion
>>> about. It was written by Lars for his own workflow.
>>
>> Out of curiosity, do you use any convenience functions for applying
>> patches from email->repository?
>
> I stupidly use ediff-patch-file (Tools → Apply Patch → To a File...).
> vc-specific operations I perform in a vc-dir buffer afterwards. That's it.

It's becoming obvious that the real pros just do it by hand!

>> I have a quick question: the :version tags on the
>> defcustoms in debbug-gnu.el all seem to refer to Emacs versions,
>> shouldn't they refer to debbugs package versions? Or is this also a Lars
>> thing?
>
> No, this is a Michael thing :-)
>
> We could add :package-version tags to the defcustoms, I've been too lazy
> until now.

Actually it's also partially an Eric thing, I see that :version is
documented as specifically referring to Emacs versions. That seems not
very meaningful, but I'm also not trying to create extra work for anyone!