Zsh Mailing List Archive
Messages sorted by:
Re: Feature request (#b)...(...)<not empty>
- X-seq: zsh-workers 40635
- From: Sebastian Gniazdowski <psprint2@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Feature request (#b)...(...)<not empty>
- Date: Sat, 25 Feb 2017 09:24:40 -0800
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=vUU4XyTPQFgrhJudM4R2WOFStQ c=; b=1FR1YqrXWx4RbtORrfVCjPqWHe8UfsBdT/hKUPvpOMFg2OSS3FF2d+Q+Xp UEZFC1LbWmeM/f9a9//02+IYMqFEqfMrF0XUwqQXR9Wxi9+/tWL6cIvv3yOG5yo6 qj4pBhG2jEn4SU1bRepAx6PVjKduQeDhMeUYmRSr3uHFaDemo=
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=vU U4XyTPQFgrhJudM4R2WOFStQc=; b=V1HK/Wtvz+H38KpH95qDvjXBR4CxBfVHTf /oUrh7i0GjmTXHmyIAt3il0uB2x7vhfO4oRn9k8L3UvfosKPScTRLopuIVWkXo1o G3TsVhhqoCpMZQv685AfcTkBCQIw4D63eri9SN6jYAgf8SFzZHa/WAcnXPp//LMI tnApLUTlM=
- In-reply-to: <170225084736.ZM22286@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <1488011830.2241447.892433784.52D183B6@webmail.messagingengine.com> <20170225151315.GA4424@fujitsu.shahaf.local2> <1488037019.2320483.892622496.169D8730@webmail.messagingengine.com> <170225084736.ZM22286@torch.brasslantern.com>
On Sat, Feb 25, 2017, at 08:47 AM, Bart Schaefer wrote:
> On Feb 25, 12:37am, Sebastian Gniazdowski wrote:
> (...) or it must remember
> everything it did up to that point and re-evaluate that after the
> second "fg" is scanned.
I thought that ((a|)(b|)(c|)) could be left as it is. So after it scans
"bold" (a), it normally proceeds to scan "fg" (i.e. b), etc. until it
finishes the outer parenthesis. No change here. Different order, e.g.
ba, isn't accepted, i.e. first "fg" then "bold" – the say API is
restricted, order is: bold, foreground, background (lacking any of them
but of course not all).
> (...) This is different from simply failing to match what is
> coming up next and backtracking the whole process.
This matches what (#n) would do. Reject empty result of parentheses, so
indeed... I was thinking in terms of parentheses.
((a|)(b|)(c|))<HERE>(#n) <- in this place we're somewhat at "current"
node. First recently finished. Expected some nodes to be there, grouping
elements of parentheses. And typical rejection of nodes to be already in
> Zsh's scanner will always take the left branch of an alternation if both
> branches will succeed, so arranging this with longest matches first will
> accomplish what you need, I think; but I suspect everything might be a
> bit oversimplified here.
I'm in good position because it's API. User is required not to do
restricted things, it's like e.g. not accepting NULLs in C, so I can
leave it as it is.
Messages sorted by: