GNU bug report logs - #25091
26.0.50; shr-map hides gnus-article keys

Previous Next

Package: emacs;

Reported by: Katsumi Yamaoka <yamaoka <at> jpl.org>

Date: Fri, 2 Dec 2016 09:10:01 UTC

Severity: normal

Tags: patch

Found in version 26.0.50

Done: Katsumi Yamaoka <yamaoka <at> jpl.org>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 25091 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: npostavs <at> users.sourceforge.net
Cc: 25091 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#25091: 26.0.50; shr-map hides gnus-article keys
Date: Mon, 05 Dec 2016 15:57:12 +0900
[Message part 1 (text/plain, inline)]
On Fri, 02 Dec 2016 21:26:20 -0500, npostavs <at> users.sourceforge.net wrote:
> There's a similar attempt in yasnippet to try use the original binding.
> It's generally been troublesome.

I realized it is not a coincidence that two TAB commands, one is
provided by `gnus-article-mode-map' and the other is provided by
`shr-map', behave similarly in the Gnus article buffer.  Why TAB
-- `widget-forward' -- moves the point to a shr link in addition
to attachment buttons is because Gnus adds widget buttons to shr
links purposely using `mm-convert-shr-links' (see mm-decode.el).
So, I believe it is natural to make `shr-next-link' behave like
`widget-forward' as well.  Furthermore, what should make it do so
should be `mm-convert-shr-links', not shr functions (as a patch
I posted first).  In other words, the command that TAB invokes
on a widget button added to a shr link should be `widget-forward',
not `shr-next-link'.

,---- background
| Normally TAB in the Gnus article buffer runs `widget-forward'
| that moves point to the next attachment button or a shr link.
| However, TAB on a shr link in the Gnus article buffer runs
| `shr-next-link' that moves point to only the next shr link.
| So is `shr-previous-link'.
`----

A new patch is below.

> I'm planning to switch it to use a conditional binding as described at [1].

> (define-key <map> <key>
>   `(menu-item "" <my-cmd> :filter ,(lambda (cmd) (if <my-predicate> cmd))))

> [1]: http://stackoverflow.com/questions/16090517/elisp-conditionally-change-keybinding/22863701#22863701

Thanks.  But this case seems to not necessarily be related.

[Message part 2 (text/x-patch, inline)]
--- mm-decode.el~	2016-07-25 23:45:06.237009600 +0000
+++ mm-decode.el	2016-12-05 06:55:13.007620000 +0000
@@ -1859,6 +1859,10 @@
 	(dolist (key (where-is-internal #'widget-button-click widget-keymap))
 	  (unless (lookup-key keymap key)
 	    (define-key keymap key #'ignore)))
+	;; Avoid `shr-next-link' and `shr-previous-link' so as to run
+	;; `widget-forward' and `widget-backward' instead.
+	(substitute-key-definition 'shr-next-link nil keymap)
+	(substitute-key-definition 'shr-previous-link nil keymap)
 	(dolist (overlay (overlays-at start))
 	  (overlay-put overlay 'face nil))
 	(setq start end)))))

This bug report was last modified 8 years and 163 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.