bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15735: [External] : Re: bug#15735: locate-file-completion-table shou


From: Drew Adams
Subject: bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input
Date: Sun, 6 Feb 2022 00:29:27 +0000

> >> I've now introduced a new user option find-library-include-other-files
> >> in Emacs 29 that makes `read-library-name' (and therefore
> >> `find-library') behave differently -- if set to nil, it'll offer
> >> completion over library files and nothing else.
> >
> > Thanks.  But what's the default behavior, nil or non-nil?
> 
> Non-nil.

So we're back to Square 1.  Guess this should be
filed under "won't fix" instead of "done".

Instead of fixing it, e.g. as Stefan indicated,
you chose to give users an option to fix it
themselves, but the default value of the option
doesn't fix it for them.

da> It would make more sense to me if RET at this
da> point did what I expected a second TAB to do:
da> tell you there are no completions (beyond the
da> directory name), but not exit the minibuffer.

sm> Yes, that makes sense.  Indeed, there's a problem in the completion system: 
we don't distinguish between a valid input and a completion candidate.  
"ess-5.3.10/" is a valid completion candidate, but is not a valid input.

sm> IIRC there are cases where the completion primitives make it difficult to 
enforce this distinction (e.g. when we provide a predicate, where it can be OK 
to ignore the predicate on intermediate completions like "ess-5.3.10/"), but in 
the case of load-library's completion, it should be fixable without too much 
trouble.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]