Add phan configuration for static analysis, and fix phan warnings.
`PhanDeprecatedClass` and `PhanDeprecatedFunction` rules are supressed.
Bug: T179554
Change-Id: I7cbb410ed88ba58198d0557cafd9e6df968ed885
This makes installation easier for local development.
Per https://www.mediawiki.org/wiki/Manual:External_libraries
I was supicious about whether 'use KzykHys\Pygments\Pygments;'
works in a file if the namespace/class itself is only loaded
later, but it works fine.
Ref T103890.
Change-Id: Ia1a577f555cd8ab09969dec219316bc1e76769f4
GeSHi is unmaintained, lacks support for many popular modern languages, and
suffers from deep architectural flaws, chief among them the inconsistent
tokenization of different languages, each of which requires a custom
stylesheet.
Pygments is a well-maintained alternative. It is, by my count, the most popular
syntax highlighting library around. It is BSD-licensed, actively maintained,
and is widely used in PHP projects.
To keep this easy to review, this change does not include update for l10n
files, and it does not delete the geshi/ directory. I will do those in a
separate patch.
The chief change between this and the previous implementation is that errors
result in the code block not being highlighted, as opposed to not being printed
at all, having been replaced by an angry red error message. I think that is the
right user experience. If you go to StackOverflow or GitHub and try to mark up
your code block as being written in some language that their highlighter
doesn't know about, you don't get an error message -- the code simply doesn't
get highlighted.
Because we don't recursively load dependencies for extensions, to test this,
you will need to create a composer.local.json in $IP and add:
{
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json"
]
}
}
}
Then run `composer update`.
Bug: T85794
Change-Id: I07446ec9893fae3d1e394f435d3d95cf8be6bc33
