When the GrepFiltered sub was removed, we didn't check our modules. As
it turns out, tags.pl and mac.pl hooked into this sub to do their job. A
simple no-op Filtered sub was reintroduced for those modules.
Also, all instances of $UseGrep were removed.
The EN DASH is not really required in year ranges such as 2012–2015 when
we're talking about comments in source code that is probably being
displayed in a fixed font anyway. Changing back to an ordinary hypen
allows us to make a meaningful test for use utf8.
Issues:
- the Mac layer was masking issues because of the NFC/NFD difference and existing compatiblity hacks in mac.pl
- drafts.pl was suffering from a double encoding issue
- crossbar.t and download.t tests were failing because I had recently fixed DoDownload output to be raw instead of encoded
- test.pl now has a way to capture the raw, unencoded output produced by DoDownload
- tags.t got some tests to prove that recent changes to wiki.pl actually work
Drafts are saved using the username as filename. This must also be
encoded and decoded correctly. Because of NFC and NFD issues on Mac
HFS, an appropriate normalization was added to mac.pl.
As the username is also part of the cookie, this showed that the
Cookie content wasn't being encoded correctly, so that was fixed, too.
All the source files containing non-ASCII characters needed to have
utf8 added. This will be necessary for user config files as well! The
regular expressions identifying page names had to be changed.
UrlEncode translates the string back to bytes before encoding it.
Cached RSS files are saved with UTF-8 encoding and therefore need
their meta-data changed (using the XML::RSS module to do this
correctly didn't work for some of the test files). The CGI object's
parameters, keywords and info_path are decoded correctly. File access
uses the UTF-8 layer (reading, writing, appending, access to the log
of recent changes, running sub processes with grep and diff).
The mac compatibility extension will also disable the use of grep if
non-ASCII characters are searched for because of an unexplained
problem with grep.
All the source files containing non-ASCII characters needed to have
utf8 added. This will be necessary for user config files as well! The
regular expressions identifying page names had to be changed.
UrlEncode translates the string back to bytes before encoding it.
Cached RSS files are saved with UTF-8 encoding and therefore need
their meta-data changed (using the XML::RSS module to do this
correctly didn't work for some of the test files). The CGI object's
parameters, keywords and info_path are decoded correctly. File access
uses the UTF-8 layer (reading, writing, appending, access to the log
of recent changes, running sub processes with grep and diff).
The mac compatibility extension will also disable the use of grep,
because I could not get it to work (and I don't think there will be
large Oddmuse installations running on Apple's HFS).
Replaced the $Id$ tags in $WikiDescription for all the modules and wiki.pl itself with a link to the source and an appropriate wiki page, if possible. This is shown in action=version and should help users figure out what another wiki has installed.
