unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eshel Yaron <me@eshelyaron.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
Subject: Re: [ELPA] New package: dict
Date: Fri, 12 May 2023 16:17:53 +0300	[thread overview]
Message-ID: <m1pm75wuwu.fsf@eshelyaron.com> (raw)
In-Reply-To: <875y8ywwko.fsf@posteo.net> (Philip Kaludercic's message of "Thu,  11 May 2023 18:29:43 +0000")

Philip Kaludercic <philipk@posteo.net> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> Alright, I can give augmenting dictionary.el a shot.
>>
>> [...]
>>
>> does it imply that you think it'll be hard to keep Dict's simplicity
>> intact upon incorporating it with dictionary.el?
>
> Right, you'll either have to remove stuff from dictionary.el that people
> have started to depend on, or ignore that fact.

After studying dictionary.el more carefully, I don't currently see a
good way of augmenting it to facilitate the same behavior that Dict
provides.

Basically, Dict has just one command, `dict-describe-word`, and the
question is how this command can be implemented or imitated in terms of
dictionary.el.

`dict-describe-word` is not complex, its behavior is described in
https://eshelyaron.com/dict.html#word-definitions, but let's just take a
look at its definition:

--8<---------------cut here---------------start------------->8---
(defun dict-describe-word (word)
  "Display the definition of WORD.
..."
  (interactive (list (dict-read-word)))
  (let ((definition (dict-define-word word)))
    (if definition
        (funcall dict-display-definition-function word definition)
      (user-error "No definition found for \"%s\"" word))))
--8<---------------cut here---------------end--------------->8---

It only uses two Dict-specific functions: `dict-read-word` and
`dict-define-word`.  `dict-define-word` takes a word and returns its
definition, as a string.  `dict-read-word` reads a word using
`completing-read`, with completion based on dictionary matches.  It
relies on another function, `dict-match-word`, to retrieve the list of
completion candidates from the dictionary server.

In order to implement `dict-describe-word` as part of dictionary.el, I'd
need to replace `dict-match-word` and `dict-describe-word` with
corresponding functions from dictionary.el.  Unfortunately, the parts of
dictionary.el that deal with obtaining information and the parts that
deal with displaying it are not easily separable.  Indeed, their is no
API for obtaining word definitions or matches, and the functions that
perform these actions also do unrelated UI stuff.

For that reason I don't see a good way to reuse code from dictionary.el
to port `dict-describe-word`.

Another option would be to refactor dictionary.el to make it more
modular and to provide a cleaner API.  That's possible, but refactoring
would most likely mean risking breaking stuff, and I couldn't find any
tests that'd help circumvent that risk.

All in all, I currently think it's best to keep these two separate after all.
The only concrete downside that I see is that Dict define a couple of user
options that are very similar to those defined in dictionary.el, and users of
both packages may find it annoying to customize both.  Perhaps I can have Dict
pick up these user options from their corresponding dictionary.el variables if
they're already set.

Any thoughts/ideas?



  reply	other threads:[~2023-05-12 13:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 13:22 [ELPA] New package: dict Eshel Yaron
2023-05-11 13:59 ` Eli Zaretskii
2023-05-11 14:14   ` Philip Kaludercic
2023-05-11 17:56     ` Eshel Yaron
2023-05-11 18:16       ` Eli Zaretskii
2023-05-11 18:29       ` Philip Kaludercic
2023-05-12 13:17         ` Eshel Yaron [this message]
2023-05-12 13:44           ` Eli Zaretskii
2023-05-14  6:41             ` Eshel Yaron
2023-05-14  9:14               ` Eli Zaretskii
2023-05-15 18:50                 ` Eshel Yaron
2023-05-18  7:57                   ` Eshel Yaron
2023-05-18  8:32                     ` Eli Zaretskii
2023-05-18 10:59                   ` Eli Zaretskii
2023-05-18 12:21                     ` Eshel Yaron
2023-05-18 14:09                       ` Eli Zaretskii
2023-05-18 15:51                         ` Eshel Yaron
2023-05-18 15:58                           ` Eli Zaretskii
2023-05-19  8:34                             ` Eshel Yaron
2023-05-20 14:19                               ` Eli Zaretskii
2023-05-20 16:49                               ` Philip Kaludercic
2023-05-20 18:27                                 ` Eshel Yaron
2023-05-20 19:11                                   ` Philip Kaludercic
2023-05-21  6:52                                     ` Eshel Yaron
2023-05-25  9:52                                       ` Eshel Yaron
2023-05-25 19:10                                         ` Philip Kaludercic
2023-05-26  9:16                                         ` Eli Zaretskii
2023-05-26 11:36                                         ` Rudolf Adamkovič
2023-05-26 12:26                                           ` Eshel Yaron
2023-05-18 12:59                   ` Philip Kaludercic
2023-05-18 15:37                     ` Eshel Yaron
2023-05-18 15:58                       ` Philip Kaludercic
2023-05-14 16:06               ` Stephen Leake
2023-05-15 18:58                 ` Eshel Yaron
2023-05-11 14:18 ` Philip Kaludercic
2023-05-11 18:00   ` Eshel Yaron
2023-05-11 18:31     ` Philip Kaludercic
2023-05-12 13:32       ` Eshel Yaron
2023-05-16 19:38         ` Philip Kaludercic
2023-05-17  2:25           ` Eli Zaretskii
2023-05-13 22:30     ` Richard Stallman
2023-05-14  6:48       ` Eshel Yaron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1pm75wuwu.fsf@eshelyaron.com \
    --to=me@eshelyaron.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).