Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160817223204.ZM23377@torch.brasslantern.com>
Date: Wed, 17 Aug 2016 22:32:04 -0700
In-Reply-To: <ff26da9c-c16f-d148-1753-a4f55c8cb99f@thequod.de>
Comments: In reply to Daniel Hahler <genml+zsh-workers@thequod.de>
        "Re: SSH hostname completion with common suffix and globcomplete inserts characters" (Aug 17,  9:38pm)
References: <705fb246-abcf-176b-d4fa-eb0e01cded05@thequod.de> 
	<ff26da9c-c16f-d148-1753-a4f55c8cb99f@thequod.de> 
	<174db3fa-2af2-d43b-3978-5cb789af4ed9@thequod.de>
In-Reply-To: <174db3fa-2af2-d43b-3978-5cb789af4ed9@thequod.de>
Comments: In reply to Daniel Hahler <genml+zsh-workers@thequod.de>
        "Re: SSH hostname completion with common suffix and globcomplete inserts characters" (Aug 18, 12:52am)
To: zsh-workers@zsh.org
Subject: Re: SSH hostname completion with common suffix and globcomplete inserts characters
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Aug 17,  9:38pm, Daniel Hahler wrote:
}
} Given ssh_config2:
} 
}   Host foo-test-05827d88.foo.bar bar-test-6cae9ce0.foo.bar
} 
} % ssh -F ssh_config2 test<TAB>
} 
} completes to
} 
} % ssh -F ssh_config2 -test-|.foo.bar

I can't reproduce this from "zsh -f" -- I had needed your matcher-list
style from your second message.

} and a second invocation of the completion will then use the "-t" at the
} beginning (for "escape character (or `none')").
} 
} Should this get quoted on expansion to prevent this?

It might be possible to fix this in this specific case, but in general
I don't think it can/should be handled.  This goes along with the usual
completion dilemma of whether to assume the user intends quoting to be
interpreted by completion to change the result, or to be kept in place
in order to affect the parse when the line is accepted.

A more ideal approach would be similar to using _oldlist, wherein the
internals would remember the previous semantic of the current word
(in this case, that it's an argument rather than an option) and use
that semantic again if another completion is attempted in the same
word position, rather than recalculating the context every time.

} When quoting it manually, I see a similar issue as described before (see
} below), where
} 
}   ssh -F ssh_config2 '-test-<TAB>.foo.bar'
} 
} gets expanded to
} 
}   ssh -F ssh_config2 '-test-BR.foo.bar'
} 
} (without the globcomplete option though!)

I'm not able to reproduce that, either, when quoted.  Instead I get a
listing of the two possible results, and then cycling through them
on repeated tabs.

On Aug 18, 12:52am, Daniel Hahler wrote:
}
} The insertion of "BR" does not happen with "zsh -f" though.  It is
} caused by matcher-list zstyle setting in my config: 'r:|[._-]=*'

There must be another zstyle in play somehow, because with this --

}   zstyle ':completion:*' matcher-list '' 'm:{[:lower:]}={[:upper:]}' \
}     'm:{[:upper:]}={[:lower:]}' 'r:|[._-]=* r:|=*' 'l:|=* r:|=*'

-- as my only zstyle, I can't reproduce the result above.  I *can*
reproduce the original report by adding globcomplete.

} While looking at it, it seems like 'r:|[._-]=* r:|=*' is redundant

The thing on the right side of the equal matches the trial completion,
whereas the thing on the left of the equal matches the command line.

So r:|=* means anything can match an empty word (nothing on the command
line) whereas r:|[._-]=* means anything can match after dot, underscore,
or hyphen.  The 'l:|=* r:|=*' may be redundant but I don't think the
other bits are.

} For some other reason I cannot reproduce the issue of "BR" being
} inserted when using ssh_config2 with "zsh -f" just by using the same
} matcher-list zstyle config.

As noted above, I get the "BR" thing only with globcomplete, and only
when the string on the line is not quoted.