On Fri, 02 Dec 2016 21:26:20 -0500, npostavs@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.