headers
Lindsay Haisley | 1 Apr 2009 20:08
Favicon

New bflang2 language highlighting for Smarty

I've put together a bflang2 languge highlighting definition file for
Smarty templates.  Smarty is template engine which allows the separation
of presentation logic from processing logic in PHP-enabled web sites.
The Smarty template language is basically a superset of HTML and can
theoretically contain PHP code as well.

The smarty.bflang2 file is in the latest SVN revision in the data
directory, and uses a code-reuse scheme suggested by Daniel which might
prove potentially useful for other bflang files as well, and would
allow, for instance, all bflang2 files which define html highlighting to
be kept current with the language by updating the inclusion rather than
each one separately.  smarty.bflang2 contains these two lines:

   <!ENTITY all-html SYSTEM "all-html.bfinc">
   <!ENTITY all-php SYSTEM "all-php.bfinc">

The all-html entity, extracted from html.bflang2, is used twice and
all-php is used once.  The files all-html.bfinc and all-php.bfinc are
required to be in the same directory with smarty.bflang2.

I've also re-written html.bflang2 and php.bflang2 to use these as well,
so that all-html.bfinc becomes the HTML core language definition file
for HTML, apart from the header and other bluefish related code.  I've
done the same for PHP in all-php.bfinc which encapsulates all the
language definition elements from php.bflang2.  Both the modified
html.bflang2 and php.bflang2 work as expected.  They're not in SVN, but
can easily be re-created for testing.

Comments and suggestions are requested.
(Continue reading)

Permalink | Reply | 7 comments |
headers
alex bodnaru | 3 Apr 2009 00:55
Picon
Gravatar

Re: New bflang2 language highlighting for Smarty


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?
these are languages in their own right, that might be embedded in web pages
also. to this respect, plase note that </script> would end a js block abruptly,
no matter of the correctness or completeness of the embedded js code. this may
well happen within a string literal or a comment block in js. i believe the same
happens with css blocks, but these might get embedded in style html attributes,
as well as in <style> tags.
if yes, could php be embedded in js too?

Lindsay Haisley wrote:
> I've put together a bflang2 languge highlighting definition file for
> Smarty templates.  Smarty is template engine which allows the separation
> of presentation logic from processing logic in PHP-enabled web sites.
> The Smarty template language is basically a superset of HTML and can
> theoretically contain PHP code as well.
> 
> The smarty.bflang2 file is in the latest SVN revision in the data
> directory, and uses a code-reuse scheme suggested by Daniel which might
> prove potentially useful for other bflang files as well, and would
> allow, for instance, all bflang2 files which define html highlighting to
> be kept current with the language by updating the inclusion rather than
> each one separately.  smarty.bflang2 contains these two lines:
--
--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Olivier Sessink | 8 Apr 2009 09:01
Picon
Gravatar

edit->replace special menu getting very long

Hi all,

the 'replace special' menu is getting quite long with all the new
functions. Especially if you have the entities plugin enabled there are
13 entries in the menu.

Should we start a new main menu item 'Tools' or something like that?

regards,
   Olivier
Permalink | Reply | 1 comment |
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 | 5 comments |
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 | 4 comments |
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 | 3 comments |
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 | 2 comments |
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 | 1 comment |
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 | 0 comments |
headers
alex bodnaru | 10 Apr 2009 19:20
Picon
Gravatar

Re: New bflang2 language highlighting for Smarty


-------- Original Message --------
Subject: bflang2 for compound languages
Date: Fri, 30 Jan 2009 05:57:30 +0200
From: alex bodnaru <alexbodn@...>
Reply-To: bluefish-dev@...
To: bluefish-dev@...
References: <497E2CFA.7040708@...>
<497F6BCC.8080002@...>

hi olivier, friends,

i'd like to put the basis for multilanguage for bflang2.

i see 2 main ways different languages may interact:

1. extension: c++ extends c, and asp/php/client_side_scripts extends html. i
would express this kind of relationship by:
  a. definition of some elements and contexts for lang2
  b. language lang2 extends lang1 by adding the previously defined elements and
contexts to [optionally certain] context(s) of lang1. here, the starting point
of the lang2 contexts should be appended as elements in the given lang1
context(s), and the additional contexts should be inserted in the final bflang2.
  c. language lang2 may void support for certain elements in [optionally
certain] contexts of lang1. think java extends c++ cut doesn't support pointers etc.

2. embedding: javascript and vbscript are good examples of languages that may be
used on their own, or optionally embedded to extend (see above) other programs,
like html web ages.
but before actually extending the html, the embedded language should be
(Continue reading)

Permalink | Reply | 752 comments |

Gmane