GNU bug report logs - #55491
All completion fragments get added to obarray

Previous Next

Full log

View this message in rfc822 format

From: JD Smith <jdtsmith <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55491 <at> debbugs.gnu.org
Subject: bug#55491: All completion fragments get added to obarray
Date: Tue, 17 May 2022 18:50:41 -0400

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 <at> gnus.org> wrote:
> 
> JD Smith <jdtsmith <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.