I would really appreciate an enhanced syntax highlight for embedded languages. I often edit code that includes HTML, JavaScript, PHP and even SSI in one single document.
The system could use a separate syntax file for each language and provide extended attributes to know when to use each one: file extension and maybe a regular expression to indicate tags. Pseudo-code example:
JavaScript:
*.html, *.htm, *.shtm, *.php: <script language="javascript" ........>*</script>
*.js: *
PHP:
*.php,*.php3,*.php4: <?*?>, <?PHP*?>, <script languaje="php"...>*</script>
I know it'd be kind of difficult to implement but it'd be pretty useful.
Syntax highlight for embedded languages
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
Am I correct in thinking that this would solve the problem of having HTML code highlighted differently from JSP inside a JSP file?
e.g.:
<% if ( foo = true ) { %>
<a href="http://www.textpad.com">Textpad Site</a>
<% } %>
e.g.:
<% if ( foo = true ) { %>
<a href="http://www.textpad.com">Textpad Site</a>
<% } %>
-
- Posts: 5
- Joined: Wed Jun 18, 2003 3:27 pm
I think this would be EXCELLENT, i often edit html files that contain javascript. Or php files that has php and html mixed (and javascript .
THe main problem would be reliably detecting the change in language (as its correct interperter would). For example javascipt exists in handers (eg onclick) as well as in script blocks. Also would be nice but not so important if html code in echo or print blocks in php (and perl) would be similerly highlighted.
THe main problem would be reliably detecting the change in language (as its correct interperter would). For example javascipt exists in handers (eg onclick) as well as in script blocks. Also would be nice but not so important if html code in echo or print blocks in php (and perl) would be similerly highlighted.
I'm mostly interested in HTML in Java (JavaDoc in a .java file), Java in HTML (JSP), and JavaScript inside HTML. All three are pretty well defined.
I certainly don't expect more than two types of languages highlighted at any one time. In other words, I don't expect JavaScript in HTML in Java to all be highlighted. Only one super-language (Java in this case) with only one sub-languge (HTML in this case) at a time.
I wonder the impact and difficulty this places on the TextPad development process, and if it is even doable for version 5. Anyone familiar with Visual C++ development (which is the language of TextPad, according to Kieth)? Is there any way to do this efficiently, so TextPad doesn't bloat or slow down too much?
I certainly don't expect more than two types of languages highlighted at any one time. In other words, I don't expect JavaScript in HTML in Java to all be highlighted. Only one super-language (Java in this case) with only one sub-languge (HTML in this case) at a time.
I wonder the impact and difficulty this places on the TextPad development process, and if it is even doable for version 5. Anyone familiar with Visual C++ development (which is the language of TextPad, according to Kieth)? Is there any way to do this efficiently, so TextPad doesn't bloat or slow down too much?
embedded languages for syntax highlighting
this is an important feature for me also, as I often work in markup languages that have script and/or style blocks.
I think the most useful solution might be IMPORT capability for syntax files, that would allow you to import one or more syntax definitions and apply them in addition to the primary one.
A difficulty in implementing this would be that you would have potentially unlimited numbers of namespaces associated with a syntax, but that might be gotten round by required that the imported types be registered as separate document classes.
-- Robert
I think the most useful solution might be IMPORT capability for syntax files, that would allow you to import one or more syntax definitions and apply them in addition to the primary one.
A difficulty in implementing this would be that you would have potentially unlimited numbers of namespaces associated with a syntax, but that might be gotten round by required that the imported types be registered as separate document classes.
-- Robert