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: Tue, 25 May 2021 09:30:00 +0100 Message-ID: <87tumrgqrb.fsf@gmail.com> 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> 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="30673"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "emacs-devel@gnu.org" , Dmitry Gutov , monnier@iro.umontreal.ca, Juri Linkov To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 10:34:18 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 1llSW0-0007ie-G3 for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 10:34:16 +0200 Original-Received: from localhost ([::1]:52328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llSVz-00068l-IZ for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 04:34:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llSRz-0004wp-Fo for emacs-devel@gnu.org; Tue, 25 May 2021 04:30:07 -0400 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:37692) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llSRx-0001Bd-89 for emacs-devel@gnu.org; Tue, 25 May 2021 04:30:06 -0400 Original-Received: by mail-wr1-x431.google.com with SMTP id q5so31190982wrs.4 for ; Tue, 25 May 2021 01:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=qBKaJoVdrlwbC9XmTVLDGQp4LCbTgfiWul8q1vvmMYA=; b=GQhp+C0XR9Unzixj2DhO/E9IIemNE0NuHqxBUJ0G2a+pflTg4+lZxmnk2cwFUb7Izq ygo4euuU802/58nnOXx3O1ucJ7NVEdokTbGShWJYKf3S5hlOtinvnK0/3dqC77FqbIps R8Z/bLyRTCS8WeioPW+kC2FCZwqPR2wCAOuJELq0xrX4yt+ExDrRmf+tWhRknQysV5NP WROJK5Jj8GG5QSpct6d95TzOqD+LYTF2aF5HW+RMBJksww35z6Nob/TEbWpZ8ijT4q8c rw+KE6/s0FZxipL/PMYMPtK4IuBHcOFdorLLzbgxBfDZWhPgf5I6Zyg+D2k3AvUy+0oI B1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=qBKaJoVdrlwbC9XmTVLDGQp4LCbTgfiWul8q1vvmMYA=; b=nm0qtybU+BW2I2XjD05HH+inokKU3HoMc9tnAuTMBJHjpcoFXTvgudMavAY2fwAiWU bej6SqKFzfUUgKTefohjPmFXdNpDr1peS3WNpeeItyD7FEKJn2Xa746QGx9TdXR4v1oL 79l3lKgmGJ2oQLyjxvPG6grjlSU887TBmAAo5XjFvUQTIsjRjO7KNiL4P5sUv7VNIuOf lnZW9D5JHnspq996/evX9vw+ljWcStC7w72/ILlu7nJGkj4yjgzhWg+YxJahMhA02wYh H7aeTrhjF7Ed1J9z23J+y0v3hDSOi1RsXqCc6la8tlWFGvj6Ze7kvlrA52QosCq6O3IV gN7A== X-Gm-Message-State: AOAM5337rwJxWET3XUTgAYXsu3+Ry2/tiVjH2jdqOVgHbOjq+P8LC3MW 3c1NJJExf9IFc9uDU/KoLFo= X-Google-Smtp-Source: ABdhPJwy/zE6yzxJJsSFyhFWuuUTmuq0HrmcCfEH92+TrG3Xkoz8ivI1DMb/8PJMdg4GTjKFzTCkjg== X-Received: by 2002:a5d:6d04:: with SMTP id e4mr25364053wrq.344.1621931403725; Tue, 25 May 2021 01:30:03 -0700 (PDT) Original-Received: from krug ([89.180.145.0]) by smtp.gmail.com with ESMTPSA id z131sm2001078wmb.30.2021.05.25.01.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 May 2021 01:30:03 -0700 (PDT) In-Reply-To: <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> (Daniel Mendler's message of "Tue, 25 May 2021 04:53:19 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x431.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:269839 Archived-At: Daniel Mendler writes: > On 5/25/21 12:07 AM, Juri Linkov wrote: >> The next step would be to allow the option 'completions-format' >> to accept an arbitrary frontend rendering function. Then a new >> possible value could be added such as: >>=20 >> 4. completion--insert-multi-column >>=20 >> So when affixation-function will return a list of multiple columns, >> e.g. for buffers the same list of columns as used by list-buffers: >> '("C" "R" "M" "Buffer" "Size" "Mode" "File") from the backend, >> the new frontend rendering function completion--insert-multi-column >> will accept such a list of all columns, set it to the buffer-local >> variable 'tabulated-list-entries', and call 'tabulated-list-print' >> to render it in the output buffer *Completions*. > > It would be great, if the backend can specify arbitrary custom columns, > maybe with some hints (desired width, if it is a prefix/suffix, etc). > Then we can define some "semantic names" as standard, which should be > understood by the frontend, as Dmitry proposed. To clarify, the analog in some markup format is specifying something as "emphasis" and then the renderer usually decides that bold if it can, or surround it in asterisks. But the markup format doesn't usually say "bold". For the same reasons, what you're now calling "columns" should probably be referred to as "fields" or something equivalently agnostic as to the format in which they are display. > But this can happen as a second step. What kind of > `affixation-function` are you proposing, one that returns a plist? > Would such a design be acceptable for Jo=C3=A3o too? I have no strong feelings on plist, versus alist, versus propertized string, versus object, versus whatever. Just slightly strong feelings as to the fundamental mission of this function which is to do annotation/affixation/whatchacallit, not filtering or reordering. For reasons of "forward compatibility", as you called them, which is the ability for newer backends to work on older Emacs that don't understand these new things, if that work is done in `annotation-function` then it needs to use propertized strings. But if it's done in a new thing, say called decoration-function, it doesn't. Jo=C3=A3o