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

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

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

[Juri Linkov]

> 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.

Thanks for the bug reports (your posts about tab-line will be addressed soon too).

> 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).

Another alternative would be to fall back to handling URIs
only when dictionary-search fails to find a definition.
So instead of displaying the message "Word not found" it could
try to open the URI that can be found in the provided string.

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

[Gabriel]

Juri Linkov <juri@linkov.net> writes:
>
> Another alternative would be to fall back to handling URIs
> only when dictionary-search fails to find a definition.
> So instead of displaying the message "Word not found" it could
> try to open the URI that can be found in the provided string.

Hi Juri,

Yes, that's a good approach too, thank you!  I think the downsides of
this suggestion (in comparison to creating appropriate buttons for URIs
during the display of Dictionary results) are:

1) An unnecessary IO call to fetch Dictionary results that we already
know before-hand that will fail.

2) Lack of appropriate information for user (e.g.: help in echo-area
with `display-local-help').

I personally prefer the other approach of creating appropriate buttons
for URIs, but I am open to any solution.

---
Gabriel

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

[Eli Zaretskii]

> From: Gabriel <gabriel376@hotmail.com>
> Date: Mon, 21 Nov 2022 11:52:42 -0300
> 
> 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.

Sorry, I'm not following.  I tried "emacs", "fsf", and "w3c", and I seem to
get reasonable results.  For example, here's what I see for "w3c":

  [Back] [Search definition]         [Matching words]        [Quit]
	 [Select dictionary]         [Select match strategy]

  2 definitions found

  From V.E.R.A. -- Virtual Entity of Relevant Acronyms (February 2016) [vera]:

  W3C
	 World Wide Web Consortium (WWW, org.)


  From The Free On-line Dictionary of Computing (30 December 2018) [foldoc]:

  World Wide Web Consortium
  W3C
  W3 Consortium

     <web, body> (W3C) The main standards body for the
     web.  W3C works with the global community to
     establish international standards for client and server
     protocols that enable on-line commerce and communications on
     the Internet.  It also produces reference software.

     W3C was created by the Massachusetts Institute of Technology
     (MIT) on 25 October 1994.  Netscape Communications
     Corporation was a founding member.  The Consortium is run by
     MIT LCS and INRIA, in collaboration with CERN where the
     web originated.  W3C is funded by industrial members but its
     products are freely available to all.  The director is Tim
     Berners-Lee who invented the web at the Center
     for European Particle Research (CERN).

     (http://w3.org/).

     (1996-11-03)


What exactly is wrong with that?  What am I missing?  And how is handling of
URIs related to this?

> 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:

Search how? what do you type at the prompt of "M-x eww"?  And what do you
type afterwards to search for some word?

Thanks.

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

[Eli Zaretskii]

Ping!  Could you please respond to the questions I had in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59448#14?

Thanks.

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

[Gabriel]

Eli Zaretskii <eliz@gnu.org> writes:

>
> Sorry, I'm not following.  I tried "emacs", "fsf", and "w3c", and I seem to
> get reasonable results.  For example, here's what I see for "w3c":
>
> What exactly is wrong with that?  What am I missing?  And how is handling of
> URIs related to this?
>

The results from dictionary are OK, the issue is how URIs are
interpreted.

For example, "M-x dictionary-search fsf" will bring the correct results
and will transform all "keywords" (e.g.: "GNU", "free software",
"Richard Stallman", "Emacs" etc) into `dictionary-link-button'.  By
pressing RET on these buttons, a `dictionary-new-search' will be
executed, and new correct results will be displayed.  So far so good.

However, URIs (e.g.: "http://cs.pdx.edu/~trent/gnu/",
"http://delorie.com/gnu/" etc) will also be treated as "keywords",
creating `dictionary-link-button'.  By pressing RET on these buttons, a
`dictionary-new-search' will be executed, and no results will be found
(because there are not results for "http://cs.pdx.edu/~trent/gnu/").

If we open the dictionary result page for "fsf" in any browser (e.g.:
Firefox, EWW etc), clicking on "keywords" (e.g.: "GNU", "free software",
"Richard Stallman", "Emacs" etc) will display a new dictionary result
page and clicking on URIs (e.g.: "http://cs.pdx.edu/~trent/gnu/",
"http://delorie.com/gnu/" etc) will open the URI.

The intention of this bug report is to discuss the possibility of
enhancing the default behavior of dictionary to property identify and
handle URIs (i.e., to not treat URIs as ordinary dictionary keywords).
See previous threads for more details.

Let me know if you need additional information.

---
Gabriel

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

[Eli Zaretskii]

> From: Gabriel <gabriel376@hotmail.com>
> Date: Sun, 27 Nov 2022 05:27:06 -0300
> 
> However, URIs (e.g.: "http://cs.pdx.edu/~trent/gnu/",
> "http://delorie.com/gnu/" etc) will also be treated as "keywords",
> creating `dictionary-link-button'.  By pressing RET on these buttons, a
> `dictionary-new-search' will be executed, and no results will be found
> (because there are not results for "http://cs.pdx.edu/~trent/gnu/").
> 
> If we open the dictionary result page for "fsf" in any browser (e.g.:
> Firefox, EWW etc), clicking on "keywords" (e.g.: "GNU", "free software",
> "Richard Stallman", "Emacs" etc) will display a new dictionary result
> page and clicking on URIs (e.g.: "http://cs.pdx.edu/~trent/gnu/",
> "http://delorie.com/gnu/" etc) will open the URI.
> 
> The intention of this bug report is to discuss the possibility of
> enhancing the default behavior of dictionary to property identify and
> handle URIs (i.e., to not treat URIs as ordinary dictionary keywords).
> See previous threads for more details.

OK, thanks.  So I think adding discovery of URLs to dictionary.el is the
better alternative.  Patches are welcome.