From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@zsh.org
Subject: Re: GLOB_COMPLETE and numbered directories
Date: Fri, 20 Mar 2015 09:41:34 -0700 [thread overview]
Message-ID: <150320094134.ZM21989@torch.brasslantern.com> (raw)
In-Reply-To: <20150320042512.GD5478@tarsus.local2>
On Mar 20, 4:25am, Daniel Shahaf wrote:
}
} Bart Schaefer wrote on Thu, Mar 19, 2015 at 18:02:10 -0700:
} > So ... in the case of moving the cursor to after the "1" and pressing
} > TAB, $PREFIX = "1". But in the case of pressing the second TAB after
} > completing to "1a/iota", $PREFIX = "1a/iota" even though the cursor
} > is not at the end of the word.
} >
} > The fix is therefore something like this, though I don't know if I have
} > handled completeinword correctly (as in, I think this generates matches
} > on a second TAB even when completeinword is not set, but I don't think
} > anyone would object to that?).
}
} 'cat 1<C>a/iota<TAB>' behaves (with the patch) as follows:
}
} - If this is the first tab and completeinword set: completes
} - If this is the first tab and completeinword unset: doesn't complete
} - If this is the second tab: completes
}
} I think that's fine because, in the 'this is the second tab and
} completeinword is unset' case, the _first_ tab was at the 'cat 1/i<C>'
} case, so logically the overall completion that's happening here _is_
} "completion at end of word", not in middle of word.
Upon consideration, I wonder if the following might not be preferable. I
think the behavior described above remains unchanged.
I'm still puzzled as to why the internals don't do this correctly; the
cursor is obviously at the expected position.
diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
index d6a1007..977ab49 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -68,6 +68,16 @@ if [[ "$compstate[insert]" = tab* ]]; then
compstate[insert]="${compstate[insert]//tab /}"
fi
+# Second attempt at GLOB_COMPLETE
+
+if [[ "$compstate[pattern_match]" = "*" &&
+ "$_lastcomp[unambiguous]" = "$PREFIX" &&
+ -n "$_lastcomp[unambiguous_cursor]" ]]; then
+ integer upos="$_lastcomp[unambiguous_cursor]"
+ SUFFIX="$PREFIX[upos,-1]$SUFFIX"
+ PREFIX="$PREFIX[1,upos-1]"
+fi
+
# Special completion contexts after `~' and `='.
if [[ -z "$compstate[quote]" ]]; then
prev parent reply other threads:[~2015-03-20 16:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 7:32 Daniel Shahaf
2015-03-19 9:16 ` Mikael Magnusson
2015-03-19 23:15 ` Daniel Shahaf
2015-03-19 16:06 ` Bart Schaefer
2015-03-19 23:18 ` Daniel Shahaf
2015-03-20 1:21 ` Bart Schaefer
2015-03-20 4:16 ` Daniel Shahaf
2015-03-20 1:02 ` Bart Schaefer
2015-03-20 4:25 ` Daniel Shahaf
2015-03-20 16:41 ` Bart Schaefer [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=150320094134.ZM21989@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).