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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 25, 12:37am, Sebastian Gniazdowski wrote:
}
} So maybe: ((a|)(b|)(c|))(#n). #n is for not-empty, resembles [[ -n.
} 
} It looks like typical pattern situation: try something, decide if to
} reject it. So maybe it's easy to add?

It's not typical -- as Daniel described, it requires doing either
look-ahead or look-behind, which a simple regular expression scanner
does not do.  That is, when scanning a string such as "fgfgbg" the
scanner has already accepted and moved past the first "fg" before it
examines the second "f".  In order to restrict what was matched
before, the code must either stop at that point and try all possible
matches for the "fgbg" remainder of the string -- and then remember
what NOT to do when it backs up to try again -- or it must remember
everything it did up to that point and re-evaluate that after the
second "fg" is scanned.

Since this could be nested, the tree of "extra looks" has arbitrary
branching.  This is different from simply failing to match what is
coming up next and backtracking the whole process.  This is also why
perl lookahead/behind patterns have several restrictions, e.g. that
the "look" be a fixed length string, so that most possible branches
can be pruned off that tree at expression compile time.

I've greatly simplified that explanation; I'm guessing you haven't yet
studied the computer science concept of "finite automata".  You may
find it interesting.


On Feb 25,  7:36am, Sebastian Gniazdowski wrote:
}
} [range spanning all codes]([fg range]|)([bg range]|)
} 
} This way first position cannot be null and things work. However, this
} will accept fgfg fgfgbg bgfg bgfgbg. But works and is fast. How would
} you do it?

In this case since there are only two patterns at the tail of the string
I'd probably just brute-force it:

   ([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 think your neutral comment tends to hide fact how powerful (#n) and
} (#z) would be, but I might not convey this message anyway.

Yes, they're so powerful that they require an entirely different sort
of expression parser to make them work.