From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: dict Date: Fri, 12 May 2023 16:17:53 +0300 Message-ID: References: <834joj55pt.fsf@gnu.org> <87ednnvtt6.fsf@posteo.net> <875y8ywwko.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18907"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 12 15:18:48 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pxSfY-0004gz-A3 for ged-emacs-devel@m.gmane-mx.org; Fri, 12 May 2023 15:18:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxSeu-00059g-6B; Fri, 12 May 2023 09:18:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxSel-00058f-Ko for emacs-devel@gnu.org; Fri, 12 May 2023 09:17:59 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxSek-0006Tt-0v; Fri, 12 May 2023 09:17:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1683897476; bh=MhaAPy9lJ2PhvMT4hUmHQf5yDrEccKPFx/rdeSpuZAY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VzZ73fesvJYYfUFIrbvszhvh6J+qeJBJMa6NDXHPH4pGjLXrd4theQ8jFPqRW50bF +3XOQB9VHkA2bqnaq8bcSfazktmpqh+WwaQ4q5B1M5yYzgoDdvA6koyhgTuF8oyULy vt7WB1DJN3BeJSO/v8rOTCLq9cuBZM+q085lxVCXZUqV/X08evcBEMlxsYf/7MrMdP nmE43pGjJrHvzUvbk07rZh6nfJPwveqPxqAqjXzI7dyR3pckxyJPpGJ3Ms0yuiA7Jb v4NnT+v/rP5XOghCJstUD60LAIwGHvZFdGasc0gVrzd+VDFyVrqeIPIhynhENxdSht ok30V7vvSsACA== In-Reply-To: <875y8ywwko.fsf@posteo.net> (Philip Kaludercic's message of "Thu, 11 May 2023 18:29:43 +0000") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306080 Archived-At: Philip Kaludercic writes: > Eshel Yaron 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?