From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: perforce completion patch
Date: Tue, 23 Sep 2014 11:14:26 +0100 [thread overview]
Message-ID: <20140923111426.391eaf61@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <20140916203525.119cd15f@pws-pc.ntlworld.com>
On Tue, 16 Sep 2014 20:35:25 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Mon, 15 Sep 2014 15:56:27 -0400
> Anthony Heading <anthony@ajrh.net> wrote:
> > I've had the following small patch for perforce completion sitting
> > around for a while, it
> > tried to fix e.g. the completion of "foo" when doing "p4 add
> > foo/bar.cpp". That said,
> > it runs against the goal of the surrounding comments which aim to skip
> > directories; I
> > couldn't work out though why that would ever be desirable.
>
> ... it might simply be a case (as well as changing the glob) of removing
> the spurious "&& -z $dodirs" (which is true because of the way the
> caller works but confusing) and modifying the following comment to say
> we always complete directories and hence ignore the -td flag in that
> branch.
This gives us the following, which shouldn't materially change the
behaviour of the original patch.
diff --git a/Completion/Unix/Command/_perforce b/Completion/Unix/Command/_perforce
index 8398702..db91e11 100644
--- a/Completion/Unix/Command/_perforce
+++ b/Completion/Unix/Command/_perforce
@@ -1231,10 +1231,15 @@ _perforce_files() {
# "subdirs:subdirectory search:_perforce_subdirs"
)
_alternative $altfiles
- elif [[ -n $unmaintained && -z $dodirs ]]; then
- # a la _cvs_nonentried_files: directories are never maintained,
- # so skip 'em. Unmaintained files can't be integrated, opened
- # or resolved, so treat as exclusive (just as well, since
+ elif [[ -n $unmaintained ]]; then
+ # As directories are always umaintained, but may contain files
+ # we want to add, we'll always complete directories here. That's
+ # neater than the alternative of excluding them here and requesting
+ # them separately in the caller. The only client for this
+ # branch is currently 'p4 add'.
+ #
+ # Unmaintained files can't be integrated, opened
+ # or resolved, so treat as exclusive to other options (just as well, since
# this bit's messy).
local MATCH MBEGIN MEND
local -a omitpats
@@ -1253,7 +1258,7 @@ _perforce_files() {
[[ $#omitpats -eq 1 && $omitpats[1] = '' ]] && omitpats=()
if (( ${#omitpats} )); then
- _path_files -g "*~(*/|)(${(j:|:)~omitpats})(D.)"
+ _path_files -g "*~(*/|)(${(j:|:)~omitpats})(D)"
else
_path_files
fi
pws
prev parent reply other threads:[~2014-09-23 10:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 19:56 Anthony Heading
2014-09-16 19:35 ` Peter Stephenson
2014-09-23 10:14 ` Peter Stephenson [this message]
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=20140923111426.391eaf61@pwslap01u.europe.root.pri \
--to=p.stephenson@samsung.com \
--cc=zsh-workers@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).