From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Wed, 2 Jun 2021 00:22:44 +0100 Message-ID: References: <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.fsf@gmail.com> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> <871r9laj6a.fsf@gmail.com> <1b73a130-204c-76fb-2b60-02b814aee0f0@daniel-mendler.de> <87r1hl8xom.fsf@gmail.com> <878s3t8tzw.fsf@gmail.com> <3c68bd00-70ca-fa18-f9b8-cd03029f9294@daniel-mendler.de> <8735u18lsd.fsf@gmail.com> <8e33bbfe-0015-b85c-b57c-ba448f2e6215@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Juri Linkov , Stefan Monnier , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 01:27:02 2021 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 1loDmo-0000Uc-Ff for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 01:27:02 +0200 Original-Received: from localhost ([::1]:49562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loDmn-0007Jb-Iu for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 19:27:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loDit-0000kW-TC for emacs-devel@gnu.org; Tue, 01 Jun 2021 19:22:59 -0400 Original-Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]:39933) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loDis-00085n-0h for emacs-devel@gnu.org; Tue, 01 Jun 2021 19:22:59 -0400 Original-Received: by mail-pj1-x102f.google.com with SMTP id o17-20020a17090a9f91b029015cef5b3c50so2340716pjp.4 for ; Tue, 01 Jun 2021 16:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9hrujjDozLFftX7a3gMXohiPJ46NFFZI+gsmQ23KOq8=; b=NXA2HwDDqcOP0Uf4u5fo8Ci+dYkWXyStO5F2LZ24RhTZY44aXM4knfqxF4p8Y+F4Cv 2XRwO/QY18JObG91Q0x/qLqOdka4tuhfjn03PbeyboqKYRGSHuoAAsfGKqnnf8IH3Gp5 U+rhdPa6s3ttrGcMApCmwL72lnNEA2I6B2SmfJT4sC3NsEdT69FRNmyEg/6enMi9jI/t M92HGD/XUSfL5QonC0edH75tRnDafBXN0cbwjuX37S8CRVyA2WwG/zX2zwxOQIAPE2Do h8OaByrJbZpAW4ZcEYaZChE3cxtG5tWfczKwzqheDa2mSfAoZKPsG4I7N41oSJDqWrwB 6opA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9hrujjDozLFftX7a3gMXohiPJ46NFFZI+gsmQ23KOq8=; b=SOyHBJz/J8Bclmb9JkVJm/pRde621aJtw4CioB1WRkBEqaost6Bc2uEPdD+QcZM2xk /Jv3sE9uvVIftDlviIqY3LmLpQUtifKrTOSvmB/NtDMKcnw4j/30JDwNvG3/3Ydg8Lgp F6KMupj457tX55A+X5TFKBWhKa6yDfM57/UpnUURwZ5KNL1qE2G2SuCtJUDxqSHpm7eW x1txw1WPFPZy0oygiz4pE08VSeFuP5iXnExz7Pqe2yBZFypVCQCjjs/TLez9K0vC5S/t mRcerwrmTtzuMkGzDy0ymjt0BMlMGWuQ9oFvRUBBwWBd3z7kn/Ki9yoXACE6AoRK19Km 3Cmg== X-Gm-Message-State: AOAM533qlPWxh3XO+f4EbBkvxYNC+h4+oDeRJvCuLTVIpX7PPUzr6Yjz KcA3vCI5LeGHKXiJZCaBJ2ExAXzj4AhGDsmn/kw= X-Google-Smtp-Source: ABdhPJxwTbnEMcdkKpG4ohWJUi93QaAg4FlMrCP3pFPhv7/oR9UVTpTUc+mx1GjuA0tCCFxWdHndTlMBlUHgn4BQfN0= X-Received: by 2002:a17:90a:6e07:: with SMTP id b7mr2277449pjk.7.1622589776407; Tue, 01 Jun 2021 16:22:56 -0700 (PDT) In-Reply-To: <8e33bbfe-0015-b85c-b57c-ba448f2e6215@yandex.ru> Received-SPF: pass client-ip=2607:f8b0:4864:20::102f; envelope-from=joaotavora@gmail.com; helo=mail-pj1-x102f.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:270259 Archived-At: On Wed, Jun 2, 2021 at 12:04 AM Dmitry Gutov wrote: > > On 01.06.2021 21:47, Jo=C3=A3o T=C3=A1vora wrote: > > In what way? Really, all other things being equal, in what way is > > threading arguments through lots of functions, bloating the arglist, > > implementations and the docstrings of said functions, calling group-fun > > multiple times and in multiple places in minibuffer.el better than_not_ > > doing those things? > > Why do you think it forces you to "thread" them? The current implementation in minibuffer.el threads the function down to the point where it is called twice again (once with the same second argument -- a possible inefficiency -- and then with a non-nil second argument). If the results of a single call were stored in the candidate string, this wouldn't be necessary. > Firs of all, you can construct the same composite values you wanted > using the current calling convention of the group-function. And then use > them the same way. Indeed. Indeed that does show that we simplify the code and can keep the current calling convention. But then why should we? Its akwardness becomes even clearer there: calling the same function twice in quick succession with different second arg for two different types of return valu= e. To save a cons? > Whether this results in better minibuffer.el code is debatable: your > diff has more additions than deletions, and one rather long line. Oh sure, that function is slightly more complicated, but if you look at completion--insert-strings completion--insert-horizontal completion--insert-vertical completion--insert-one-column display-completion-list minibuffer-completion-help You'll find they are all simplified. > OTOH, someone in a different codebase might appreciate that the > group-function decouples the mapping to group names from the > transformations of the items, and thus one can do the latter closer to > where the items are printed, instead of having to "thread" the > transformed values to their place of use (from where the grouping logic > was called). Exactly, but my proposal doesn't prevent doing this near the print locus. > Using a text property is a handy workaround, but ideally one shouldn't > have to use it. There's nothing wrong with it? If you see a transformation function as a property of a candidate (which it is in reality -- it's given by a fucnti= on of a candidate), then it's something that fits naturally. If a candidate was some non-string object, I doubt that there would be any doubt as to what to do here. But just because it's a string doesn't change things that much= . Jo=C3=A3o