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?
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.