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: complexity in minibuffer (was: (icomplete-vertical-mode): Add support for affixations and, annotations) Date: Wed, 2 Jun 2021 15:33:00 +0100 Message-ID: References: <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> <3d519805-f602-fa52-ec69-0506bb6cb568@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="28984"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Juri Linkov , "emacs-devel@gnu.org" , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 16:34: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 1loRwd-0007Co-HC for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 16:34:07 +0200 Original-Received: from localhost ([::1]:59214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loRwc-00030M-9U for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 10:34:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loRvs-0002Ig-MH for emacs-devel@gnu.org; Wed, 02 Jun 2021 10:33:20 -0400 Original-Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]:44618) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loRvl-0003ss-Gx for emacs-devel@gnu.org; Wed, 02 Jun 2021 10:33:20 -0400 Original-Received: by mail-pg1-x52d.google.com with SMTP id 29so2366495pgu.11 for ; Wed, 02 Jun 2021 07:33:13 -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=1o3hi11+TTZQ4xl7EHLAKdps/LBCCHKKiby2Hpk1FTo=; b=sgFS1ggX4IF6Nxfoxjq9J7RLcm1vvPBVQpqAS69t/X9EbweWV3LeDgFiMrXP8hXYbU yD363jKpZ0FWdEDJsILtIekbQddVv3vBgGzfA6bWtA8zJIELA1VxZgWNmZjctZoTn6kI 3wSHUaeiUaJbLYy+VJqZVQ0Ayxjozcpi668459XUUyjccTOh9l5YSbgOYsHoYZVF/+zu TcfwaDS4zEhccHarOkM+t2XmmkW/jEXGf0WRq1STTnl+1yvjhUJqs4y+uiQTAh4nxqD8 YzTg18NsuiWw9ngY/lUlifFLAcE24XBRV6C4mtxZAIPi8uRcchBuCK5Ex3yybos1uUnn Oe2g== 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=1o3hi11+TTZQ4xl7EHLAKdps/LBCCHKKiby2Hpk1FTo=; b=CHRy2Q4UOoKquC9bnTLe97hLInt9ZrSzhYkA0gMvvYvoCHYMsnW9ZSmZ4zEGwEv4nV w8ClVujYhyxdQLIMiejvWZ0OZwok3pclarZQluvt5KI9gPGMjW9Q9cgAA0wtZxbTM+hz rQ9uzjJThxxOGi5r4cd4Bq9ylc8NvdW1xqC/VyxtBrsndAlTn09EBThtXXBIHj0SDOij 9+REF/4BIvxfujk3KwHZDfrXH8P/MG/oXYZOT2uUu8Po4plqiDl/wz1Xy9Wd8atjfdzG cPI6sblgRQD4HfFqItFUkRjskKArlexAK/hUunpteWxw02JSOpDA868pN8/qqF74AiS2 v/QA== X-Gm-Message-State: AOAM532r4xFF5lShlX1KFbBlkZBJNpN5e2E9WCge+rPB8BBlq1RBQdNM DWJj+Qc1GP1KYv8rFRcIrEtYtR7tt05evviU2Jk= X-Google-Smtp-Source: ABdhPJybUTLQH+jZvyqNW6EqleGaGe/rbjx6XG8Z91W9cl86Kzckrc5+UNPZqaf6Hn6O+ZaK7j67iwis9feGXIDm880= X-Received: by 2002:a63:489:: with SMTP id 131mr10605987pge.411.1622644391739; Wed, 02 Jun 2021 07:33:11 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::52d; envelope-from=joaotavora@gmail.com; helo=mail-pg1-x52d.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:270294 Archived-At: On Wed, Jun 2, 2021 at 3:19 PM Stefan Monnier wr= ote: > I must say I'm not sure what you're referring to here. > So I went searching for `consp` in minibuffer.el, and IIUC you're > talking about the code which takes a set of completions and displays it > in *Completions*. E.g. the code in `completion--insert-*`. > Is that right? Yes (but on only) And those were the functions who now get an optional group-fun arg (also often 'if'ed against sometimes only threaded). > [ If so, it explains why I wasn't sure what you referred to, since it's > not part of the code with which I'm familiar ;-) ] > > Indeed, I wonder why we have that. I think it has to do with the way Juri (or someone else) implemented affixation function and annotation function, which was what I was trying to touch to experiment with resolution-function ideas. Sometimes as complet= ion is represented by a cons (string annotation-prefix annotation-suffix) sometimes only a string. It could be a string always, with properties. Or a struct. But let's leave it at string and never cons. > So we could have a quick loop through the completion candidates at the > entry of `display-completion-list` which converts each candidate to > a plain string and then calls a streamlined `completion--insert-strings` > where we don't need those `consp` any more. > [ And in most cases we could call `completion--insert-strings` directly > rather than go through the old `display-completion-list`. ] > > WDYT? Am I missing something? Works, but can't we just find we're making the (presumably) useless cons and just do a propertized string there? I'd prefer to take a clearer look= at where this messiness was introduced and clean it there. Which is commonly why I look at other nearby cleanup opportunities and bring them up here. From where I stand this time (code only in master) is when to strike the iron with the "aesthetics" hammer, which for me normally translates to "use less code that does the same (and usually quicker)". Jo=C3=A3o