[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39504: 27.0.60; [PATCH] eww/shr: Ensure faces of enclosing elements
Kévin Le Gouguec
bug#39504: 27.0.60; [PATCH] eww/shr: Ensure faces of enclosing elements apply to <code> elements
Fri, 21 Feb 2020 19:46:11 +0100
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Lars Ingebrigtsen <address@hidden> writes:
>> Speaking of cosmetic issues, how did you apply my patch?
> I did it by hand since there were two patches in the email and the `M-m'
> command in debbugs-gnu (which does all this applying and marking with
> bug numbers automatically) doesn't like that.
Thanks! I didn't know about debbugs-gnu's M-m.
FWIW, "| git am RET" with point on the attachment actually *does* TRT
(so long as you're happy with the contributor's message).
(Sorry for my earlier ramblings; while "git am $file" chokes on the
leading '>', "git am < $file" digests it just fine.)
I've cobbled up a function to apply "git am" on the attachment at point
and let the committer optionally amend the message. Does that look
(defun debbugs-gnu-am ()
(gnus-mime-pipe-part "git am")
(vc-checkin nil 'Git)
;; log-edit-done eventually errors out if vc-parent-buffer is not a
;; file-visiting buffer.
(setq-local vc-parent-buffer (find-file-noselect "CONTRIBUTE")))
- the vc-parent-buffer hack is ugly,
- this does not fill the *log-edit-files* buffer,
- this does none of the careful window placement debbugs-gnu-apply-patch
takes care of.
 If default-directory is set to the root of the Emacs repository, but
a cursory glance at debbugs-gnu-apply-patch gives me the feeling
that it's also true there?