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: Mon, 24 May 2021 20:05:45 +0100 Message-ID: <874kesj6k6.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> 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="4856"; 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 Mon May 24 21:07:08 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 1llFuu-00013w-Ix for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 21:07:08 +0200 Original-Received: from localhost ([::1]:43564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llFut-0007v2-Gb for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 15:07:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llFtj-0005iA-0b for emacs-devel@gnu.org; Mon, 24 May 2021 15:05:57 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:35601) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llFtf-0005T9-0L for emacs-devel@gnu.org; Mon, 24 May 2021 15:05:54 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id a4so29646649wrr.2 for ; Mon, 24 May 2021 12:05:50 -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=1LJ+yUrUGiPg2eHE/lz6m4uGzFGM7ei0KIfdB9euJlk=; b=ib0O4TIeyY8Twa4K4NXHzGu6TV/drZznlR0NbqaDQjNYDhHVVDemp3iQ15zJFTqyTT TzngjJ5+/CbcOJJ6XSYxNbxmTZK44vHX6QYejSOSSIA2T7l1CfB44/EOGh5ddR3+Q15k PyFTUytQSGs41tkZVaN//u+Zc54/Ab9xa5c+fCodCqlNCuDLgP212OXdzODuMRumuSZe aqz3CtQNEXEXf0POtGjMVGyJqfHiPM0oNdWt0V+jPqLHlv//qR3phyXWRkVTa3WR6BFm IJ4qwXw9+Ev3SqMLRjAJmb1qQ9/sWEsDtvzKi0cKBZqncn1oertcSwVtWeJ3gGKz9eK/ x/8A== 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=1LJ+yUrUGiPg2eHE/lz6m4uGzFGM7ei0KIfdB9euJlk=; b=X9QlTWrUTxx6okS8fyYLigObPCZo2zFbAXqu+Tsx7k4eTcWqOOwkz0xCKWqIYME7If l+JwFhwQ8qEAGXK9riphIRFsCvHa9FpLM0PCB+/Y1dfR7vmg1sGMu3kaFhhKdBqY569J ep0Vh43BjcQlG0XEWDs2YdrV/D5a1Ab9k0ZzURZSx4aYzi4TnzxshDWRSqGP4lNkndYF 25XA/pu2rrLRBblrtiIbQrASp6w760Dg6UKAustu/fO7ignecywxWCTqFUJ14WZ1F1it ntq0KuDJtt/kUaOGwAKihjcOZBaGhss+ZjLiXqAbVYoX4iNLnd09kgzqaqU77ey3sGe7 SW4w== X-Gm-Message-State: AOAM531P7kAxs/4GAc2OUkZPwmUOaFJ8DufYLl7hOpzzjjM5QamyLiUQ vFsOwORALGDnYntKwW/Vfyg= X-Google-Smtp-Source: ABdhPJwdtdTmOIE/xo4niS8fgVifC5YlChBemaOXkHvvguS7iP7k0j46+893vuQ6CfNQOthKSoiXXQ== X-Received: by 2002:a05:6000:1849:: with SMTP id c9mr22993912wri.282.1621883149081; Mon, 24 May 2021 12:05:49 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id q62sm8909875wma.42.2021.05.24.12.05.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 12:05:48 -0700 (PDT) In-Reply-To: <93d2cfe9-bae8-bf94-486f-7569aa31491d@daniel-mendler.de> (Daniel Mendler's message of "Mon, 24 May 2021 01:04:03 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x429.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:269795 Archived-At: 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). In the branch scratch/icomplete-vertical-mode-related-work which I've just pushed to the repo, I have two commits: - One commit, titled "Overhaul annotation-function to match affixation-function" makes annotation-function match its cousin in capability and switches the two producers of affixation-function to use annotation-function instead. It uses the logic we discussed before, returning a propertized string. It should be backward and forward compatible. Modulo bugs, it's not very well tested. After this commit, the only consumer of annotation-function in Emacs is the *Completions* buffer, as before. - The other commit, titled "Make icomplete-vertical-mode behave a little more like a dropdown", is still a work in progress. It reworks icomplete.el to make the vertical mode behave more like a typical dropdown. Alas, it's not very easy to do, especially since a looping dropdown is hard to define in the first place. I think, before icomplete-vertical-mode can really be usable and behave like the fancy extra-Emacs packages, it needs to be iterated some more. This commit also makes use of annotation-function. In the process it shows how layout decisions are delegated to icomplete.el, not to the backend, a criticism of affixation function that Dmitry and Stefan seem to share. Personally, given the evidence here, I'd install the first commit (after testing) and not encourage people to use affixation function for now. We'll see if we keep or remove it (I haven't touched it). I'd also keep working on icomplete.el so we can clean up icomplete-vertical-mode. Jo=C3=A3o