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 21:29:15 +0300 Message-ID: <465f4c28-4db6-4a96-d48a-a905bcad6cf3@yandex.ru> References: <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> <390c2a7d-b173-b788-8e72-b8254462ea2f@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="11682"; 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 20:30:22 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 1loVdG-0002x2-4v for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 20:30:22 +0200 Original-Received: from localhost ([::1]:58306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loVdF-0007AB-78 for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 14:30:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loVcJ-0006TT-Vv for emacs-devel@gnu.org; Wed, 02 Jun 2021 14:29:24 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:54861) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loVcF-0007nn-6U for emacs-devel@gnu.org; Wed, 02 Jun 2021 14:29:23 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id o127so1894633wmo.4 for ; Wed, 02 Jun 2021 11:29:18 -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=UiFnoZk46v8QsTW73T7H5hY2JA0pZtd8u3FwWQAyhnI=; b=d4GMjomfEMUoNaeBVy9G/zzx7CiXGwgfJeMnuQJSuoPyyS2h9NN9jdllbjQERQCWJk dsT87Z58psQjL7D/8rgyYpc0FRPxnfhITUgr4zBZMqHecAEjNXs/QdeX1/sozaDy4Ea4 omgCIzfbuLGqxjYmt+w8nQkN/5dutGAihGKt/bR4U8OshLdQmqQ7jSWBSqTWMNoWjvaF PW+uwYkxXSrNf56yjKMYI7EEailPRS1bzb7JY+CyizvOGfPEpBRdTUs2Wq/tSgD/aknW K8FAxA7WDE9+GDJure0eXLa/StHYeVL1HmGK2IFeeHC7YoznGbMQlSnShcN7XRDs+x65 6OSA== 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=UiFnoZk46v8QsTW73T7H5hY2JA0pZtd8u3FwWQAyhnI=; b=sgILoMndUt+X0laYH9tTmhf6cKChtnigHNNrtJgFSkfAz7WHddlcaXCIZb/2W6oo9j xEn+98/nYVngaUyCY5BXK81aiK+WyNehipdd9XKuKo5/0tFYdvH3LVlKxCLCDCQTy0E6 M3DXrNIG0FTsEiptzpqxUwbQuHnnwhZC8ef++A9cgdtFm7T9/rZvDSVX08BKAvVD1qSi UfsrEmEk7yqX6/eSlPlghkUoILaibPshJX6XwdGe8qf3R5U/u7Wj6bGNeo6bHLSiRe15 XzZpnkQLVANIabOs0yYbqPogXyKf/kKWrF3F+tyaOdmZga0e+x5/9cl69CzSg54ShSx1 +AEg== X-Gm-Message-State: AOAM532TS1OYM29t2h39ZsKy5GidNvr8CcPjeQheBMBReR/XSVHO7WqP 7H9nAn09XNzb4Yq1ZkKKBqw= X-Google-Smtp-Source: ABdhPJwynYi9GTaurI6EfSf0ffEbHnj3vSu8qz46ooEIqhcP47C2APquArK9bOiT2NWtZpd3tPHdzg== X-Received: by 2002:a1c:f219:: with SMTP id s25mr6593977wmc.31.1622658557535; Wed, 02 Jun 2021 11:29:17 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p12sm3279556wme.43.2021.06.02.11.29.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 11:29:16 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=raaahh@gmail.com; helo=mail-wm1-x334.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:270317 Archived-At: On 02.06.2021 15:59, João Távora wrote: > In terms of usability and speed of these approaches (propertized string > or struct or something else) would be faster than "sometimes string, > sometimes cons, let's just test it here and there and everywhere". Not necessarily: a struct is extra allocation and extra indirection to get the string. Also could slow down the hot path (the 'all-completions' call). >> 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. > > OK, but that's on another level. We do have per-completion properties which > could possibly not be modeled as string properties. It's much faster > to access say, the completion score for a given company from a slot, > rather than from a text property. Other less important things could stay in > the string property list (or in a plist of said hypothetical struct, > which should > be about the same in terms of cost). Another problem with such structs is it encourages "materializing" properties for all completions ahead of time, instead of doing it lazily. Or if we put a function in every its optional slot, that would be both non-obvious and smell of over-engineering. >> 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. > > The little md dance is the same. In the end it relies on global state > as well, unless you thread the whole thing down again. Everything ultimately relies on the global state, but this way one can trace the logic from the call site to find out how the group function is retrieved. Both alternatives (getting the transformer from the text property and binding group-fun to a dynamic var) rely on "magical" knowledge of sorts, without a comparable handy way to find how the value was computed (Grep will help, of course, but it leaves more opportunity to set the wrong value, or fail to set it in some contexts). > Anyway, I agree with you and that's basically why I prefer keeping > properties of completion objects in the completion object. I'm not a > fan of the global state either for exactly the reasons you list. Threading MD, like Stefan suggested later, seems like a good alternative to me. >> 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. > > It wouldn't be less flexible. Having a "group fun" take a single completion > string and no other args and return its group and a transformer function isn't > less flexible. Alternatively having a "group fun" take a completion string > and fills in its "group" and "transform" properties is also no less flexible. > And both these options are, IMO, better than having a "group fun" take a > second boolean parameter telling it which of two actions to perform, because > of (yet) unproven performance concerns. It seems pretty clear that that's > letting the implementation spill into the API. Now that I understand it better, I say that your proposal is fine (the first one in the paragraph above, at least), but I (obviously) don't agree that that the current one is as ugly as you paint it. It's also more in line with the current shape of the c-a-p-f API (have a xyz-function return a struct where one of the values if also a function is a bit out there).