From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Wed, 2 Jun 2021 02:46:17 +0300 Message-ID: <3d519805-f602-fa52-ec69-0506bb6cb568@yandex.ru> References: <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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15014"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: Daniel Mendler , Juri Linkov , Stefan Monnier , "emacs-devel@gnu.org" To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 01:47:19 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 1loE6Q-0003mh-SL for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 01:47:18 +0200 Original-Received: from localhost ([::1]:36238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loE6P-0001V0-CM for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 19:47:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58314) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loE5b-0000qA-2E for emacs-devel@gnu.org; Tue, 01 Jun 2021 19:46:27 -0400 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:55055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loE5X-0006FC-RL for emacs-devel@gnu.org; Tue, 01 Jun 2021 19:46:26 -0400 Original-Received: by mail-wm1-x32b.google.com with SMTP id o127so80218wmo.4 for ; Tue, 01 Jun 2021 16:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=A93Th6a+ZJbzc/dD8H+fETFtMvnWIzOowDJ02EMw2Z4=; b=d8g8rZcIZVaC7N0G31/Q4MAA3GYig6KaSmqtJ0/TDemTcHO/HtTMwh4EitBS76y6uT 9VZD51B6jcYVLijJpE1QcLOqThEGD/rNRvJg17lDuWiup/Rjvv8dn8U4/I6ocA5O1a8g CcPZd5GClN/02unDkJy9L0ioGEuy3SkpQKWI+fzNsYO2qvnUeK8oayV1xvMjJNvyvLvF p+hZ24VBLT/siVdKtvFi499Huzro19m0mj/Fjo5MiFpofMwkwDpGKYcbXliZSce+GspQ oADfPyzjpzgE9oh+PTF9NOSLP9Pnqy6CiCEzL0Kk/22wtv/LAG+u98uMHV4lq3GhFJ66 UViA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=A93Th6a+ZJbzc/dD8H+fETFtMvnWIzOowDJ02EMw2Z4=; b=GlJdp6G34SHMu13kHMdcjiMmZYt9vHmYcX8NF1z7Co+8kQr56n0jgx5EGK679N/H0h cLl9iThypm/6Q7wBeVgR3m1erEQqZaFx5qjiW+IBVZIOOxw+m6HpQJqhz1o4VTvVS+Em 0HsmZbmIAgZZ1ephStHnV2KfhxmFzbscLjWL5LfGMhJWXtXR/QBigzfwvmNiLpZET6Ta zKZzgBr4VAFfNSgY4KDUEm8QFasEMmF4StUaHR0fBRR8AiraD2lvoNWNd9mHq26DC12A QfkIeu9yEj7q6TUvLpQd0zhkDqWomzsQvDlkiAkVpyKuwP//FmdIV8DHc7QhN/9M+qe5 D4/g== X-Gm-Message-State: AOAM533QGQfDdVG0TBQ9vSEGRa1ALhjOtpKJyp+YIeqAwtR18KGKX3Bc xDNdhbJLzRucIKzdhERPmXc= X-Google-Smtp-Source: ABdhPJwh4f4sWMfzKE91LAoH0zOTMSDdMz+s4GQ+cb7Kv/PzdkX6raLFtQfi2125zL1PVUDPINxOug== X-Received: by 2002:a1c:e91a:: with SMTP id q26mr2182637wmc.170.1622591180145; Tue, 01 Jun 2021 16:46:20 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w13sm868950wmi.4.2021.06.01.16.46.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Jun 2021 16:46:19 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32b.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_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.613, 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:270261 Archived-At: On 02.06.2021 02:22, João Távora wrote: >> 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 value. I think the awkwardness comes from the general organization of minibuffer.el rather that from this particular addition. >> 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. Yeah, OK, that's a recent change I haven't read yet. But couldn't any of these functions fetch the current group-fun based on the minibuffer contents and the current global values? completion-all-sorted-completions and minibuffer-completion-help have relevant code which could be extracted into a helper. A new dynamic var, as you wrote in a later email, is also an option. >> 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. One might do the grouping and the printing at different stages (in different functions). >> 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 fucntion 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. It's a property (method) of a completion table, isn't it? The way I see it, we actually combine there two distinct actions (grouping and transform), only in the interest of less typing or whatever. But as the actions are distinct, it makes sense to be able to ask for one or the other.