Re: Integration of dictionary package

[Torsten Hilbrich]

On 20.11.20 04:11, Jean Louis wrote:
> Keep choices during session:[1]
> ----------------------------
> 
> When I select dictionary and bury the buffer like with quit button,
> then the selected dictionary is erased.
> 
> My expectation is that selected dictionary remains at least during
> the session until I change it. Let us say somebody translates words,
> then each time new word need to be translated user would again need to
> select dictionary.
> 
> This same should apply for [Select Match Strategy] as if I already
> select "Match substring occurring anywhere in a headword" then I
> expect as user that match strategy remains at least for the session
> time, and not that I need to re-select it again. I would not even find
> or know that some definition did exist for substring.´

The current dictionary and the matching strategy are buffer-local
variables (dictionary-default-strategy and dictionary-default-strategy).
As the buffer is closed when pressing the quit button this setting is
then lost.

> 
> Failed to open server localhost, continue with dict.org (y/n)?
> --------------------------------------------------------------
> 
> If user says one time here, then at least during Emacs session this
> need not be asked again, unless user sets it up to be let us say
> localhost. 

This could be modified, in this case I could set the variable
dictionary-server to preserve the user's choice (without storing it
permanently).

> 
> Matching strategy
> -----------------
> 
> Matching strategy could be customizable, I am not sure if it is, is
> it?

You can customize-variable dictionary-default-strategy. However, the RFC
only requires the "exact" and "prefix" strategy and to provide a default
strategy when "." is used. So a customisation could only provide a value
list of these special values and maybe a user-supplied ones.

All other strategy can be queried by the server and set for this
specific dictionary buffer.


> When I already say for example: .
> 
> 
> [quit] button:
> --------------
> 
> Just like M-x calendar and some other features I think there is no
> need to really kill the *Dictionary* buffer. It better remains in
> memory. When user click on [quit] it would bury the buffer but it
> would not kill it.
> 
> By doing so, also the above first problem with remembering of choices
> would be partially solved, but I do not think this should be solution
> for the choices problem during Emacs session. Choices should be
> remembered during Emacs session even if *Dictionary* buffer is
> killed. See above [1].

You can customize-variable dictionary-use-single-buffer

> Regarding selection of dictionary
> ---------------------------------
> 
> For this here:
> 
> Please select your default dictionary:
> 
> *: All dictionaries
> !: The first matching dictionary
> 
> I do not understand what "*" and "!" should mean for the user. I can
> see that selection can be done with ENTER (mouse should work with 1st
> mouse button, but does not).
> 
> Those symbols ! and * maybe indicate something else as for underlying
> choices with the dict server. But to me as user they indicate possibly
> to press those keys to select a dictionary.

"*" and "!" are special dictionary names within the dict protocol.

> 
> Selection of dictionary after definition not found
> --------------------------------------------------
> 
> When I search for definition but definition is not found there is
> error: if: No match for "customizable" with strategy "." in dictionary "*".
> 
> (Now I wonder why is that word not found)
> 
> 1. If word is not found and there are no other words, then that part
>    of sentence ", maybe you are looking for one of these words" should
>    be removed as already mentioned.

This needs some code changes but could be fixed.

> 
> 2. But now, when word is not found, and user did not use All
>    dictionaries as option, upon [select dictionary] thereafter same
>    word should be searched. Now I see this does happen, but do not
>    know why it does not happen all times.
> 
>    1. I selected already All dictionaries
>    2. [Search Definition] I enter: customizable
>    3. Word not found, maybe you are looking for one of these words
>       if: No match for "customizable" with strategy "." in dictionary "*".
>    4. [Select Dictionary] All dictionaries
>    5. Now I get definitions
> 
>    Something is wrong with this workflow as first I do not get
>    anything.
> 
>    If I again [Search definition] I will again get word not
>    found. Which is not logical.

Selecting a dictionary only does that. No search is performed then. When
after selecting the dictionary some search result is shown this is the
result of the previously performed search.

> 
> Capitalization of buttons
> -------------------------
> 
> [Back] [Search Definition]         [Matching words]        [Quit]
>        [Select Dictionary]         [Select Match Strategy]
> 
> While buttons are fine, maybe they need not be capitalized as titles,
> maybe no capitalization is necessary or just first word.
> 
> Matching words is not capitalized as other buttons, it's not
> consistent.

I agree, it should be consistent. I think I will change it to uppercase
the first word only.

> 
> [Matching words] question
> -------------------------
> 
> If I already select match strategy to be substring, then if I go for
> "Search definition" and write "tayl" (expecting taylor) I do not find
> there "taylor", I find other choices.>
> I am myself not sure of differences and wording "Matching words"
> because "Search definition" is call for action but "Matching words" is
> not call for action.

I could rename it to "Find matching words". There is enough space avaiable.

> 
> I would like to understand the difference and why "Search definition"
> is not following "Match Strategy" and why I need to use "Matching
> words" to follow "Match Strategy".

Match strategy is only used when finding matching words. Search
definition only perform a simple lookup without the option for
specifying how to match against the list of words.

See https://tools.ietf.org/html/rfc2229 if you are interested in more
details.

> 
> And then some native English speaker to say if that button sounds
> right "Matching Words".
> 
> Involve TAB to jump from button to button, from marked word to marked word
> --------------------------------------------------------------------------
> 
> I see that TAB gives me error: "There is no next link"
> 
> Instead to look for some links, it should jump in the first 2 lines,
> if there are buttons shown from button to button and after buttons, it
> should jump from marked (yellow) word to marked word so that user may
> quickly get to the choices.

At least in the version within the emacs repository the tab key is
wrapping around through all the buttons and links used. There I use the
button library to provide the functionality for the function buttons at
the top and the links to word definitions in the text.

        Torsten