While we were working on the new sugar standards specs, we ran up against a problem: I was adamantly against providing a category for “builtin functions”. I was of the point of view that only keywords would be hardcoded into the syntax file, because unlike built-in functions, they were an actual part of the syntax of the language.

However, good points were brought up - it turns out that PHP programmers are used to having their built-in functions hilighted by their text editor. As it is, we can only apply CSS selectors that select Syntax elements as defined in Syntax.xml files. The problem is this leads to horrible zones, like this one extracted from the official JavaScript Sugar:

Yes, downright ridiculous.

We realized after some discussion that we were *already* maintaining a list of all of the built-in/stdlib functions in our Sugars! CodeSense!

So, to solve this problem, the simplest solution is to allow Themers to hilight items of CodeSense.

Jan? Please? I can’t imagine that this would be too hard to implement, and it’d really allow us to keep our Syntax.xml files clear of this silliness without pissing off PHP and C programmers, who have hundreds if not thousands of built-in functions they need to be hilighted.

I can see two ways of doing this:
a) Have some sort of variable that can be inserted into a regex containing an alternation, eg: /\b({$net.fileability.c.function-names})\b/ The regex would then be preprocessed by espresso.
b) Don’t use regexes at all, but allow some way to specify that a code sense library should have a syntax zone (faster but less powerful)

alexgordon - 19 January 2009 06:15 AM

I can see two ways of doing this:
a) Have some sort of variable that can be inserted into a regex containing an alternation, eg: /\b({$net.fileability.c.function-names})\b/ The regex would then be preprocessed by espresso.
b) Don’t use regexes at all, but allow some way to specify that a code sense library should have a syntax zone (faster but less powerful)

I was hoping to have nothing to do with syntax zones at all - because they’re not, technically, the syntax of the language. Any more than x becomes a part of the syntax of the language when I type “x = 1”.

I want to see a specific selector for CodeSense in the themer’s toolkit - not see CodeSense imported into the Syntax.xml

But maybe that’s just me.

elliottcable - 19 January 2009 06:19 AM

alexgordon - 19 January 2009 06:15 AM

I can see two ways of doing this:
a) Have some sort of variable that can be inserted into a regex containing an alternation, eg: /\b({$net.fileability.c.function-names})\b/ The regex would then be preprocessed by espresso.
b) Don’t use regexes at all, but allow some way to specify that a code sense library should have a syntax zone (faster but less powerful)

I was hoping to have nothing to do with syntax zones at all - because they’re not, technically, the syntax of the language. Any more than x becomes a part of the syntax of the language when I type “x = 1”.

I want to see a specific selector for CodeSense in the themer’s toolkit - not see CodeSense imported into the Syntax.xml

But maybe that’s just me.

alexgordon - 19 January 2009 06:23 AM

I completely disagree. Code sense should go in the syntax.

But… it’s not syntax. That’s simply not semantic. And non-semanticity is the devil.

alexgordon - 19 January 2009 06:23 AM

To the themer, there should be no noticeable difference between regex provided zones and code sense provided zones.

Then do that on the Espresso end, so that Syntax and CodeSense “goes in”, and then (from the themers point of view), one accessor system “comes out”. Details up to Jan, I don’t really have any good ideas.

But I don’t want to have to put anything in my Syntax.xml at all that doesn’t actually refer to a real element of syntax - including lines that simply refer to CodeSense data.

elliottcable - 19 January 2009 06:43 AM

alexgordon - 19 January 2009 06:23 AM

I completely disagree. Code sense should go in the syntax.

But… it’s not syntax. That’s simply not semantic. And non-semanticity is the devil.

alexgordon - 19 January 2009 06:23 AM

To the themer, there should be no noticeable difference between regex provided zones and code sense provided zones.

Then do that on the Espresso end, so that Syntax and CodeSense “goes in”, and then (from the themers point of view), one accessor system “comes out”. Details up to Jan, I don’t really have any good ideas.

But I don’t want to have to put anything in my Syntax.xml at all that doesn’t actually refer to a real element of syntax - including lines that simply refer to CodeSense data.

Oh, I understand, for keywords, sure.

I was talking about for functions, which was my main worry. I hadn’t even considered keywords - in the languages causing the problem here (C, PHP) there are far more built-in functions and standard library functions than there are actual keywords that should be in the syntax definition.

elliottcable - 19 January 2009 06:52 AM

Oh, I understand, for keywords, sure.

I was talking about for functions, which was my main worry. I hadn’t even considered keywords - in the languages causing the problem here (C, PHP) there are far more built-in functions and standard library functions than there are actual keywords that should be in the syntax definition.

It’s pretty ridiculous. If they were in a code sense library, it would be much more manageable. I suppose my point is, functions aren’t the only thing which this could be used for.

This is a must!

I think maybe having something like this within zones: <codesense>function.builtin</codesense>, to replace <expression> when necessary would be the way to go. It would look for the appropriate list in the code sense file.