|Date||Commit message (Collapse)|
Making them immortal doesn't seem worth it, since doing immortal
allocations after process startup leads to fragmentation. While
the allocations made by highlight are small, those small
allocations can break up contiguous regions and prevent
consolidation by the malloc implementation.
Since instantiating code generators doesn't seem too expensive,
just use and delete them ASAP.
Using "make update-copyrights" after setting GNULIB_PATH in my
I didn't wait until September to do it, this year!
Quoting Amitai Schleier, who made this same change in ikiwiki,
where lots of the public-inbox highlight code comes from:
> As of 3.51, searchFile() is no longer provided in highlight's Perl
> bindings (at least on NetBSD and OS X, as built from pkgsrc). This
> leaves us falling through to getConfDir(), which has been gone
> rather longer.
> From highlight git, it appears searchFile() and getFiletypesConfPath()
> both originated in the 3.14 release. The latter is still available in
> 3.51, and returns the same result searchFile() used to. Switch to it.
So, this should still be compatible with the version of highlight.pm in
Debian, but add support for newer versions as well.
: commit 4d06df9583e6c4145f8c6fc2fd51d7894c0b85ce
Cc: Amitai Schleier <firstname.lastname@example.org>
This is compatible with Markdown; but we still keep the WYSIWYG
nature of plain-text with this. This is only intended for use
with our documentation. Enabling any type of Markdown support
for emails can lead to incompatibilities or interopability
problems with alternative implementations.
We want to be able to take advantage of this in other modules
It turns out there's no point in having multiple instances of
this or having to worry about destruction or destruction
This will make it easier to reuse the one instance we have
across different modules.
We'll want to use to support highlighting syntax used by
Markdown and possibly other markup languages (while retaining
the raw plain-text layout and formatting).
Favor in-place utf8::decode since it's a bit faster without
method dispatch overhead; and don't care about validity just
HlMod->do_hl itself should return "utf8" strings, since other
parts of our code can use it, so it's not the job of ViewVCS to
post-process HlMod output.
We already have a <pre> tag in ViewVCS, and nesting <pre>
inside the pre-existing <pre> overrides the "white-space:pre"
we use to align line numbers.
I'll probably expose the PSGI service for cgit;
but it could be useful to others as well.