Re: right clicking on URL in emacs-w3m vs. gnus

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 21 Apr 2010 15:08:26 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Ted Zlatanov wrote:
>> On Sun, 18 Apr 2010 06:41:23 +0800 jidanni@jidanni.org wrote:

j> In emacs-w3m, right clicking on a link brings up a menu with lots of choices.
j> However doing the same action inside gnus doesn't.

j> E.g., try right clicking on http://example.org/ .

>> This is composed of two things actually:

>> 1) the emacs-w3m popup menu should be accessible in the Article buffer.
>> Currently it can be invoked with (w3m-mouse-major-mode-menu EVENT) so it
>> *can* be bound to right-click in the article mode by the user.  This
>> part is pretty easy.

>> 2) right-click on a URL should bring up that menu.  I'm not sure if
>> there are any other logical things to hang on right-click in Gnus.  For
>> instance we could bring up the Treatment or Commands menus that are
>> otherwise in the pulldown.  So maybe the emacs-w3m menu should be under
>> the main popup menu in the article buffer, and it should also show up in
>> the menu bar when the article buffer is using emacs-w3m.

>> Any opinions?

KY> I don't know what items the menu should provide but I tried hacking
KY> it as attached below.  Currently the right-click pops up this menu:

KY> ,----
KY> | Open this link with
KY> | ===================
KY> | browse-url
KY> | emacs-w3m
KY> `----

KY> (The first item overlaps to the middle-click though.)

Maybe Treatment, Article, and Commands should precede the w3m menu, and
they should always show up on a right-click?

Can we also hang the w3m menu in the menubar when HTML is rendered in
the article buffer?

I'm OK with any changes you think are appropriate here, these are just
suggestions.

You could make a "yamaoka-dev" branch and push it with any proposed
changes instead of a patch (the commit e-mail will still go out and we
can see your changes in the e-mail). Then we can try the feature
(collaboratively making changes to yamaoka-dev in the process) and merge
it into the master branch when it's ready and you can then delete
yamaoka-dev.  I don't know if that's the right model for us so feel free
to propose something else if you think it's better.

Ted