state of the project?

[splitbrain]

Is this project still actively maintained? We make extensive use of this library in DokuWiki and I'd like to have a place where to point people to with language updates.

Would you consider adding more maintainers to get this at least into a state where minimal changes (language fixes, PHP compatibility updates, etc.) get applied? I'd be happy to help with that.

Here are the things I think should be done:

• go through the pull requests and merge the core bug fixes Fix error state when setting existing language after non-existing #1 Fixup/Add parameter names to docblock comments #38 synced GNU 2.0 license with current version from gnu. #70 Added FNAME ucfirst #71
• go through the pull requests and merge all the language additions/fixes Add support for QML syntax #19 Update css.php #20 Added Mathematica syntax file #22 Add the Mercury language (http://www.mercurylang.org) #29 Update vb.php #44 Added Swift support #47 Improve T-SQL syntax highlighting #49 Updated autoit.php from latest AutoIt release. #51 new language (phix) #52 Added Julia syntax file #55 Fix Lua comment blocks and string blocks. #63 add support for Kotlin #75
• fix langcheck errors for existing languages
• remove old build scripts (referencing sourceforge and SVN)
• move contrib and docs out of src
• move non-api docs to github wiki
• move real api docs to github pages
• make the script a little more modern by using proper public/protected attributes
• introduce a namespace
• remove any workarounds for php lower than 5.6
• have some initial minimal testing in place
• tag this as 1.0.9.0 and make it available via packagist Packagist #62

Again, I'm happy to do this if I get the feedback that it would be welcome and be merged quickly.

[cweiske]

A namespace will no be introduced since it will break backwards compatibility. Use geshi-1.1 for that.

What I would really miss is unit tests that tell me if a patch breaks things :/

[splitbrain]

Yeah. Unit tests would be awesome, but I don't know enough about the GeSHi internals to do that. However I thought about two things that would be relatively easy:

1. dogfood the geshi source through geshi and simply check that a few keywords are in the resulting output -- this would ensure at least the PHP compatibility and catch possible syntax errors.
2. use the checklang.php mechanism in a unit test

When both are in place it could be set up at travis and you could at least see if new PRs violate those basic things already. Eg. I had to fix most of the language additions becasue checklang found some issues

[cweiske]

unit tests would be too much,yes. I thought about having a set of source test files and their expected output, which gets compared by phpunit.

But having checklang in travis would also help, yes.

[splitbrain]

@cweiske I started working on unit testing as outlined above. Can you have a look at my questions here: splitbrain-forks#1

[splitbrain]

I converted the geshi-doc.html document to markdown, manually fixed stuff and added the contents (mostly) to the wiki. I left out stuff that very obviously needs rewriting. A new table of contents linking to the various documents should be created on the Home page. And of course all the pages need some work, but now the community could step in.

[splitbrain]

I'm closing this in favor of #79 #81 and #82