bug#61274: 29.0.60; dabbrev-capf signals errors

[Daniel Mendler <mail@daniel-mendler.de>]

On 2/4/23 18:17, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Daniel Mendler <mail@daniel-mendler.de>,  61274@debbugs.gnu.org
>> Date: Sat, 04 Feb 2023 12:13:27 -0500
>>
>>> maybe dabbrev-capf is unsuitable to serve as the value of
>>> completion-at-point-functions?
>>
>> As the name implies, it's a function designed specifically for use on
>> `completion-at-point-functions`.  Maybe dabbrev is not well adapted
>> for use within a normal completion UI, but `dabbrev-capf` should do its
>> best to obey the rules of `completion-at-point-functions`, so I think
>> the behavior Daniel suggests is indeed what `dabbrev-capf` should try
>> to do.
> 
> Then there's something here that puzzles me: the recipe presented by
> Daniel is basically identical to what dabbrev-completion does.  And
> yet dabbrev-completion produces different effects when invoked in the
> same buffer with the same text at point.  What is responsible for the
> difference in behavior?

You mean that the stringp type error does not occur? There is some code
in `dabbrev-completion' which sets up Dabbrev (resets variables etc), so
this is likely causing the difference.

However the second issue still occurs even with `dabbrev-completion'.
When I execute `dabbrev-completion' in a buffer where no completions are
found, I get the message "dabbrev--abbrev-at-point: No possible
abbreviation preceding point", while the message should be the usual "No
match" from `completion-at-point'. At this point we are moving into
problematic territory however, since Stefan reimplemented
`dabbrev-completion' based on `dabbrev-capf'. We may want a more
specific error message for `dabbev-completion', while we don't want any
errors signalled by `dabbrev-capf', such that it conforms to the
`completion-at-point-functions' contract.

Daniel