zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@zsh.org
Subject: Re: zsh completion for umount
Date: Mon, 31 Oct 2016 00:47:32 -0700	[thread overview]
Message-ID: <161031004732.ZM18486@torch.brasslantern.com> (raw)
In-Reply-To: <58164C21.9090505@gmx.ch>

On Oct 30,  8:38pm, Fourhundred Thecat wrote:
}
} When I remove everything from .zshrc, and only leave following two lines:
} 
}   autoload -Uz compinit
}   compinit -D
} 
} then completion for mount -o <TAB> starts working, same as you describe.
} That is great progress. But umount m<TAB> still does not complete, nor
} does umount ./m<TAB>

Curious that no one has noticed this before.

Completion for mount / umount works fine as long as you're completing
full paths, either to device files or to mount points.

However, the _canonical_paths function that's used to convert strings
on the command line into the One True Path to either such a device or
mount point, is somewhat deficient when it tries to compare a relative
path to the canonical path, as is necessary to complete the path tail
when the current directory is already part of the canonical path.

I don't have any more time to chase this now, but briefly in case
someone else wants to pick it up:

"_canonical_paths_add_path $PREFIX" is called which, if prefix is not
empty, tries calling zstat to see if it is a real file.  Of course
this fails because it's not a file, it's only a prefix of a filename,
so _canonical_paths_get_canonical_path is NOT called, and the path
from the current directory is not discovered.  The upshot is that
_canonical_paths_add_path only does anything useful if the prefix
on the command line is either already a device or mountpoint, or is
the name of a directory in the partial path to one.

If you try to trick it as Daniel suggested by adding "./", things
are only slightly better in _canonical_paths, but then go sideways
later:  the bug discussed earlier this year, in which the current
prefix is erased but nothing replaces it, affects this completion.


  reply	other threads:[~2016-10-31  7:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5815DDAB.8070307__40712.3355348178$1477828401$gmane$org@gmx.ch>
2016-10-30 15:35 ` Daniel Shahaf
2016-10-30 19:38   ` Fourhundred Thecat
2016-10-31  7:47     ` Bart Schaefer [this message]
     [not found]     ` <161031004732.ZM18486__31116.0025107258$1477900147$gmane$org@torch.brasslantern.com>
2016-10-31 15:23       ` Daniel Shahaf
2016-10-30 11:46 Fourhundred Thecat

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

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

  git send-email \
    --in-reply-to=161031004732.ZM18486@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /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.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).