bug#55491: All completion fragments get added to obarray

[JD Smith]

Thanks for your thoughts.  The context is fairly specific — using 
cape-super-capf to compose two CAPF’s: elisp-completion-at-point and 
cape-dabbrev. This results in incorrect test-completion calls which interfere 
with candidate selection.   With your nudge, I discovered this is because cape 
is not handling the elisp--shorthand-aware-* predicates returned by the elisp 
completion system in all cases, so it can be fixed there. 

I guess whether this constitutes a bug depends on whether anyone would expect 
unbound completion fragments to pollute the obarray. 

> On May 17, 2022, at 4:30 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> JD Smith <jdtsmith@gmail.com> writes:
> 
>> (intern-soft "ohno") <C-M-x> -> nil
>> (ohno <M-TAB>                -> No match
>> (intern-soft "ohno") <C-M-x> -> ohno :(
>> 
>> This has the result that, e.g.:
>> 
>> (test-completion "ohno" obarray nil) <C-M-x> ; t!  Sigh
>> 
>> will always return t during completion, for any completed fragment.
>> For completion systems that complete against obarray
>> (e.g. emacs-lisp), this is obviously undesirable.
> 
> Completion in emacs-lisp-mode doesn't take unbound variables into
> account, I think?  So putting stuff into the obarray shouldn't have much
> (if any) noticeable effect.
> 
> Where do you see anything undesirable as a result of this?
> 
> (This behaviour is still present in Emacs 29.)
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no