-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
In my attempt to shoehorn together a Lang Grammar for Textpattern from scratch ( "scopeName = source.txp" , and NOT "text.html.txp" ) I ran into a couple of problems. I also took a peek at how it's done in the MT Bundle, but I decided, it's best to start from scratch. Note.:I'm not a programmer, just a beginner of TM, usually as I understood, this should then go into the developer mailing list, but since I am not a developer, I decided then to post first here.
I'll summarize my observations and obstacles below:
1) grammar Scope consideration
Textpattern's syntax is very similar to Html, there is single tags (self enclosing ) and container tags. However, the total code blocks, used in forms and pages can get rather complex, since in many cases you can have funny nested language constructs that can not be matched with any of the present grammars regex constructs. EXAMPLE.: <li <txp:zem_nth step=1 of=2>class="odd</txp:zem_nth><txp:zem_nth step=1
txp:if_article_listactivea</txp:if_article_list> </txp:zem_nth>
<txp:zem_nth step=1 of=2>"</txp:zem_nth>>txp:permlinktxp:title /</txp:permlink></li>
(Note.:Note the second bracket after the zem_nth closing tag, the code sample for Txp form above will parse a perfectly valid XHTML, once the request is returned from the Server)
You can see the pref snippet that I used to test the above below.:
Sample.: { name = 'keyword.control.txp'; match = '(["|\s]?txp:.+\s/["|\s]?|["|\s]*?txp:.+["|\s]*?|["|\s]?</txp:.+>["|\s]?)'; }, (works, but not with the complex constructs, like mentioned above.)
Problem.: Some of these instances make it difficult to construct the regular expressions. Possible Solution.: Could be excluded with negates whenever occurs (That would be rather hackyish and not elegant)
2) Furthermore the reason, why I opted for a "source txp.scope" rather then the other easier and integrable solution and attempt everything from scratch, is that there is not a real hierarchy between html and txp forms and pages, so I thought it would be more expandable and extensible in that way. Question: Is that so ? Or am I terribly wrong ?
3)Question: Is the p.list format going to change to a xml format for the Language grammars. ?
4) I made two variants of a preliminary bundle for the Grammar, would it make sense to submit those to repository, once they reach an acceptable stage ?
5) I'm a little perplexed with the Theme Editor, and in particular the context of Theme names, Theme Scope names and the corresponding scope selectors in the Language Grammar and prefs. For Instance, for the above p.list value/pair keyword.control.txp, I did not have a blank element of keyword control in the list. I thought at first, that (after reading the manual ) I should have a blank keyword control element (in the Fonts and colors pane ) and then , for my above purpose, I create a keyword.control.txp scope selector, that I style for the above purpose, but that doesn't appear to seem so.
Is it correct to suspect that the element names themselves are irrelevant for the inner functioning of the language grammar ?
I hope that this was not too long and thank you in advance for reading this and possibly have an answer to my questions. So for I am pretty much amazed with the editor.
regards, marios
- -- marios at CSSDelyrium requests http://www.consking.com/contact
________________ __ _ / ___/ __/ __/ _ ___ / /_ ______(_)_ ____ _ / /___\ _\ / // / -_) / // / __/ / // / ' \ ___/___/___/____/__/_/_, /_/ /_/_,_/_/_/_/ /___/
On 21/5/2006, at 0:23, marios buttner wrote:
You can see the pref snippet that I used to test the above below.:
Sample.: { name = 'keyword.control.txp'; match = '(["|\s]?txp:.+\s/["|\s]?|["|\s]*?txp:.+["|\s]*?|["|\s]?</txp:. +>["|\s]?)'; }, (works, but not with the complex constructs, like mentioned above.)
Problem.: Some of these instances make it difficult to construct the regular expressions. Possible Solution.: Could be excluded with negates whenever occurs (That would be rather hackyish and not elegant)
I don’t have a good sense of the language, but another option is to split up the fragment into multiple parts and use begin/end matches. Similar to how HTML tags are matched, where there is both a name, attributes, and potential embedded Ruby, PHP, etc.
- Furthermore the reason, why I opted for a "source txp.scope"
rather then the other easier and integrable solution and attempt everything from scratch, is that there is not a real hierarchy between html and txp forms and pages, so I thought it would be more expandable and extensible in that way. Question: Is that so ? Or am I terribly wrong ?
There are two types of inheritance in TextMate.
First there is simply including another language grammar in the new one. E.g. C++ includes the C grammar and thereby inherit all the C rules. Here the including grammar can override rules included, simply by matching the same stuff but before doing the include.
The other type is in scope name. This has nothing to do with the actual language grammar matching, but it is instead used in the context of scope selecotrs.
For example there is a `table` snippet which inserts an HTML table. The scope selector for this is `text.html` and all languages which have a scope name starting with `text.html` will provide this snippet (e.g. `text.html.markdown`) -- one can override such inheritance by creating a new item which use the same key equivalent / tab trigger, but give it a more specific scope.
For Textpattern, you do want a scope name of `text.html.textpattern` if the functionality in the HTML bundle is useful in the context of txp (like converting to/from entities, creating tags, inserting HTML snippets, etc.).
Even if only a subset is useful, it still makes sense to inherit the scope name, as one can always override the functionality which is different for the inheriting scope, and/or ignore that it exists.
Though should you decide to keep your new scope, you should inherit from text rather than source, if this is markup.
3)Question: Is the p.list format going to change to a xml format for the Language grammars. ?
Not inside the language editor. It is however stored as XML on-disk (and actually binary plists in the default bundles).
- I made two variants of a preliminary bundle for the Grammar,
would it make sense to submit those to repository, once they reach an acceptable stage ?
If others may find it useful, yes.
- [...] Is it correct to suspect that the element names themselves
are irrelevant for the inner functioning of the language grammar ?
Yes -- only the scope selector means something.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Allan Odgaard wrote:
On 21/5/2006, at 0:23, marios buttner wrote:
[snip]...............[snip]
I don�t have a good sense of the language, but another option is to split up the fragment into multiple parts and use begin/end matches. Similar to how HTML tags are matched, where there is both a name, attributes, and potential embedded Ruby, PHP, etc.
Potential candidates for this would be php, javascript , xml, and php includes. There are three types of files that get inserted in the relevant mysql database tables: forms, pages and css. The css files are like any other CSS files.No txp tags allowed inside these. The pages files are the usual template files, just as in MT. (They could indeed be taken as html files, if the header elements for example wouldn't be replaced by a special output form file and parsed therein OTF.) The form files are a special breed and empower the CMS to maintain a complete separation of content and presentation layers along with the ability to parse valid XHTML. File extensions are irrelevant, and the convention is to use ordinary UTF-8 text files since the (official) User handling for those is cut'n paste. In my experimental bundles, I changed this to use .txpml for pages, and .txfml for forms , just in case to have a basic convention to differentiate between them if needed, and let TM automatically recognize them. (I'll probably see what they think about this in the TXP-dev forum and post there for opinions)
Php includes are handled differently and are escaped within txp tags,like so:txp:php code </txp:php>.
[snip]...............[snip]
There are two types of inheritance in TextMate.
First there is simply including another language grammar in the new one. E.g. C++ includes the C grammar and thereby inherit all the C rules. Here the including grammar can override rules included, simply by matching the same stuff but before doing the include.
The other type is in scope name. This has nothing to do with the actual language grammar matching, but it is instead used in the context of scope selecotrs.
For example there is a `table` snippet which inserts an HTML table. The scope selector for this is `text.html` and all languages which have a scope name starting with `text.html` will provide this snippet (e.g. `text.html.markdown`) -- one can override such inheritance by creating a new item which use the same key equivalent / tab trigger, but give it a more specific scope.
For Textpattern, you do want a scope name of `text.html.textpattern` if the functionality in the HTML bundle is useful in the context of txp (like converting to/from entities, creating tags, inserting HTML snippets, etc.).
I came to realize this last night, when I inspected the MT bundle. The route that I took was probably wrong, and overriding would indeed take less time, although , when I tested the MT Bundle on some sample template files, I stumbled on a particular strange fact.
Example: (The following was taken from a regular xml template file for a MT Atom feed from the SixApart Site) 1)A regular nested Element that can be identified as a mt tag:
<$MTEntryBody encode_xml="1"$>
In the tool tip this shows us the scope selectors of:
text.html.mt mt.variable.tag.html variable.other.mt
Nothing particular wrong with this, I would assume.But when the same tags are assigned as an attribute value for an xml tag eg.:
<category term="<$MTCan aategoryLabel encode_xml="1"$>" />
I get :
text.html.mt meta.tag.other.html string.quoted.double.html
, which means , that with the current grammar,I don't get the differentiation, that it is an actual mt tag that is supplied as an argument to another xml tag inside xml.
My question is this:In the above MT example, was the grammar intentionally designed like that?and consequently now we build another preference item to differentiate those tags of the second kind relying on the string.quoted.double scope?
Or is it in fact a shortcoming of the grammar in general ? would the use of captures be the appropriate choice for the above example,to match MT tags, that are nested inside xml tags ?
Even if only a subset is useful, it still makes sense to inherit the scope name, as one can always override the functionality which is different for the inheriting scope, and/or ignore that it exists.
Though should you decide to keep your new scope, you should inherit from text rather than source, if this is markup.
3)Question: Is the p.list format going to change to a xml format for the Language grammars. ?
Not inside the language editor. It is however stored as XML on-disk (and actually binary plists in the default bundles).
(I realized that they couldn't open with Apples default plist editor)
- I made two variants of a preliminary bundle for the Grammar, would it
make sense to submit those to repository, once they reach an acceptable stage ?
If others may find it useful, yes.
I need it for myself, so once I'm getting at an acceptable stage, I'll point to it at lest from the dev-texpattern list, to hear their opinions.The snippets and commands are fairly easy, for what's needed, the problem is the language grammar. I am not sure if it succeeds though.
- [...] Is it correct to suspect that the element names themselves are
irrelevant for the inner functioning of the language grammar ?
Yes -- only the scope selector means something.
Alan, thanks for the valuable help and this advanced and powerful text editor of course,
regards, marios
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
- -- marios at CSSDelyrium requests http://www.consking.com/contact
________________ __ _ / ___/ __/ __/ _ ___ / /_ ______(_)_ ____ _ / /___\ _\ / // / -_) / // / __/ / // / ' \ ___/___/___/____/__/_/_, /_/ /_/_,_/_/_/_/ /___/
On 21/5/2006, at 16:32, marios buttner wrote:
[...] In the above MT example, was the grammar intentionally designed like that?and consequently now we build another preference item to differentiate those tags of the second kind relying on the string.quoted.double scope?
It was done like that only because the other way is more complex, since it requires repeating the MT rules inside the tag matching stuff, and, the tag matching stuff is an included rule. So either the MT grammar would have to duplicate the rule, or the base HTML grammar (which gets included) would have to be changed to support MT tags (like it already does for PHP and Ruby).
So ATM most grammars which augment HTML only does it at the root level. There is a system planned [1] which should make it much easier to have augmenting grammars extend the base grammars though.
[1] http://lists.macromates.com/pipermail/textmate/2006-April/ 009943.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Allan Odgaard wrote:
On 21/5/2006, at 16:32, marios buttner wrote:
[...] In the above MT example, was the grammar intentionally designed like that?and consequently now we build another preference item to differentiate those tags of the second kind relying on the string.quoted.double scope?
[snip]...............[snip]
So ATM most grammars which augment HTML only does it at the root level. There is a system planned [1] which should make it much easier to have augmenting grammars extend the base grammars though.
I have an experimental version for the language, however, I'd like to improve and refine it more, I saw, that the biggest hurdle is the plist syntax and trying to alter it,sometimes brought my unexpected results. I have a large pile of sample files that play hard on the syntax,trying to evaluate it.
Nice to see, that the edit in TM command also works right from within the Bundles editors plist textarea field. (Pressing the Test button after regaining focus nicely reformats the code very convenient.Not to mention the Syntax check.)
What I really wanted, was weather there are any additional documentation resources about the syntax that are not available from the manual/help menu.
regards, marios
On 27/5/2006, at 18:57, marios buttner wrote:
[...] What I really wanted, was weather there are any additional documentation resources about the syntax that are not available from the manual/ help menu.
There are no official alternative resources.
The manual should be exhaustive when it comes to a) documenting the plist format [1] and b) documenting the language grammar keys [2].
[1] http://macromates.com/textmate/manual/appendix#property_list_format [2] http://macromates.com/textmate/manual/language_grammars
-
Allan Odgaard -
marios buttner