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: Tue, 25 May 2021 00:04:19 +0100 Message-ID: <875yz7ivik.fsf@gmail.com> References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87a6olazff.fsf@gmail.com> <93d2cfe9-bae8-bf94-486f-7569aa31491d@daniel-mendler.de> <874kesj6k6.fsf@gmail.com> <87zgwkhrmi.fsf@gmail.com> <83f4eb63-3299-bfe7-77f9-0fc19403b966@daniel-mendler.de> 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="11923"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Juri Linkov , dgutov@yandex.ru, monnier@iro.umontreal.ca, "emacs-devel@gnu.org" To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 01:06:00 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 1llJe4-0002rP-Jc for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 01:06:00 +0200 Original-Received: from localhost ([::1]:42962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llJe3-0003X8-9o for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 19:05:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llJcW-0002l9-IG for emacs-devel@gnu.org; Mon, 24 May 2021 19:04:24 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:55274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llJcU-0002pY-SI for emacs-devel@gnu.org; Mon, 24 May 2021 19:04:24 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id o127so15674115wmo.4 for ; Mon, 24 May 2021 16:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=RuYA6mQFRCfKtXnFsPomPvtAf8ksPDXrogcKOLQGZLA=; b=PD37uo8wMK0g5ndDInNshIpkr/3klzfON8iy09df1L93fmxSTupqMZccQAY0mlDXqf lbm5ZUGnFPwQytdjGSHR3iD2JesuvHNO9dHbc3CVsbGKzw4nHWIYuYX3TJtYBpSAbAQK IhF2IceslCc5v13UE8WHGvyaeRFTDikPsbPxJw4Aj3XOmyzQfmnj7QPNdIvZw1vIdqC4 3Tm6FC0sbpa1HVsKZzucepmdAiiizQC6r7pnNgn8PdXhsOXR7a+UEiv+MF8HYS7KOCy6 O6zj9EGMqrAZxEZSRpmfmN0XfcaAkV2ZVzHhZ/HW+lKqb94OMQDZxVyv+tASebSn3RHi WqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=RuYA6mQFRCfKtXnFsPomPvtAf8ksPDXrogcKOLQGZLA=; b=OUgX+NYbBaRPO5PmKvgWu8sJpW/WhkNP8dZc3vol3K7RO2/iDWxNW20eU8tvLxeHkO 48t7NlkyIYcr44QhuDoG9EinxBodpB+Kf428bRLNwa+Ns3csjFs4UMFZVBc+WALzsPia ahtud55/ZRYjQa5p+afYa2eZGxfaITSTfzs03BceMH6M/lVL6cLeA3BxRtpdN3hygSoM nSnckDyCgIkDxi2i9bFBZDd8MApj54HswAgBYKcWKaSwQeZKNwjlGC8yyZgEsuFP+wCW heqNIftJjqUQj6SEPX59bGx85EqP3Kq3Ja7h7mFowtDwzx+K1Odtl9hI1dXd8zV0OuKP Xb6w== X-Gm-Message-State: AOAM532gEmCCBmNdRjNPbHi4nt/eHrmPYRUSOrJ/W2D5zZKWsHRfwDq2 r845pgR/s7oPhpBU5AZ8ULI= X-Google-Smtp-Source: ABdhPJxhGIAJL3sNkr0JIKqj1y7XpLpi53Al9r27Bq71cfsnfXuWf8waRdmyAn4/0OqeIdwLvc/kjQ== X-Received: by 2002:a1c:5982:: with SMTP id n124mr21080231wmb.33.1621897461321; Mon, 24 May 2021 16:04:21 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id i12sm13072378wrn.94.2021.05.24.16.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 16:04:20 -0700 (PDT) In-Reply-To: <83f4eb63-3299-bfe7-77f9-0fc19403b966@daniel-mendler.de> (Daniel Mendler's message of "Mon, 24 May 2021 21:53:24 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x330.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:269821 Archived-At: Daniel Mendler writes: > On 5/24/21 9:13 PM, Jo=C3=A3o T=C3=A1vora wrote: >> Jo=C3=A3o T=C3=A1vora writes: >>=20 >>> Daniel Mendler writes: >>> >>>> On 5/23/21 11:54 PM, Jo=C3=A3o T=C3=A1vora wrote: >>> >>>> But regarding merging or not merging the patch, I don't agree with your >>>> argument of taking this as leverage which makes the discussion more or >>>> less difficult. >>> >>> I'm not taking this as "leverage", I just don't think icomplete.el >>> should embark into what I consider (and apparently others) a misdesigned >>> API. We should strive to come up with maintainable and reliable >>> systems, not just merge something because it happens to work and look >>> nice (which is plain to see that it does). > > Okay, I agree with what you say about maintainable and reliable systems. > I am thankful that you are putting work into the > `icomplete-vertical-mode`. And I hope we find a good solution for the > annotations. > > My proposal to merge this is not just because it "looks nice". It > replicates what is already present in the default UI which is part of > the core functionality in minibuffer.el. Everything that you consider to > be wrong here should also be fixed there. > >> By the way, another reason not to merge your patch as it is originally >> is that it seems to affixate too many prospects, way way more than are >> shown. My alternative patch should, in principle, only annotate the >> candidates that are to be displayed. It also does suffix alignment (but >> not prefix yet). So my view is that there are edges to polish in >> multiple angles and we shouldn't rush this. > > If that is indeed the case this is a fair criticism and my patch should > not be merged. However this implies that there was something wrong with > the code all along since the prospects I am annotating are concatenated > right away. Of course the concatenation should only be done for the > candidates which are visible. I see the original code for icomplete-vertical-mode and a rough proof of concept, workable but still a long way to go to be as sturdy as Ivy or Helm or those new things. Until your patch, it didn't annotate completions, and so this wasn't a problem so far. Your (or is it someone else's?) Vertico package probably is much better, and icomplete.el should take clues from it. > Regarding the patches you are working one, I think we should first > agree on a way forward regarding the `affixation-function`. I think making use of annotations in icomplete.el is a good exercise for developing a good annotation-function protocol. That's why I put it in the same branch where I'm reworking icomplete.el. But you're right that they are independent things. > I don't think it is a good idea to end up with the > `affixation-function` in addition the enhanced `annotation-function` > with its prefix/suffix annotations. If we go with the enhanced > `annotation-function` the `affixation-function` should be removed. I tend to agree, but there's also no harm in keeping both. That's what happens right now. > I wonder about the semantics of your 'prefix and 'suffix annotations. > Will the 'suffix take precedence over the string itself then or are they > supposed to be concatenated? Wouldn't it be sufficient to only add a > 'prefix annotation? Yes, it would. But I figured, it's better not even to call the return value of annotation-function a "suffix". It is an annotation, for the frontends to place where they feel is most appropriate. If the annotation is richer, with hints such as 'prefix and 'suffix or 'super-fancy-columnized-hints some frontends may go the extra mile and support those. > Is there a possibility to add more annotations? In > my other mail I had thought about supporting multiple annotation fields > which are then displayed in columns. Do you consider consider something > like this to be realistic? Yes, I do. None of this seems really hard to do. Jo=C3=A3o