Re: Why not include all ELPA packages in an Emacs release?

[Philip Kaludercic]

Daniel Mendler <mail@daniel-mendler.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Arash Esbati <arash@gnu.org> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>> I am not familiar with cape,
>>>>>
>>>>> Cape offers CAPFs, but I think one great featuzre is that you can switch
>>>>> the CAPF function during completion with something like this in your
>>>>> init file:
>>>>>
>>>>> (use-package cape
>>>>>   :bind (:map corfu-map
>>>>>               ("C-c p d" . cape-dabbrev)
>>>>>               ("C-c p f" . cape-file)
>>>>>               ("C-c p s" . cape-elisp-symbol)
>>>>>               ("C-c p w" . ispell-completion-at-point)
>>>>>               ("C-c p :" . cape-emoji)))
>>>>
>>>> I tried it out, and it doesn't seem to work that well without something
>>>> like corfu or vertico.  Generally it seems like an example where
>>>> "completion" is misinterpreted to mean "selection".
>>>
>>> This is not correct. Please stop spreading misinformation like this.
>>> Capfs like the ones from Cape can be used to complete in a stepwise
>>> manner. 
>>
>> I understand that, I am just saying that it doesn't feel that natural
>> without something like corfu enabled as well.  Or at least with the
>> above configuration, something like cape-emoji with the default
>> in-buffer completion is less comfortable than the built-in C-x 8 e.
>> Same with dabbrev itself vs. cape-dabbrev.
>
> First, this is not what you said (selection vs completion). 

I do think that this is related. cape-emoji, cape-tex, etc. do not
complete partial input.

>                                                             Second, the
> Capfs provided by Cape work as well or "natural" as other Capfs with the
> default completion UI as they do with Corfu. The aforementioned
> configuration is meant to trigger completion manually, which will open a
> completion UI in any case, but this is not the only way to use these
> Cape commands. You can also use the Capfs by adding them to the
> `completion-at-point-functions' list. Then you can use them as usual via
> `completion-at-point'.

Again, I cannot agree or at least I don't see why.  My impression is
that using the TeX input method remains more natural to me than adding
cape-tex to `completion-at-point-functions'.

>>>         Simple examples are cape-dict, cape-dabbrev or cape-file.
>>> cape-dabbrev for example predates the builtin dabbrev-capf and works in
>>> the same way.
>>
>> How?  When I use M-/, the expansion is replaced in place, while
>> cape-dabbrev behaves more like dabbrev-completion (C-M-/) by prompting
>> me for input.
>
> Yes, dabbrev-expand behaves differently. Note that cape-dabbrev also
> replaces the expansion at point if it is unique, like the dabbrev-capf
> or dabbrev-completion. But that's not my point here. Cape provides
> Capfs, and all I am saying is that the Capfs work as well with the
> default completion UI as they do with Corfu. They follow the usual
> implementation practices of other Capfs which are already part of Emacs.
> You can use them by invoking `completion-at-point' and perform a
> step-wise expansion. Selection doesn't has to happen necessarily.

I can't think of an example OOTB where completion-at-point expands a
string like \alpha results in α.  When playing around with this, it
feels unnatural to me, but if I am the only one who feels like this then
this doesn't matter.  My point is that this feels less unnatural when
used in combination with Corfu, that presents the options as a kind of
selection.

What is relevant for this thread is that there are (debatable) implicit
dependencies between packages that should be kept in mind when
considering to add a package to the core.

> Daniel

-- 
        Philip Kaludercic on peregrine