bug#63127: 29.0.90; Tramp all-completions errors with internal error

[Michael Albinus]

Daniel Mendler <mail@daniel-mendler.de> writes:

Hi Daniel,

> I accidentally typed /sudo:::/ instead of /sudo::/ in the file
> completion prompt of my Vertico completion UI. Vertico immediately
> recomputes candidates and in this case shows an internal Tramp error.
>
> File error: tramp-sh-handle-file-name-all-completions: internal error
> accessing ‘/root/\:/’: ‘’
>
> For reproduction, this internal error can be triggered by executing the
> following expressions:
>
> (all-completions "/sudo:::/" #'completion-file-name-table)
> (try-completion "/sudo:::/" #'completion-file-name-table)

I'm not a vertico user, so I have tried to prepare Emacs for this. With
the following invocation, I could reproduce the bug:

--8<---------------cut here---------------start------------->8---
# ~/src/emacs-29/src/emacs -Q -l 
~/.emacs.d/elpa/compat-29.1.4.1/compat-autoloads.el \
  -l ~/.emacs.d/elpa/vertico-1.2/vertico-autoloads.el -f vertico-mode
--8<---------------cut here---------------end--------------->8---

However, there exist a newer Tramp version in GNU ELPA. When I call

--8<---------------cut here---------------start------------->8---
# ~/src/emacs-29/src/emacs -Q -L ~/.emacs.d/elpa/tramp-2.6.0.3/ \
  -l ~/.emacs.d/elpa/compat-29.1.4.1/compat-autoloads.el \
  -l ~/.emacs.d/elpa/vertico-1.2/vertico-autoloads.el -f vertico-mode
--8<---------------cut here---------------end--------------->8---

the error doesn't happen. However, Vertico doesn't seem to complete at
all under this configuration.

Could you pls check, whether using Tramp 2.6.0.3 from GNU ELPA is still
compatible with Vertico? Note that we have changed Tramp's file name
completion per bug#37954, bug#51386, bug#52758, bug#53513, bug#54042 and
bug#60505 (all of them merged to one bug).

> I am not sure if this can be considered a bug, certainly not a serious
> one. Usually completion tables are supposed to not show such
> internal errors. Instead they ideally just return nil signaling the
> absence of matches. Maybe this indicates some problem in the Tramp file
> handler parser, which could bail out earlier on such an invalid path?

This sanity check has already been removed in Tramp 2.6.0.3 per bug#61890.

> Thanks!
>
> Daniel

Best regards, Michael.