unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 10085@debbugs.gnu.org
Subject: bug#10085: 24.0.91; completion-pcm--find-all-completions returns wrong remote file names
Date: Wed, 23 Nov 2011 09:04:19 -0500	[thread overview]
Message-ID: <jwvhb1vkkxg.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87r50z1gqj.fsf@gmx.de> (Michael Albinus's message of "Wed, 23 Nov 2011 07:43:16 +0100")

>>> `expand-file-name' seems to access the remote host. This can be
>>> suppressed by let-binding of `non-essential' to t.
>> I think adding non-essential to rfn-eshadow.el would be even more
>> correct (but it doesn't fix the underlying problem).
> Shall I submit such a patch towards rfn-eshadow.el, for the sake of the
> upcoming release?

You can even install it now.

> Honestly, I do not understand in detail the "underlying problem".

Simple completion tables have (all-completions STRING TABLE) return
a list whose elements all have STRING as a prefix.

More complex completion tables such as file-name completion instead
return a list whose elements have only a suffix of STRING as a prefix.
Until Emacs-23, completion tables could do this without telling anyone,
which restricted the kind of completion styles that could be implemented
(e.g. partial-completion-mode provided partial-completion for files in
an ad-hoc way, whereas Emacs-23 provides partial-completion for files
without using file-specific knowledge).
Emacs-23 solved this issue by adding a new method to completion tables,
called completion-boundaries which lets the completion table announce
which part of STRING will be the prefix of the all-completions result.

So, completion of "/foo/bar" is divided into fields "foo" and "bar" with
"/" as separators, and (completion-boundaries "/foo/bar") returns 5 to
indicate that "/foo/" will be stripped from all-completions's output,
leaving only "bar" as a prefix of all returned elements.

As I have shown with the trace, Tramp treats "/sud:" and "/sudo:"
differently, making the ":" a boundary separator in the first case but
not in the second.  It's not strictly incorrect, but it is inconsistent
and makes it harder for the minibuffer.el code to behave well.

> I guess we need to find out, what are separators in Tramp wrt
> completion tables, and how to handle them.

The user finds out, the implementer decides.


        Stefan





  reply	other threads:[~2011-11-23 14:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-20 15:58 bug#10085: 24.0.91; completion-pcm--find-all-completions returns wrong remote file names Michael Albinus
2011-11-22 17:04 ` Stefan Monnier
2011-11-22 22:13   ` Michael Albinus
2011-11-22 23:05     ` Stefan Monnier
2011-11-23  6:43       ` Michael Albinus
2011-11-23 14:04         ` Stefan Monnier [this message]
2011-11-23 20:28           ` Michael Albinus
2011-11-24  2:10             ` Stefan Monnier
2016-04-27 14:16             ` Stefan Monnier
2016-04-27 18:37               ` Michael Albinus
2016-04-27 19:16                 ` Stefan Monnier
2016-05-02  7:19                   ` Michael Albinus
2011-11-22 19:05 ` Stefan Monnier
2011-11-22 21:55   ` Michael Albinus
2012-03-30 18:28 ` Stefan Monnier
2012-03-31 12:36   ` Michael Albinus
2012-03-31 15:29     ` Stefan Monnier
2016-04-23 20:08 ` bug#10085: Tramp method completions Live System User
2016-04-24  8:22   ` 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=jwvhb1vkkxg.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=10085@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /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).