bug#12396: 24.2.50; [PATCH] extend usability of gnus-read-ephemeral-emacs-bug-group

[Juri Linkov]

>> It makes sense, but it's kinda not the way these function in Emacs
>> usually work.  `M-x find-file-at-point', `M-x man', etc, all react to
>> the thing under point.  And that's a very self-evident user interface.
>> Put point at the thing you're interested in, and then issue a command.
>
> I was annoyed enough times by having to navigate to the bug number to
> avoid typing it in that I decided to code up a way to avoid having to do
> that; having it in Emacs might spare others such annoyance. :-)

I agree with Lars that getting a default value from distant parts
of the buffer is non-standard behavior for thing-at-point.
It might cause more annoyance when it will do not what the user expects.
For instance, if it will get a bug number far away from point, then
the user might expect that it will also get a bug number on the next line
at the same column position, etc.  IOW, I don't oppose such a change
only if its logic would be simple and intuitive to users.

Also moving argument reading out of the `interactive' specification
in `gnus-read-ephemeral-emacs-bug-group' is a change for the worse.

However, I think that the second part of your proposal is very useful.

Do you think `bug-reference-push-button-action' can be a function?
So users could set it to `browse-url' or `gnus-read-ephemeral-emacs-bug-group'
(these values still need const tags like in your patch)
or any other function.  Also I wonder why you don't call
`gnus-read-ephemeral-emacs-bug-group' with a bug number argument
so users don't need to confirm it with RET.

BTW, bug-reference.el could be improved to support also links
to revision numbers like "revno:109985" that opens an URL like
http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/109985