From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: dict Date: Thu, 18 May 2023 18:58:46 +0300 Message-ID: <83h6s9vdft.fsf@gnu.org> References: <834joj55pt.fsf@gnu.org> <87ednnvtt6.fsf@posteo.net> <875y8ywwko.fsf@posteo.net> <83zg69br5f.fsf@gnu.org> <83ednj9sw2.fsf@gnu.org> <837ct5x5v6.fsf@gnu.org> <83sfbtvii4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20134"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 18 17:59:12 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 1pzg24-0004xB-2j for ged-emacs-devel@m.gmane-mx.org; Thu, 18 May 2023 17:59:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzg1Z-0004Wn-66; Thu, 18 May 2023 11:58:41 -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 1pzg1T-0004WH-25 for emacs-devel@gnu.org; Thu, 18 May 2023 11:58:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pzg1S-0001xS-Mi; Thu, 18 May 2023 11:58:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9C1NDas37ruvplyZezKSWw3v4TDNh0Ln4OzfBAovikc=; b=jJWWaS3kVOmr nBVfpTspvW2KCRJxeN3QK6xHfmlTjtnp2hd0hQdA7WSZpUaQz0K1nio9ZRbLTMSlgXb4hQkd9OAtJ XNTVxZYPVvDqXQVjlqPajpF25QMll0lUXAaR8MXOkIt6wZvPlBG9Tptdyhmfzses0pAE9HVm9/zvh Cbit+xn3eK83oolTNBzY1wnwICqm3htG2BHIiupHXWD62SbpcUfP8b5fzlUKK0IqA6JPN1DodI7R6 tNW0rOEger+5TgaUSmvEu4co378qRKTZ9jjKyifG4wFhNXCFINvBnEBv18zTE13w95aROAE/ixQY/ lewrNuj0Zeqd5kA/FZQclw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pzg1S-0004mh-53; Thu, 18 May 2023 11:58:34 -0400 In-Reply-To: (message from Eshel Yaron on Thu, 18 May 2023 18:51:01 +0300) 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:306182 Archived-At: > From: Eshel Yaron > Cc: philipk@posteo.net, emacs-devel@gnu.org > Date: Thu, 18 May 2023 18:51:01 +0300 > > Eli Zaretskii writes: > > >> I agree setting three options may be a bit much for casual users, but > >> note that in order to display word definitions in *Help* you only need > >> to customize the last option, `dictionary-display-definition-function`. > >> The other two only affect the interactive word and dictionary selection > >> (mostly adding completion), so I'm not sure it's necessary to couple > >> them with how the definition ends up being presented. > > > > Then why did you add the other options? > > I've added these options in the patch because I want to have minibuffer > completions in `dictionary-search`'s prompts, similarly to > `dict-describe-word`. That's also why I mentioned all three > customizations in my earlier message: to show how to obtain the behavior > of `dict-describe-word` in dictionary.el using the new user options. > > But from the perspective of other dictionary.el users, it may be useful > to customize each of the options but not the necessarily all of them. > That's why I implemented them as separate user options. Makes sense? AFAIR, this started from you proposing a package that would behave as if all 3 options were customized, and saying that you like this alternative behavior much better, so much so that you felt a new package is in order. So I'm asking why not let users who, like you, will like that much better, to get that behavior, with all its bells and whistles, by setting just one option? Wouldn't you personally like such an option and use it all the time?