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

[Drew Adams]

> 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. 

Caveat: Not following this thread at all.
So this is likely to be only noise; sorry,
if you find it so.
___

If some of the discussion has to do with
finding and showing the longest common
match across a set of matches for some
pattern, or even _a_ long common match,
then maybe code such as what I wrote for
Icicles, long ago, might be of interest.

For a set of matches of a given pattern,
depending on the pattern-matching approach,
there might not be _any_ common substring
of all the matches.  E.g., different
matches can use the pattern to match
different parts of the completions.

And even if there is a common substring,
there may not be a single such ("the"
common substring).  Or there may not be
a single longest such substring.

For straight prefix completion the matter
is straightforward.  For other kinds of
matching it's less so.  What I was most
interested in was regexp-matching (which
includes substring matching).

The code I came up with doesn't try to
be perfect.  I think it's pretty useful
in practice.  YMMV.  It amounts to this:

  It is the longest match of your input
  pattern that is common to all candidates
  and also contains the first input match
  in the first or second candidate,
  whichever is longer.

The reason this common-match expansion
typically finds the longest common match
is that your input typically matches the
first or the second candidate in only one
place.  And the longer the input you type,
the more likely this is.  In practice it's
only with very short input the expansion
sometimes misses the longest common match.

The algorithm independently tries two
candidates (first & second) as a starting
point, to increase the probability of
finding the longest common match.

I think it's useful, when showing the set
of completions (e.g. in *Completions*),
to highlight, in a candidate completion,
both (1) the part of it matched by the
pattern and (2) the part of it that's
common to all other matching candidates.
Two different faces are used for this.

The expanded common match found isn't just
a common substring of the completions
matched by your input pattern.  It's such
a substring that also matches your input.

It can be interesting to a user, and is
sometimes useful, to see what a given set
of matches have in common with each other
and with your pattern.  One thing they
can have in common is a common substring.

Besides highlighting a common substring,
Icicles can (optionally) expand/replace
your input pattern in the minibuffer as
well.  (You can hit `C-l' to retrieve the
pattern.)

Since I saw that you mentioned that the
common part can be long, and that can
distract users, I'll mention too that if
you use `C-x .' during completion that
toggles an option that hides (elides) the
common part.  E.g., file-finding commands
that expect an absolute file name can
turn on such eliding to start with.

https://www.emacswiki.org/emacs/Icicles_-_Expanded-Common-Match_Completion