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 17:57:56 +0300 Message-ID: References: <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> <6937cf53-98fc-98ff-3026-b5eccf461a76@daniel-mendler.de> <74e97523-2f86-f365-d183-fddc015fc0dc@yandex.ru> 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="3314"; 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 16:58:35 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 1lmdwZ-0000ko-5Z for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 16:58:35 +0200 Original-Received: from localhost ([::1]:53044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmdwY-0000Yx-7d for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 10:58:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmdw2-0008Iu-CG for emacs-devel@gnu.org; Fri, 28 May 2021 10:58:02 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:42499) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmdw0-0007gl-Gj for emacs-devel@gnu.org; Fri, 28 May 2021 10:58:02 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id x8so3572221wrq.9 for ; Fri, 28 May 2021 07:58:00 -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=oM7yCcvqaeTI8ISvQSd/Jzn/+/SeF9qr1Np5Oy5sM/A=; b=t6QuGaoIKfT1qrjogPMrl/OaOhxu5KXyrE3hhB6Mq0MQaJMoizAercIY+JPN5rs5Q0 YH3dkSMuP5lOtvlYEGB2w5StqurXpStcBoc7dOuB22QT3hiSCIqaaJYi+Zz/OihwYAsU yseYNEHXCr8AMLdXEjQr40hVdCXhDw2cpMICSFYautTfDjEl8WkzlCESk6QIFT9/WvsS du1r8eFHuem4kCiOOYxPFc7/SAkfv3QONZ0TxLA+kqovY82XhPtIt7aO8j8nwPPZRz5W VGq0OegJYMLJEYmTp0zHqtfXu+CYqN5DQm+GpJAnRrECkHxpNnBdTqgkUSyw5md0Qpxc JbvA== 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=oM7yCcvqaeTI8ISvQSd/Jzn/+/SeF9qr1Np5Oy5sM/A=; b=ZW42TPnV3BaqNmxBojRztpYMw8pc9pYMp+/VoC7cC5Pm09GyaZAjJ2w4RCnOpRDeRS GBvZCrCPlVVjeeUSXJYXX3A9QoTuHO9e3PYKzJA8qstmS+zuGUt/9gKbFvDTwCFvdaz6 x4VgCiI6SWrwGdyv+kkUvr1vdEjE6wCoxs/uFd5Ng+wVZCi9JuwLdpsW8+5DNwzSQ/tx DtwA/OTi3MkGZJseDkGvw8pOS2ZlMpdr1LDWxiWslJNRXScjdC+nALJ1O9SQsKrWd8qk +fgjePtVMRPF1sWavqGIU4Gx7oPXwQppZ+t1hfyL0k5NPI5No5+x9GH998uF08ticCeS ZDrg== X-Gm-Message-State: AOAM532CYzyvBdZhE2RbnvwIFymcERzPrBViD4/A+QWzsZJxbVJAdpch Fy5045Inatp5w9GGdMnUOV0KHqkYgQM= X-Google-Smtp-Source: ABdhPJw2gzisf/BWMdRcvhSo5FdOFzBa3JQ/g3D/IQlDjwWVk/qWrQOmHtkQqJCNqimc38OVxBlHcA== X-Received: by 2002:a5d:688d:: with SMTP id h13mr9061893wru.362.1622213879204; Fri, 28 May 2021 07:57:59 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c6sm7650823wru.50.2021.05.28.07.57.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 07:57:58 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=raaahh@gmail.com; helo=mail-wr1-x434.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:270008 Archived-At: On 28.05.2021 17:10, Daniel Mendler wrote: > What about the possibility for the backend to return some kind > of description of the available data? > > (:kind 'icon :keybinding 'string :description 'string ...) > > But maybe that's also overkill. I could get behind something like this. Though it does look like extra work for backend writers. My thinking was more along the lines of having the attribute types simply be described in the docs (then only the "known" attributes would be rendered by different frontends), but you and the Marginalia community can probably make a better choice between these options than myself (*). Note that this is still compatible with my suggestions of completion-info-columns-function, the latter could still be used for some presentation-level choices (like which columns to display and in which order; but also be able to show arbitrary columns). But it becomes less necessary for sure. (*) From where I'm standing, there should be a limited set of columns you'll want to show in such table. Then we could basically document them all at once and forego the introspection capability. But I definitely can be wrong about this. > Okay, I think I understand what you mean. Of course there is already a > bit of presentation performed by the backend depending on how it returns > the data, in particular if the backend returns generic fields of type > string. In order to fix this one would have to distinguish 'string from > 'file field types. Another use for field types could be to render some of the fields differently, e.g. apply the help-key-binding face to key bindings. >>> From my experience this is not a good thing. The completion table should >>> have the ability to add arbitrary annotation columns depending on the >>> data. >> >> Well, it definitely shouldn't choose the presentation of "kind" >> annotations on its own, like in your earlier example. > > My idea is rather that the completion table returns a field of type, > which can then be interpreted depending on its type by the UI. The > question is how fine grained these types should be. As you argued string > is not generic enough, one would require a special 'kind type and a > 'filename type. In the case of the 'kind type the discussion becomes a > bit mood since then one has a field 'kind of type 'kind. But this is not > the common case, I think one could catch many annotations with some > common types. Yes, probably.