Apache .conf scheme

[SynCap]

lets rock!
today I'd found hE. well, it's are coolest and balanced code editor i've seen...

not all is cool in my scheme, but it's shine, folds and suggests.

as base distributed xml scheme was used

TODO:
1. checking allowed params for derectives,
2. more strict folow for rules
3. check directives and common values lists

[alex]

Hi SynCap,

Perfect, very good job. I have tested it with my httpd.conf - works immediately.

I think EscapeChar is also needed (for stings) in SPECIFICATION.

Code Select Expand

      <EscapeChar>\</EscapeChar>     

Also can be added but better with Labels

Code Select Expand

      <Scope  open="IfModule" close="IfModule" has_name="true"/>

Also I think, will be good to add Labels definition for quick navigation between config areas (I will provide some examples tomorrow).

Adding of the intellectual completion of values will be difficult: there are not too many possibilities to define areas where and what is allowed (regular expressions are not supported yet). but maybe this can be solved with scripting support coming in 1.50.
But in any case, just ask in every particular case and I will do my best to help.

The license for HippoEDIT already sent to you

[SynCap]

hi.
thanx for license, very glad and really nice surprised.

it seems to be easy to make suggest allowed common values for conf files: I think to begin named scope on directive end, wich will ends with \n
just lot of coding and scheme will grows up to be heavier than all *.conf files together

I really know how make documentation  more useful: just add the water, sorry - examples and illustrations to each instruction, and comments to scheme files.

One more: I think, that using XML format to store shemes is not absolutely needed. What about to use alternatives, JSON or YAML? May be in parallel with existing XML?
That lets easier way to keep existing shcemes, and the same time - easier way to read and understand code of sheme files, because of clean posibilities of commenting.

[alex]

it seems to be easy to make suggest allowed common values for conf files: I think to begin named scope on directive end, wich will ends with \n just lot of coding  and scheme will grows up to be heavier than all *.conf files together

Yes, you are absolutely right. I thought about exactly this if you would ask me . I have done something similar in css_spec.xml, but there it was a little bit more easier and also do not go very deep, because then you need to define all attributes and so on and this is huge work
So, I think, the right way will be auto-completion glued with scripting. And performance will be acceptable for small documents.

I really know how make documentation  more useful: just add the water, sorry - examples and illustrations to each instruction, and comments to scheme files.

I also know ) And documentation also. The only matter of time: I need to select between bug fixing, development of the new features, support or documentation development . I will try to ad this when I will have free time (but maybe wiki for this purpose will be better). Here is post from Stefan with some explanations.
Comments for schema files. Yes, that can be added. maybe for main schema parts. Or just create a template schema with comments inside.

One more: I think, that using XML format to store shemes is not absolutely needed. What about to use alternatives, JSON or YAML? May be in parallel with existing XML?
That lets easier way to keep existing shcemes, and the same time - easier way to read and understand code of sheme files, because of clean posibilities of commenting.

Changing from XML as a storage format will be huge effort (I have all serialization framework based on this). Initial selection of it was done because of popularity, it is most standard way for storing structured data, there are a lot of ready parsers in any language, a lot of browsers have  built in possibility for XSLT transformation of XML (so I can get HTML presentation of syntax schema easier). And in 2002 (when HE was started) JSON was not yet known.
As alternative I can only add one more layer in coding which will transform JSON into XML before reading/saving... But if this is more important than new features ?

[SynCap]

along with task of intellisence suggestions:
why not to organize keyword's scopes?
for example, each apache directive may have some predefined values - On, Off, allow, yes, no etc, and some directives may have values in similar sets, i.e. [yes, no], or [allow, disallow, none] etc
when we describe some directive we start some named scope to wich we attach the scope of another scopes: set of keywords, named set of keywords, set of allowed scopes or styles.

I see that this is global idea on algorithmes of parsing, may be somewhen in not so far future ...

[alex]

Code Select Expand

If I understood you right, this is already exist and controlled by style [i]containers[/i].
When you define style and then use <Containers> node, you tell engine in which other style [i]this[/i] style can be used. So keywords of [i]this[/i] style will be only recognized/suggested in the style found in containers.

