The problem with the current begin-while is that it is not a true "while"; it can skip stuff. I request a begin-while construct which is anchored at the "begin" and, if it fails to find the "while" immediately after, gives up and moves on.
Example: Markdown permits a heading like this:
This is a Heading =============
The problem is to match that entire thing, in particular both so that it can be theme-marked and so that "This is a Heading" can appear in the symbol list. At the moment, this can't be done. That fact is well proven by the fact that the Markdown bundle fails to do it. It's a clever bundle so if this were possible, it would be done correctly.
The reason it can't be done is three-fold:
(1) A "match" rule not only cannot span two lines, it can't even look ahead to the next line. Thus I can't express the notion "any line provided it is followed by a line starting with multiple equals signs", even though there is a perfectly good way to say that as a regular expression.
(2) A "begin"-"end" rule is both too narrow and too broad. It is too narrow because the "begin" rule suffers from the same limitation as the "match" rule: it cannot span two lines, and it cannot look ahead to the next line. It is too break because it just keeps going to the end of the document.
(3) A "begin"-"while" rule would work if only the "while" were taken seriously. For example, we could say this:
begin = '^\w.*?\s*$';
to mean "a line that starts with a word character and might end with some spaces". The trouble is that this matches almost any line in the world. What I'm asking is that the 'while' should pick right up on the next line, _and fail if it doesn't work_ (this is what "while" means in most programming languages, after all):
while = '^={6,}\s*$';
This works, but the trouble is that the negative works too: the resulting begin/while pattern matches every line of the document! This seems to be because the "begin" matches everything even though the "while" doesn't match anything.
That is why I am asking for a begin-while that takes the "while" seriously: after matching the "begin", if you can't match the "while", skip that "begin" and try again on the next line. Only succeed when the "begin" is actually *followed* by the "while".
Perhaps what I am actually asking for it "begin" "next" "next" or similar.
I can't believe this would be expensive, and it would solve a LOT of Asciidoc grammar problems, where there are many multi-line patterns such as this one.
m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
On 7 Feb 2014, at 2:08, Matt Neuburg wrote:
I can't believe this would be expensive
It would add complexity to the parser, its API, and it would affect its run-time.
and it would solve a LOT of Asciidoc grammar problems, where there are many multi-line patterns such as this one.
I have considered allowing \n in regular expressions to match multiple lines. I did this for the firstLineMatch pattern (which can match multiple leading lines, if \n is part of its regexp).
Though it is no simple change and it would affect the run-time, but ideally TM would know when such patterns were involved, and thus the penalty would be insignificant for grammars that do not use such patterns.
The lack of setext header support is definitely a thorn in my eye.
On Feb 6, 2014, at 5:48 PM, Allan Odgaard mailinglist@textmate.org wrote:
The lack of setext header support is definitely a thorn in my eye.
I didn't mean to yank your chain. Sorry about that. The problem is that a lot of asciidoc is this sort of pattern: what a line means depends on what's on the next line (and possibly what's on the line after that). m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com