bug#59448: 29.0.50; URIs in Dictionary are not properly handled

[Gabriel]

Severity: wishlist

Description:

URIs (http, mail, news, ftp etc) in Dictionary are not properly handled.
It means that URIs are treated like a regular search phrase, which is
not really useful for `dictionary-search' (since most will not return
any results) and no default mechanism is available to follow such URIs.

Steps:

1) emacs -q (master "6b0179f7908c658342d1e642e5444e3d2e1cd997")

2) Run `dictionary-search' with some search word whose results contains
URIs in dict.org, for example:

  M-x dictionary-search RET emacs  RET
  M-x dictionary-search RET fsf    RET
  M-x dictionary-search RET w3c    RET
  M-x dictionary-search RET python RET
  M-x dictionary-search RET ruby   RET

Actual result: URIs are treated like a regular search phrase, in which
RET will execute `dictionary-new-search' will not find any results.

Compare with EWW behavior:

1) emacs -q (master "6b0179f7908c658342d1e642e5444e3d2e1cd997"

2) M-x eww RET

3) Search for some search word whose results contains URIs, for example:

  emacs
  fsf
  w3c
  python
  ruby

Actual result: despite some <a> tags seems to be broken, it's possible
to follow the links (e.g.: follow "http://python.org/"; when searching
for "python").

Alternative:

It seems that `goto-address-mode' can be enabled to help handling URIs
in Dictionary buffers, which will find some URI patterns (using
`goto-address-url-regexp' and `goto-address-mail-regexp'), allowing to
follow URLs and composing emails with C-c RET (`goto-address-at-point').
Perhaps `goto-address-at-point' can be enabled by default in
`dictionary-mode`?

Other alternative is to handle URIs natively in `dictionary-mode'.  For
example, some proper URI handling in the action of `dictionary-link'
button or in `dictionary-display-word-definition'.

Nevertheless, I believe the default behavior of Dictionary could be
improved, i.e., to avoid treating URIs as regular search words that will
provide little to none value to users (since it will mostly fail to find
results) and to provide a better integration with other Emacs features
(e.g.: EWW to browse URLs or Gnus to compose emails).

---
Gabriel