headers
Lindsay Haisley | 8 Apr 2009 20:27
Favicon

Re: New bflang2 language highlighting for Smarty

On Fri, 2009-04-03 at 01:55 +0300, alex bodnaru wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> hi Lindsay, everybody,
> 
> that's a very important feature in my opinion too, that might open options for
> multiple html template languages as well.
> 
> one question/reminder: did you treat js and css as includable languages as well?

In Smarty templates, these languages need to be exempted altogether from
template processing since they make use of curly braces, which are also
the tag delimiters for Smarty template processing commands.  Smarty
therefore defines a pair of template tags, "{literal}" and "{/literal}",
which delimit sections of code which the Smarty engine will skip over.
smarty.bflang2 handles this by defining a context between these
delimiters where the contents of all-html.bfinc are included, and
all-html.bfinc handles css and js since it's pulled from html.bflang2.

So the answer to your question is no, because js and css are already
included in all-html.bfinc.  They _could_ be treated as nested language
contexts, but this wasn't necessary in smarty.bflang2.

The bflang2 paradigm seems to make the implementation of nested language
contexts a bit awkward, to say the least. There needs to be some way of
unambiguously defining language contexts for which the defining
delimiters trump _any_ context in which they occur and switch into or
out of that language context.  I ran into this in working on the "{php}"
(Continue reading)

Permalink | Reply |
headers
Olivier Sessink | 8 Apr 2009 22:01
Picon
Gravatar

Re: New bflang2 language highlighting for Smarty

Lindsay Haisley wrote:
[..]
> The bflang2 paradigm seems to make the implementation of nested language
> contexts a bit awkward, to say the least.
[..]

There is a reason for that. The bflang2 format is not a format to define
a language. It is a format to configure the bluefish scanning engine. It
is designed such that the language file can be parsed top to bottom to
compile the state tables for the scanning engine in one go.

All patterns in each context are compiled into one DFA table (a binary
scanning table which allows extremely fast scanning). So two contexts
that have 100 equivalent patterns, and 1 different pattern, need to be
compiled in two separate DFA tables. Only if ALL patterns in a context
are equivalent a DFA table can be re-used.

So if one context has pattern ?> and the other has {/php} there need to
be two different DFA tables.

regards,
	Olivier
Permalink | Reply |
headers
Lindsay Haisley | 8 Apr 2009 22:23
Favicon

Re: New bflang2 language highlighting for Smarty

On Wed, 2009-04-08 at 22:01 +0200, Olivier Sessink wrote:
> Lindsay Haisley wrote:
> [..]
> > The bflang2 paradigm seems to make the implementation of nested language
> > contexts a bit awkward, to say the least.
> [..]
> 
> There is a reason for that. The bflang2 format is not a format to define
> a language. It is a format to configure the bluefish scanning engine. It
> is designed such that the language file can be parsed top to bottom to
> compile the state tables for the scanning engine in one go.
> 
> All patterns in each context are compiled into one DFA table (a binary
> scanning table which allows extremely fast scanning). So two contexts
> that have 100 equivalent patterns, and 1 different pattern, need to be
> compiled in two separate DFA tables. Only if ALL patterns in a context
> are equivalent a DFA table can be re-used.
> 
> So if one context has pattern ?> and the other has {/php} there need to
> be two different DFA tables.

*.bfinc files essentially define a language for the BF scanning engine,
and the re-use of code they allow is a programming convenience.  If it's
awkward and doesn't result in any run-time savings, then perhaps
multiply nested such includes are best left alone.

I answered Alex's question as far as smarty.bflang2 is concerned.
Recursive includes for CSS and JavaScript aren't implemented and aren't
needed.
(Continue reading)

Permalink | Reply |
headers
Olivier Sessink | 9 Apr 2009 00:30
Picon
Gravatar

Re: New bflang2 language highlighting for Smarty

Lindsay Haisley wrote:
> On Wed, 2009-04-08 at 22:01 +0200, Olivier Sessink wrote:
>> Lindsay Haisley wrote:
>> [..]
>>> The bflang2 paradigm seems to make the implementation of nested language
>>> contexts a bit awkward, to say the least.
>> [..]
>>
>> There is a reason for that. The bflang2 format is not a format to define
>> a language. It is a format to configure the bluefish scanning engine. It
>> is designed such that the language file can be parsed top to bottom to
>> compile the state tables for the scanning engine in one go.
>>
>> All patterns in each context are compiled into one DFA table (a binary
>> scanning table which allows extremely fast scanning). So two contexts
>> that have 100 equivalent patterns, and 1 different pattern, need to be
>> compiled in two separate DFA tables. Only if ALL patterns in a context
>> are equivalent a DFA table can be re-used.
>>
>> So if one context has pattern ?> and the other has {/php} there need to
>> be two different DFA tables.
> 
> *.bfinc files essentially define a language for the BF scanning engine,
> and the re-use of code they allow is a programming convenience.  If it's
> awkward and doesn't result in any run-time savings, then perhaps
> multiply nested such includes are best left alone.
> 
> I answered Alex's question as far as smarty.bflang2 is concerned.
> Recursive includes for CSS and JavaScript aren't implemented and aren't
> needed.
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 9 Apr 2009 04:08
Favicon

Re: New bflang2 language highlighting for Smarty

On Thu, 2009-04-09 at 00:30 +0200, Olivier Sessink wrote:
> easier maintaining is a good thing indeed. So what we can do right now 
> with the bfinc files is very useful. But I don't think we should alter 
> the language format to make maintenance easier but loading slower and 
> more complex.

Well right away, without modifying the language format, both
html.bflang2 and php.bflang2 could be altered to "pull in" updated
versions of all-html.bfinc and all-php.bfinc.  This would give us 3
bflang2 files which could depend on these included files.  A 4th would
be asp.bflang2, although I don't work with asp (I'm strictly an Open
Source man) so someone else would have to do this work.

--

-- 
Lindsay Haisley       | "Everything works if you let it"
FMP Computer Services |   (The Roadie)
512-259-1190          |
http://www.fmp.com    |
Permalink | Reply |
headers
Olivier Sessink | 10 Apr 2009 10:51
Picon
Gravatar

Re: New bflang2 language highlighting for Smarty

> On Thu, 2009-04-09 at 00:30 +0200, Olivier Sessink wrote:
>> easier maintaining is a good thing indeed. So what we can do right now
>> with the bfinc files is very useful. But I don't think we should alter
>> the language format to make maintenance easier but loading slower and
>> more complex.
>
> Well right away, without modifying the language format, both
> html.bflang2 and php.bflang2 could be altered to "pull in" updated
> versions of all-html.bfinc and all-php.bfinc.  This would give us 3
> bflang2 files which could depend on these included files.  A 4th would
> be asp.bflang2, although I don't work with asp (I'm strictly an Open
> Source man) so someone else would have to do this work.

we have several alternatives to do this:

create for example an include file with only the list of all PHP
functions. This allows other languages to add a different <group> header
around the list, and thus specify different options (autocomplete
on/off?).

we could do the same for css and for javascript.

for html it is slightly more difficult, because certain tags start the css
and javascript contexts.

what is the best practice?

Olivier

--

--
(Continue reading)

Permalink | Reply |

Gmane