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: Fri, 28 May 2021 15:44:57 +0300 Message-ID: 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> <87y2c5nhsr.fsf@mail.linkov.net> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <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> <874kenulu2.fsf@gmail.com> <5f032d77-670e-e83e-fa37-f0a57e08e166@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32602"; 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: "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Juri Linkov To: Daniel Mendler , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 14:47:41 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 1lmbts-0008Bb-Or for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 14:47:40 +0200 Original-Received: from localhost ([::1]:54354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmbtr-0005DC-Qp for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 08:47:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmbrS-0003yC-Hr for emacs-devel@gnu.org; Fri, 28 May 2021 08:45:10 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:44616) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmbrQ-0005YT-GS for emacs-devel@gnu.org; Fri, 28 May 2021 08:45:10 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id r10so3139413wrj.11 for ; Fri, 28 May 2021 05:45:01 -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=bIxWr1avBz6+wTSribMRtTaGMN+W+WvDV/KFnWjWOwY=; b=QserOwrDjPqUuE4qp2gVKvpS5ZS2IzmkaJ3Rxtq6IDPLlBQ9/uHmq6aDplg2/wTPpk cIIMooodEa9OzBuxFOe3p928l+HqQvjqXW2YrojJzuSuFDMVAeSQ6nY2ZKU+kCh7Ih2F aVSLZ7RsgoLtMW9Fe3zEGIn3WP3j9otaKD54Otpj30iW4JWjlYdHcM2XsrrZbKUQ9K/4 vz2UFH0FmNsdnBQyTE/BzxUuyc7HFeVQH9Ec4Qh0/4XqYKv9dAd0R7XMpDgrBLE09kLn yhFlJKzIUDVunEQzC2ITtE8pK4mYhaAptiygmQA3g4K+rPi6EW1p/1OwnLMdLzLK4Ks4 iFWg== 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=bIxWr1avBz6+wTSribMRtTaGMN+W+WvDV/KFnWjWOwY=; b=i5YOTSFEOTW6jmY8x9GKA0vlHBYx0hGZ9TSDSQGXHA6mTxhOmr8pb5g6TxZnbdvGLN 9M7OE37PXaoizTbmKSaGaYh1b5b6ojltPJuCi7lr9oMyw/tYmTqDiTvgoEtzyN85Sprp yQ7ux1n2WlaadjrFUFtQfFMeKRKx36ouLsNgCjlRfmd2ZUAhkgYUz3fHnbqTsycxxAzW PgXttGOQEu5F6SITnA31wgORrl6kRj0qPGAgGLxZdPIBwUmAGG7or/tRIr347OXy28Sr tLtG/SacK33k0UwkTe58NNwbVAGaQMmdWsnb3IjNDRSXzSOwQE0de7HSezr9lPochSId PEkQ== X-Gm-Message-State: AOAM5328xwZBxtLGhu28b9FkSCZWG7XZ/qeRa8jqfzsarNkg3rRmaVKs W948AG4tnE+GzSgX1XCodNByGliZX0A= X-Google-Smtp-Source: ABdhPJzd5BY20pVcfa3sgIA6aTx13XHwbA+ePjNKgj9J0UQNN9Eb1+eDeHWG1kQmVhyvgo269yw9Lg== X-Received: by 2002:adf:fe49:: with SMTP id m9mr8756695wrs.125.1622205899689; Fri, 28 May 2021 05:44:59 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m9sm6887311wrq.78.2021.05.28.05.44.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 05:44:58 -0700 (PDT) In-Reply-To: <5f032d77-670e-e83e-fa37-f0a57e08e166@daniel-mendler.de> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=raaahh@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:269996 Archived-At: On 28.05.2021 14:55, Daniel Mendler wrote: > But there should also be a > way to request all available fields, such that a UI can show the ones it > supports (but not based on name but based on type!). I get that it could be seen as convenient, but why can't the frontend just request the fields it supports, one after the other? IME the overhead for the additional function calls is negligible, as long as we're rendering only a dozen items or so, and not the full collection (with thousands of items or more). But maybe you want a collection of particular bits of data, pre-formatted for display in a table, and basically not useful for anything else. You could call it :info-columns-function, something like that. Which would allow frontends not even care about which columns are there, or what they contain, and just print them in the indicated order. I'm not a fan of having a backend drive presentation like that, but as long as nobody argues for elimination of "functional" attributes in favor of the info presented in info-columns-function (meaning, I could mostly ignore that addition), I'm not going to fight it. But also consider the possibility of having that logic extracted: - Have c-a-p-f elements only include the "functional" attributes. - Add a middle layer, something like an option completion-info-columns-function, which takes (COMPLETION EXTRA-PROPERTIES) and returns a list of columnar instructions in the format you originally wanted. EXTRA-PROPERTIES is the value of completion-extra-properties when called by the default UI. That would allow, for example, to show the key bindings and descriptions always in the same place, across all completion functions. A possible drawback is that a completion function cannot unilaterally add a new column without a corresponding change in completion-info-columns-function. But that might arguably be a good thing.