As example you can check entities definition in XML:
[code]      <Style id="entity" name="Entities" bold="1" italic="0" underline="0" clr="#FFFFFFFF" bkclr="#FFFFFFFF">
        <Containers>
          <Open id="normal"/>
          <Open id="string"/>
        </Containers>
        <Blocks>
          <Block open="&amp;" close=";">
            <Close text=""/>
          </Block>
      </Style>
      <Style name="Entities Values" bold="1" italic="0" underline="0" clr="#FFFFFFFF" bkclr="#FFFFFFFF">
        <Containers>
          <Open id="entity"/>
        </Containers>
        <Keywords>
          <Keyword text="aacute"/>
          .....
          <Keyword text="yuml"/>
        </Keywords>
      </Style>


Here keywords of Entity values are only allowed inside "entity" style defined before.
If you will apply this to apache case can be something like this:
<Style id="paramater1" name="Entities" bold="1" italic="0" underline="0" clr="#FFFFFFFF" bkclr="#FFFFFFFF">
        <Blocks>
          <Block open="SuperDuperParam " close="\n"/>
      </Style>
      <Style name="SuperDuperParam Values" bold="1" italic="0" underline="0" clr="#FFFFFFFF" bkclr="#FFFFFFFF">
        <Containers>
          <Open id="paramater1"/>
        </Containers>
        <Keywords>
          <Keyword text="On"/>
          <Keyword text="Off"/>
        </Keywords>
      </Style>
[/code]
I think this what you have mentioned before.

If you have in mind something else (I think so), then please show the example of definition in HE schema terms (part of XML).
Finding right rule description is rather hard stuff (not talking about implementation ).

[alex]

I have been uploaded Apache conf schema to the library.
I have added some example labels, number style and escape symbol.

Can you please check it, if everything is OK? Maybe some more useful labels can be added?
To check functionality of labels, you need to open Navigation Bar (Alt+M), then filter by substring + enter.

[SynCap]

Thanx, i've saw it already. Perfect! Just like a doctor's prescription!
A bit modifications:
1. style "numbers" added, to modify behovoir of showing numbers in scope headers
2. images swaped in "Directory" label & "ServerName" - i thnk it looks more readable in navigation dropdown list
3. killed [italic="1"] in "comments"
somthig bit else...

[alex]

Everything is OK, I diff-ed changes.

Images were selected for example, you can use any from the standard set or attach your image set. More important that all main points from the conf file will be in label list (I am not very big specialist here, though I am using it in local site) to simplify navigation.

Italic style for comment was changed only in user extension (apache_user.xml). Normally, if I have user file in standard bundle, it only contains default template, tools and context help items. So I have not included yours but have changed spec file (which contains schema defaults) to have comments without italic.

number style was also twice defined. I have removed old definition.

I have uploaded your updated version to server.

[SynCap]

non-italic comments - is just my own quirk, i've kill them all in all schemas, even in spec files . Also got the new color scheme based up "eclipse colors" namespace - because I hate green italic comments and maroon common keywords.
I've read about images & took them in mind, btw - very nice idea, never seen it in elsewhere.
Just this time i got brainstorming - in INI scheme in Value names, that contains hyphen, highlited only part just before equal sign.
I think - if i solve this weak in elegant manner, i'll do some changes in apace scheme.
BTW - in cumulative pack of all schemas are included some "uneccessary" files, such as *.chm - check them, surplus files seriously enlarge the pack.

[alex]

For INI schema, just insert this in SPECIFICATION node:

Code Select Expand

      <Words>0-9A-Za-z_--</Words>
Generally, this is not needed 0-9A-Za-z_ because it is inherited from default schema, but in such way it is more clear...
I will also updated default ini_spec.xml.

About *.chm file. It is used in Vip schema (ERP Galaktika) and defined for it as dependency. That is why it is why it is also packed. But maybe I can skip such big files when packing all syntaxes.

[SynCap]

<Words>0-9A-Za-z_--</Words>

i didn't like this solve, because this change behovoire of values and strings

it's clean, that chm was integrated as shceme dependant help file, but who really use some language - they have its own docs, it's too obtrusive to submit big files when scheme nedded. in short words - spam, i.e. unsolicited content

[alex]

i didn't like this solve, because this change behovoire of values and strings

Why? This control which characters should be included in keywords. Additional consequences will be word selection (Ctrl+Click, ExpandSelection, word right/left) will include -, statistics will collect all words together with -, completion also.
But do not see how strings are influenced...

it's clean, that chm was integrated as shceme dependant help file, but who really use some language - they have its own docs, it's too obtrusive to submit big files when scheme nedded. in short words - spam, i.e. unsolicited content

it is removed