GNU bug report logs - #15735
locate-file-completion-table should not accept incomplete input

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, "15735 <at> debbugs.gnu.org" <15735 <at> debbugs.gnu.org>
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.

Previous Next

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