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: Wed, 2 Jun 2021 19:52:20 +0100 Message-ID: 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> <465f4c28-4db6-4a96-d48a-a905bcad6cf3@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="4319"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Juri Linkov , Stefan Monnier , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 20:53:16 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 1loVzQ-0000x8-1p for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 20:53:16 +0200 Original-Received: from localhost ([::1]:48426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loVzP-0004Fe-50 for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 14:53:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loVyn-0003aB-9g for emacs-devel@gnu.org; Wed, 02 Jun 2021 14:52:37 -0400 Original-Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]:41634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loVyl-00062p-GM for emacs-devel@gnu.org; Wed, 02 Jun 2021 14:52:36 -0400 Original-Received: by mail-pg1-x530.google.com with SMTP id r1so3021110pgk.8 for ; Wed, 02 Jun 2021 11:52:34 -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=ymKTZe8vJr7Q7Cf6APJ85jyDCR150v+W98AZvbjHMlA=; b=VFTlAyaAIs62lZKyUY0tJIsx6HH923beCJxYJ0Uak1Zn6yOHvsbCGCw0Ow8izW9ZWz Olr4ohWaG0IHsZCHGF3Xh3OBYqRS+WHCPNQbOh3VEpyM2OyzHkpoQbmq77Oxq6zaF9SE 6JdRYo56bPHVG7VTGKBi3QajOfes6QsIljUSD1pngVgxs3jAYd68DJbyjKEW3Mbf1kS+ Hgdz/GoO+opxdeSMvBSxIvGOLOJYVKQDOD6Nf+VBJlwQyeuoLkoTeRMZ5Woe8r5l0Mj9 xHi+WtUWXvaMNh/DNe85qv6Zi/xL+P6F5khhdB/LUT1S+c9EFnGQkzgqGzJqv2KK05Eu pDrg== 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=ymKTZe8vJr7Q7Cf6APJ85jyDCR150v+W98AZvbjHMlA=; b=XesR1TMliv+wERkakvd8uzQ9kPEp1H6FQI6hHbrIvEIjACcTA0FTjPySCRvk54l9xs aEfQwpp08sHi9V+uJK60O9QnfMQwWkjjQa86ejbxnQURBh0Dmc7ht7ZHIgwNWwwbBSxG BUDnG2yv+F2pBkw3dur0xTssQ3LxijtBIQceDk/z4UHCSXya+iFntHRH80S4vXyvWVWf 1/mwRlIKji25DPC3OqBjbs5sSyCq3KUvLvKSEkoo9YgcwldeloMBf+FlwMXHtv/gCKc4 CRWiRr3hYFyUlq7HXOGOpU0WKmgwOpn9RG4Q96ljlTIypxQVrFjN/7InlaSVHJCOpJPV 6ZMw== X-Gm-Message-State: AOAM532kG/2R/uekTm2ITkQeGFnjiS2w1z60arn5Alu1jGBdk0Q1S7Pr 8kpocoyxRmi5+8QgKJfrFWITggvEaRdU0V6pjhI= X-Google-Smtp-Source: ABdhPJxSQIEjttaO+O+PvfoLoIBwb8e29Jobx25ghNvnlj60iky3RYe+d0QK9KGiE27/5+/GDUrOszDcxXQkkxNzBuY= X-Received: by 2002:a63:5c01:: with SMTP id q1mr35419372pgb.447.1622659952454; Wed, 02 Jun 2021 11:52:32 -0700 (PDT) In-Reply-To: <465f4c28-4db6-4a96-d48a-a905bcad6cf3@yandex.ru> Received-SPF: pass client-ip=2607:f8b0:4864:20::530; envelope-from=joaotavora@gmail.com; helo=mail-pg1-x530.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:270323 Archived-At: On Wed, Jun 2, 2021 at 7:29 PM Dmitry Gutov wrote: > 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 extra indirection is the cost of an aref, so a tiny increment to a constant factor that I beliieve is quite large. You'd pay that with the saved IFs alone, I suppose. The allocation is about the same, since you're allocating less string properties. This is just a box, and a string is already a box. > 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. Off, no don't do that. If you want indirection, don't use structs, use eie= io objects (CLOS-likes). You only use structs where you need fast access to. Indeed structs really shine when very fast access to very commonly used properties are is required. But we have only minor hints of these so we'd have to profile. Structs were just an example, I just talking about an ADT. > 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. I don't paint it as particularly ugly (or rather, for me, everything is ugl= y, there is only uglier and less ugly). I was just noting an alternative and looking at its pros and cons. > 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). Are higher-order functions in Elisp APIs really that uncommon? It's the daily bread in lots of stuff I work on, like capf for one (maybe that's wh= at you don't like about it?) Since lexical binding, they are really really cool to use in my opinion. Not gratutiously of course, but for it's good not to shun them. Jo=C3=A3o