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

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

bug#65137: 29.1; completion-substring-try-completion doesn't return the


From: Dmitry Gutov
Subject: bug#65137: 29.1; completion-substring-try-completion doesn't return the longest common substring
Date: Wed, 30 Aug 2023 02:25:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 29/08/2023 18:45, Spencer Baugh wrote:

Could you describe the usage scenario a little more?

 From my brief testing, the current behavior seems okay most of the
time: you still get the short input which matches a bunch of strings
(e.g. filenames), you can type a little more chars and narrow down.

With your change, TAB will insert the most common prefix for all those
completions, which in case of project-file can be a pretty long
string. Not a huge problem, but on the face of it that doesn't seem
like an improvement. So which scenario would that make better?

As a very concrete example that I ran into frequently, for
project-find-file if you have two files:

dir/foo.ml
dir/foo.mli

and you input "foo" and press Tab, you get "foo.ml".  But it is then
impossible to expand that to dir/foo.ml using completion because of this
bug.  So you have to manually select dir/foo.ml if you want to visit
that file, either by switching to *Completions* and selecting it or by
using minibuffer-next-completion.

Now I understand, thank you. I guess this is something that certain environments (such as OCaml) are more prone to than others.

Also this problem seems somewhat unique to the default completion mechanism. If I use Ivy, or Helm, or Vertico, or even the "bare" icomplete-mode, they all have the notion of the currently selected completion, with a short key sequence to choose it.

E.g. with icomplete-mode on I would type until the needed completion is highlighted in the minibuffer and then press C-j (maybe press C-, or C-. to select it).

The default completion, as you say, has the means to do a similar thing with M-<up> and M-<down>, but it's less obvious and requires more keypresses.

After this bugfix, inputting "foo" and pressing Tab will expand to
"dir/foo.ml".

In general, this bug makes it impossible to input a file name with
completion (in project-file) if that file name is a prefix of another
file name.  Like dir/foo and dir/foo.tar, or dir/foo.log and
dir/foo.log.bak.

Your patch fixes that by expanding inputs into longer lines after TAB (meaning, the user will see their input text shift, sometimes considerably, to the right, and perhaps feel a little disoriented). It might be a minor thing, but a downside nevertheless.

I do wonder what Stefan thinks what would be the right behavior here.





reply via email to

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