Re: [ELPA] New package: dict

[Philip Kaludercic <philipk@posteo.net>]

Eshel Yaron <me@eshelyaron.com> writes:

>>> +(defcustom dictionary-display-definition-function nil
>>> +  "Function to use for displaying dictionary definitions.
>>> +It is called with three string arguments: the word being defined,
>>> +the dictionary name, and the full definition."
>>> +  :type '(choice (const :tag "Dictionary buffer" nil)
>>> +                 (const :tag "Help buffer"
>>> +                        dictionary-display-definition-in-help-buffer)
>>> +                 (function :tag "Custom function"))
>>> +  :version "30.1")
>>
>> What is the reason for having this option fallback to nil?  I couldn't
>> make that out from the patch.  If all the other options offer a
>> concrete-default function (that you could also call in your own
>> function), then it seems inconsistent to not provide this here as well.
>
> The reason is that, unlike the other options, the default path that
> `dictionary-search` takes to displaying a definition is highly coupled
> with how it obtains the definition, making it difficult to extract into
> a standalone function.  That's a refactor I prefer to avoid at this
> point.  So, if you set `dictionary-display-definition-function` to a
> custom function, we use the new function `dictionary-define-word` to
> cleanly obtain the definition and let your custom function display it.
> If you use the default (nil) value, we let `dictionary-search` call the
> "old" function `dictionary-new-search` that both obtains and displays
> the definition.

OK, I am not familiar with the code and I get that it could take too
much effort to refactor this properly right now.

>>> +(defun dictionary-define-word (word dictionary)
>>> +  "Return the definition of WORD in DICTIONARY, or nil if not found."
>>> +  (dictionary-send-command
>>> +   (format "define %s \"%s\"" dictionary word))
>>> +  (when (and (= (read (dictionary-read-reply)) 150)
>>> +             (= (read (dictionary-read-reply)) 151))
>>
>> I think a memq would be nice here.
>>
>
> No, `memq` would be appropriate if we wanted to check that the
> expression `(read (dictionary-read-reply))` evaluates to either 150 or
> to 151, but here we want to check that it evaluates 150 and then
> afterwards that it evaluates to 151.

Whoops, misread that as and `or' and forgot about side-effects.

>>> +(defun dictionary-display-definition-in-help-buffer (word dictionary definition)
>>> +  "Display DEFINITION, the definition of WORD in DICTIONARY."
>>> +  (let ((help-buffer-under-preparation t))
>>> +    (help-setup-xref (list #'dictionary-search word dictionary)
>>> +                     (called-interactively-p 'interactive))
>>> +    (with-help-window (help-buffer)
>>> +      (with-current-buffer (help-buffer)
>>> +        (insert definition)
>>> +        (goto-char (point-min))
>>> +        (while (re-search-forward (rx "{"
>>> +                                      (group-n 1 (* (not (any ?}))))
>>> +                                      "}")
>>> +                                  nil t)
>>
>> Perhaps you could explain what is going on here.  Why is this pattern
>> significant?
>
> We want to buttonize references to other definitions in the *Help*
> buffer, which appear enclosed in curly braces.  I've added a comment
> explaining this.

So the protocol always wraps other definitions in curly braces?