bug#23006: 25.0.92; Loading Tramp breaks pcomplete in eshell-mode

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03/21/2016 06:55 PM, Michael Albinus wrote:
>
>> And I don't understand why Tramp shall refuse to provide file name
>> completion once the user has asked for this explicitely. Typing
>> "/ssh:host:tmp/em TAB" is a very convincing argument to me, that the
>> user wants a new connection to "host", and she wants also to get
>> completion for "tmp/ema" on that host. I cannot see why Tramp shall be
>> forbidden to do this.
>
> You don't know that the user has pressed TAB. There are contexts where
> the user hasn't pressed TAB, but we still call
> file-name-all-completions, e.g. in an idle timer callback, to show
> what *would* happen *if* they press tab.

Yes, that would be a legitimate scenario to ask Tramp not to open a new
connection. It's the first time somebody explained this, as far as I'm
aware of, thanks!

So maybe we need two different flags for Tramp: One to suppress opening a
new connection under any circumstances, and one flag to tell Tramp that
we are in the file name completion business, and it shall open a new
connection only it is safe (like seeing a slash in the local file name
part). Remember my scenario about ediff'ing remote files; I *want* file
name completion for the second file, even if there's no established
connection yet.

>> But again, *this* bug report is not about what Tramp does when
>> non-essential is bound to non-nil. *This* bug report is about, that
>> non-essential is nil, although file name completion is
>> undergoing. Remember, we are in eshell, the user has typed "cd /", and
>> afterwards she has called pcomplete.
>
> Sure. I'm the author of this report. Still, it would be nice to have
> `non-essential' have the intended effect.

Still, it would be nice to have let-bound non-essential in order to get
an effect.

Best regards, Michael.