Thanks for your language file. Please recheck it with the langcheck script that ships with recent releases of GeSHi to check the language file to be okay.
On a second note: Please stay from using .+ in REGEXP sections. That's a REALLY bad habbit and may cause huge problems. Please reply with a general description (possibly with some small samples) to look for a better solution to this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've double-checked the language file and agree with it. It doesn't pass langcheck because TAB characters have been used .. easily fixed with a 's/^I/ /g'. I've had a look at the .+, too, and would tend to agree with that as well. What are your reasons against it?
Short example:
dn: o=ex,o=ample
objectClass: organization
objectClass: top
o: ex
Fixed the tabs locally already; that's not the big issue.
The reason against the .+ is the missing end delimiter. You risk double highlighting which causes invalid output in certain situations. If you have (like LDIF) a line based format that end delimiter should be clearly visible from within the regexp.
Another improvement I'd like to see would be to have standard items in a keyword group as can be seen in the email.php language file (rfc821 implementation).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't consider the missing end delimiter an issue - it will always be until EOL. You can't really make a list of standard items - there are none. Any list would be largely arbitrary, and only fitting to some of the common usecases. Being more generic is better here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the syntax defines only til EOL your Regexp should express exactly this: .+?$ - otherwise it can easily cause problems.
And regarding lists: RFC821 which I based the email language file on doesn't do any specifications on field neither, but there are some fields you'd probably find in such a source. One purpose for keyword groups is providing documentation to such known items which only works if they are provided. And as LDIF mostly is used with LDAP servers providing authentication or an enhanced address book the ldif language file should reflect this. Marking common items vs. non-standard items always brings you an advantage. Even the whois language file (which highlights a format nearly as arbitrary as LDIF) marks common grounds. Keyword in the sense GeSHi understands it just means "identifier commonly used to mark something".
And if there are common usecases (e.g. authentification and address book) that have differing fields: Just do multiple keyword groups and people can decide which to use in their case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LDIF language file
Thanks for your language file. Please recheck it with the langcheck script that ships with recent releases of GeSHi to check the language file to be okay.
On a second note: Please stay from using .+ in REGEXP sections. That's a REALLY bad habbit and may cause huge problems. Please reply with a general description (possibly with some small samples) to look for a better solution to this.
I've double-checked the language file and agree with it. It doesn't pass langcheck because TAB characters have been used .. easily fixed with a 's/^I/ /g'. I've had a look at the .+, too, and would tend to agree with that as well. What are your reasons against it?
Short example:
dn: o=ex,o=ample
objectClass: organization
objectClass: top
o: ex
(more on http://en.wikipedia.org/wiki/LDAP_Data_Interchange_Format\)
I'd recommend taking it into the distribution 'as is', after replacing the TAB characters to comply with the style guide.
Fixed the tabs locally already; that's not the big issue.
The reason against the .+ is the missing end delimiter. You risk double highlighting which causes invalid output in certain situations. If you have (like LDIF) a line based format that end delimiter should be clearly visible from within the regexp.
Another improvement I'd like to see would be to have standard items in a keyword group as can be seen in the email.php language file (rfc821 implementation).
I don't consider the missing end delimiter an issue - it will always be until EOL. You can't really make a list of standard items - there are none. Any list would be largely arbitrary, and only fitting to some of the common usecases. Being more generic is better here.
If the syntax defines only til EOL your Regexp should express exactly this: .+?$ - otherwise it can easily cause problems.
And regarding lists: RFC821 which I based the email language file on doesn't do any specifications on field neither, but there are some fields you'd probably find in such a source. One purpose for keyword groups is providing documentation to such known items which only works if they are provided. And as LDIF mostly is used with LDAP servers providing authentication or an enhanced address book the ldif language file should reflect this. Marking common items vs. non-standard items always brings you an advantage. Even the whois language file (which highlights a format nearly as arbitrary as LDIF) marks common grounds. Keyword in the sense GeSHi understands it just means "identifier commonly used to mark something".
And if there are common usecases (e.g. authentification and address book) that have differing fields: Just do multiple keyword groups and people can decide which to use in their case.