Re: Feature request (#b)...(...)<not empty>

[Sebastian Gniazdowski <psprint2@xxxxxxxxxxxx>]

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
place.
 
>    ([all-except-fg-or-bg]|[fg]|[bg])#([fgbg]|[bgfg]|[fg]|[bg])
> 
> 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.

-- 
  Sebastian Gniazdowski
  psprint2@xxxxxxxxxxxx