From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: Daniel Mendler <mail@daniel-mendler.de>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: Simplification of `affixation-function`
Date: Wed, 28 Apr 2021 03:20:31 +0300 [thread overview]
Message-ID: <35eddaa5-30fa-80db-7a29-3d171b5c09d6@yandex.ru> (raw)
In-Reply-To: <8735vbr7w3.fsf@mail.linkov.net>
On 27.04.2021 19:48, Juri Linkov wrote:
>> You can also note that the third (suffix) element is always an empty string
>> in both of these use cases. So affixation-function was really added to be
>> able to add a prefix.
>
> affixation-function was an improvement over annotation-function,
> but nonetheless it has limitations too. What would be a better thing is
> like Daniel proposed a new meta `group-function`, I'd imagine a similar
> meta `format-function` that could receive a candidate and return
> a string to insert to the completions buffer.
That would also conflate information with presentation, and thus only be
usable for the default completion UI. And not ideal even for that purpose.
> Then the caller e.g. help--symbol-completion-table could define whether
> to append "u", "a" and "c" in parens by using on a candidate something like
> (format "%s (%s)" cand (cond ((fboundp (intern cand)) "f")) ...),
> or prepend a dimmed letter as a prefix, or to use an icon.
Do you use Company? Take a look at what elisp--company-kind does.
The fact that the space of allowed values is constrained makes the
returned information really more useful.
And here since you do not document which values (strings, characters,
etc) the prefix returned by affixation-function can take, their
usefulness is limited. The user can't be sure what "c" means: it's
"command" here, but could be meant as "constant" by another affixation
function. Is "m" a "macro" or "method"? "f" stands for "function" or
"field"?
And also because of that no completing-read UI can replace these
characters with any alternative (e.g. graphical) representation.
next prev parent reply other threads:[~2021-04-28 0:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-24 17:35 Simplification of `affixation-function` Daniel Mendler
2021-04-24 20:22 ` Juri Linkov
2021-04-24 21:17 ` Daniel Mendler
2021-04-24 21:41 ` Juri Linkov
2021-04-24 22:01 ` Daniel Mendler
2021-04-24 22:34 ` Stefan Monnier
2021-04-24 22:48 ` Dmitry Gutov
2021-04-24 22:56 ` Daniel Mendler
2021-04-25 17:58 ` Dmitry Gutov
2021-04-25 18:08 ` Daniel Mendler
2021-04-25 22:31 ` Dmitry Gutov
2021-04-27 16:48 ` Juri Linkov
2021-04-27 17:39 ` Daniel Mendler
2021-04-27 18:11 ` Juri Linkov
2021-04-27 18:40 ` Daniel Mendler
2021-04-28 0:20 ` Dmitry Gutov [this message]
2021-04-28 19:59 ` Juri Linkov
2021-04-29 2:15 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35eddaa5-30fa-80db-7a29-3d171b5c09d6@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
--cc=mail@daniel-mendler.de \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).