zsh-users
 help / color / mirror / code / Atom feed
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


      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).