unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r113958: * minibuffer.el (completion--sifn-requote): Bind `non-essential'.
Date: Thu, 22 Aug 2013 20:40:35 +0200	[thread overview]
Message-ID: <87zjs9sh5o.fsf@gmx.de> (raw)
In-Reply-To: <jwvob8pd9uo.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 22 Aug 2013 11:39:24 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Hmm. Why not signalling a pilot error, when a user applies "C-x
>> f /sudo: RET"?  It's not so different from the case the user has
>> described in Bug#13900, which was the trigger to introduce the rule
>> "host name != any method name".
>
> Then how about a different take on the problem: Tramp shouldn't signal
> an "ambiguous file name" error when its behavior would be the same
> either way.  AFAIK substitute-in-file-name would return the same result
> regardless of whether "/ssh:vagrant@192.168.10." is taken to be the file
> "vagrant@192.168.10." in host "ssh" or access via ssh to host
> "192.168.10.".

Well, I could try to implement it in Tramp's `substitute-in-file-name'
handler. However, I don't know which other functions with file name
handlers are called when applying `minibuffer--complete-and-exit'. Let's
see. (But it would be a just a hack)

>> And it is bound to t only in icomplete.el, ido.el and rfn-eshadow.el, as
>> yet. For exactly that reason: "please relax your tests and connection
>> actions when performing file name completion or minibuffer decoration".
>
> The key word is "decoration" and not "completion".  The present case is
> about completion and not about decoration.
>
>> That doesn't sound ugly to me.
>
> It's called `non-essential' and not `tramp-inhibit' specifically because
> I don't want icomplete.el and friends to have Tramp-specific hacks
> in them.  If you start abusing it on the premise that "that's how I use
> it in Tramp", then it defeats the whole purpose.

I don't want to spread trampish functionality somewhere else. But Tramp
is broken by design: its syntax is ambigous, and sometimes Tramp cannot
decide merely on the file name syntax whether this is the intended file
name to be used on the wire.

That's why it needs advice from the caller: "don't take this file name
serious, I'm not interested in a working connection yet". That does not
mean that Tramp wouldn't use an established connection if it exists
already, it simply means that Tramp doesn't open a new connection if
there isn't one.

Minibuffer decoration is such a case where Tramp needs such an advice,
and file name completion is another case. An incomplete file name does
not need a working connection. Consequently, some predicates used in
file name completion (like `file-exists-p') will give proper results
only when the connection is established finally. But that might be
acceptable.

`non-essential' bound to t looks to me perfect for such an advice. If
you believe it is an abuse of that variable, please give me a hint how
Tramp could get such an advice otherwise.

It is not "that's how I use it in Tramp". Since I hack for Tramp (11
years these days) this problem eats a serious amount of my maintenance
time. I would be more than happy if it could be solved finally,
somehow. Due to the misdesigned Tramp file name syntax, I don't see how
to solve it inside Tramp.

>         Stefan

Best regards, Michael.



  reply	other threads:[~2013-08-22 18:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1VBinS-0002iC-21@vcs.savannah.gnu.org>
2013-08-20 14:35 ` [Emacs-diffs] trunk r113958: * minibuffer.el (completion--sifn-requote): Bind `non-essential' Stefan Monnier
2013-08-20 14:59   ` Michael Albinus
2013-08-20 20:35     ` Stefan Monnier
2013-08-21  9:46       ` Michael Albinus
2013-08-21 20:08         ` Stefan Monnier
2013-08-22  9:50           ` Michael Albinus
2013-08-22 15:39             ` Stefan Monnier
2013-08-22 18:40               ` Michael Albinus [this message]
2013-08-23  3:21                 ` Stefan Monnier
2013-08-26 13:19                   ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zjs9sh5o.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).