[TxMt] lang grammar regex and complex language constructs

Sun May 21 14:32:37 UTC 2006

-----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)
> 
>> 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 ?
> 
> 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.

> 
>> 5) [...] 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 at 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

  ________________      __         _
 / ___/ __/ __/ _ \___ / /_ ______(_)_ ____ _
/ /___\ \_\ \/ // / -_) / // / __/ / // /  ' \
\___/___/___/____/\__/_/\_, /_/ /_/\_,_/_/_/_/
                       /___/

-----BEGIN PGP SIGNATURE-----
Comment: This might change in the future
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEcHmI8tSzPOYuZvQRAsyRAKC5e+qWijWjsq1dQ78SjNDbqCy4HQCfTHft
KbHn2QQjj899nesLvKd6TAQ=
=jdBl
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.macromates.com/textmate/attachments/20060521/2980ea38/attachment.asc>