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 14:48:38 +0300 Message-ID: <390c2a7d-b173-b788-8e72-b8254462ea2f@yandex.ru> References: <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> <3d519805-f602-fa52-ec69-0506bb6cb568@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="10342"; 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 13:49: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 1loPN9-0002W2-Fl for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 13:49:19 +0200 Original-Received: from localhost ([::1]:43736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loPN8-0000dp-IJ for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 07:49:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loPMb-0008OI-3N for emacs-devel@gnu.org; Wed, 02 Jun 2021 07:48:45 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:42504) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loPMY-00024R-Fw for emacs-devel@gnu.org; Wed, 02 Jun 2021 07:48:44 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id c5so1966048wrq.9 for ; Wed, 02 Jun 2021 04:48:41 -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=wajmXFYB3c+O+0xeDeDNMpuvfmvcGmAT6MFWlBVMqec=; b=H1VnO9j+39nBS9KowpqRoWN5xGMwKH+Rfh4E0B3lxpokQxTN9Wbrv06eo+vUdy0VEU I9suLJd4miZUFEliJ1Dtv5B+vloVq0ahH6ArqxzBlo6GutJ+PxN5I/Hh654xde6WhA/b MrfFGP7utNH+AGFGiQPQqHGH+lAuSPwGru7lioVX9/RAVH5+lZvLDj7ExsBSq2jRibg8 y+4+3aV/pYp8/7Z+hinFHvRR9+E+EkDzlQy3j4yPnvcZELvLtcpHpBeUe7+rMhhvc9x2 on9ZbwW6tY597Fh9t2VV6VA8S+obmFTXUiyBdiZXijDou8XzE0ndurWZ14Jhxwfp/PdG MUuQ== 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=wajmXFYB3c+O+0xeDeDNMpuvfmvcGmAT6MFWlBVMqec=; b=r2SzQwyeQpqOl5MzE4xxVAn+Rs2rw5klXPiMtc3S3RkAE79l7aEgtE7Q7IJcvCGXpV GZ/fgaX6DKWjolmUzixwp1XdBQnfqYZZJjZTrBNSzOUGtBeNaX6KSK+N2krnj025uQGQ yrgtarkRgkNPo7DXAizy1r98N0qj/0FfRNmh2b6MMLNDIAy2UEw5O1n9BTAA8VWvZo1X zBLk1D6U8rtowGvjEyvyyw6fZASgB10HF4quZSDQly0Io9y+hoiwXThjYd/SSFTEkrkc Y59QUcJaaDtJcPuilU/3l7pnHwtFEt997w9RNDVRFr8AAEI3xJPtm8j1V47k2hFHiq5m 5BQA== X-Gm-Message-State: AOAM532uwBLc3y+Ad8ODnZ3O01c+ESHmCGTWFZvHzB27uaQxtIShxixK 5fo02PbB3GpIGpe2AxZRh6E= X-Google-Smtp-Source: ABdhPJzlHJd2FMD7fnubgKiJnDmIOt40MOIqisGfxm7/3cTlCoTK4hDgEFQ5kgDcV5/oY7pN11klYg== X-Received: by 2002:a5d:4567:: with SMTP id a7mr20406740wrc.362.1622634520887; Wed, 02 Jun 2021 04:48:40 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s1sm2526461wmj.8.2021.06.02.04.48.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 04:48:40 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=raaahh@gmail.com; helo=mail-wr1-x436.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:270282 Archived-At: On 02.06.2021 03:02, João Távora wrote: > On Wed, Jun 2, 2021 at 12:46 AM Dmitry Gutov wrote: >>> 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 than from this particular addition. > > Yes, yes. Just that this particular addition pulls things in the wrong > direction, in my opinion. > > Another pain point in minibuffer is the representation of candidates. > Sometimes they are strings, sometimes they are lists of strings with > prefixes and suffixes, lots of silly "if consp". Really should all be slots > in a completion object. Maybe, maybe not. Sometimes we're dealing with a lot of completions, though (like 10s of thousands). It would not be great to see some extra latency because of a "cleanup" like that. The cases you are referring to could be solved with a "completions and some extra info" struct or several, I think. Where one of the fields is the list of completion strings. > If that object is a string, text properties are a > good choice (but we could even abstract the implementation away, > though it could be slow). Text properties are a good choice in a lot of cases. If we try to turn each completion into a struct, that would limit fields that could be stored. Add some versioning concerns, etc. >>>> 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? > > Yes, but in that case, a dynamic variable is better than repeating > that little md dance. If you want to move group-fun from function arguments to a dynamic var, I'm not going not object. It seems reasonable to make it less prominent in the code, since it's an optional feature. But speaking of pulling things in the right direction, I think one of the main troubles on minibuffer.el is a lot of the implicit, untyped global state. And that change would add to it. The "little md dance", on the other hand, makes things explicit. >> It's a property (method) of a completion table, isn't it? > > We're talking about different things. The group function is a property > of the completion table. Each invocation transforms a completion, > meaning it produces a property of a completion. An that property could > be stored in the completion, whatever the format. You are describing the action of caching. Which is a fine thing for the caller to do, but there's no need to make the API less flexible than it is now.