unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Mendler <mail@daniel-mendler.de>
To: Juri Linkov <juri@linkov.net>
Cc: emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	Dmitry Gutov <dgutov@yandex.ru>
Subject: Re: Simplification of `affixation-function`
Date: Tue, 27 Apr 2021 20:40:40 +0200	[thread overview]
Message-ID: <7a810694-443a-4942-21a2-11b97ef2c106@daniel-mendler.de> (raw)
In-Reply-To: <87fszb61hs.fsf@mail.linkov.net>

On 4/27/21 8:11 PM, Juri Linkov wrote:
> affixation-function is called immediately after sorting candidates.
> format-function could be called immediately before inserting candidates
> only when they are displayed.

I don't see why using the affixation function is not possible for the
transformation. The affixation function is basically just called right
before insertion, right before the candidates are passed to
`display-completion-list`. I don't see the need for an additional format
function here.

>> why not change the affixation function then such that it only returns a
>> single string? We could do that but I think it is valuable to separate
>> prefix/candidate/suffix for display in a tablist.
> 
> Because completion--insert-strings needs to highlight the untransformed
> candidate with mouse-face=highlight.

Yes, that's right. `choose-completion` uses the mouse highlight to
locate the candidate. But this trick must be relaxed as soon as you
bring transformed candidates into the game. In my `group-function` patch
I am attaching the untransformed candidate to the property
`completion--string`, which is then read by `choose-completion`. Note
that the highlighting is still preserved, if no grouping/transformation
is used. In that case the highlighting still reflects the untransformed
candidate. As such the change is backward compatible as long as
grouping/transformation is guarded behind a feature flag.
>> The group function candidate transformation is also to be distinguished
>> from a potential transformation performed by a
>> format/affixation-function, since the group transformation should be
>> only applied when grouping is active. It is therefore better to keep the
>> transformations separate.
> 
> API would be more clear when transformation is separated from grouping.
> So if there is no need to transform group candidates, only group-function
> is provided.  When group candidates need transformation, then additionally
> format/affixation-function can be provided as well.

I considered exactly this, but it is problematic. The idea of grouping
is that you can optionally turn it on or optionally support it in the
UI. The grouping transformation should only be applied when grouping is
enabled. This is important since the grouping candidate transformation
may remove some redundant part of the candidate which is then displayed
in the group title. This means we cannot conflate the grouping candidate
transformation with the `affixation/format-function`.

We can either go with two functions
`group-sort-function+group-transform-function`, where
`group-transform-function` is optional or with the boolean `transform`
argument I am having now in the patch. I think it is easier to have a
single `group-function` instead of splitting this small feature into two
functions.

Daniel



  reply	other threads:[~2021-04-27 18:40 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 [this message]
2021-04-28  0:20                 ` Dmitry Gutov
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=7a810694-443a-4942-21a2-11b97ef2c106@daniel-mendler.de \
    --to=mail@daniel-mendler.de \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --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).