| Date | Commit message (Collapse) |
|---|
|
This reduces unnecessary white space and consistently places
the attribution under the Subject.
|
|
At the cost of some vertical whitespace.
More bikeshedding...
|
|
Often times any succession of "---" denotes the rest of the
message is too long to review at once.
|
|
Unix line endings are LF-only, so do not introduce or preserve
CRLF line endings when reading from lynx.
|
|
We have a less-ambiguous "more..." link nowadays if somebody
wants to see the full message.
|
|
We should do this in filter, too, but sometimes we
prefer to avoid filtering the message at all.
|
|
This helps readers jump around more quickly when there are
large messages.
|
|
This allows us to more-easily group and pass parameters.
|
|
Sometimes people come from sharing links and not the index,
so the back button in their browser does not really go back.
|
|
Not sure what I was thinking
|
|
Some Message-IDs are crazy long, so support SHA-1s for them
instead. This allows shorter URLs to be generated and are
less likely
However, we'll still favor short Message-IDs whenever possible.
|
|
This should allow us to reference discussions more easily.
|
|
It's important to keep HTML source readable to folks who prefer
to read raw HTML. This should improve readability of the HTML
source by keeping line length in check without wasting bytes.
|
|
Avoid redundant subroutine calls as their costs tend to add up.
|
|
Only root messages should be sorted in reverse chronological order,
child messages should be chronological. This gives precedence to
_topics_, but also for initial replies.
This improves readability when several messages appear at the same
nesting level, and helps git patch series' appear correctly as:
[PATCH 0/3] ...
[PATCH 1/3] ...
[PATCH 2/3] ...
[PATCH 3/3] ...
Instead of (what it was previously):
[PATCH 0/3] ...
[PATCH 3/3] ...
[PATCH 2/3] ...
[PATCH 1/3] ...
|
|
Oops!
|
|
Sometimes, the subject says it all.
|
|
There's no point in having a "(more...)" and "link" pointing
to the same element, replace "link" with "more..." if we've
omitted text from the index.
|
|
It's probably better to show too much than too little, even
if this means extra scrolling :<
Otherwise, we end up punishing messages who quote minimally
and end up loosing context. Unfortunately, too many people
over-quote nowadays.
|
|
Leading whitespace is pointless, but some folks end up adding
it for some reason.
|
|
It's helpful to show context if a message does not
appear on the current index page.
|
|
The previous regexp matches were too aggressive w.r.t. scissors.
We destroy trailing whitespace anyways, so do not worry about it
when cutting signatures and patches off.
|
|
Patches are usually better viewed standalone and are difficult
to judge when nested. So save precious vertical space in our
message index.
|
|
Sometimes we get spam and need to delete messages,
we must prevent errors on missing messages from propagating.
|
|
This will make it easier to bookmark an index page with threading
context.
|
|
12 lines is half an 80x24 terminal, so it is probably a reasonable
amount to quote. Often 5 lines was not enough for context. This
feature is mainly to reduce scrolling necessary to view pages.
|
|
This reduces the need for page reloads in common cases and should
improve reading speed so users do not need to open many browser
tabs. This will hopefully increase an encourage readership.
The downside of this are increased server processing overhead and
easier address scraping by spam bots.
|
|
We will reuse the html_footer function in a nested index.
|
|
This is probably useful information for folks browsing via web
interface. It'll probably make more sense if we show the entire
body in the threaded display, though.
|
|
HTML clients also tend to send quoted-printable crap in
their plain-text parts, preserve that so it's displayed
correctly for all QP-capable handlers.
|
|
We nuke DKIM headers because we modify headers and sometimes the
body, which may invalidate the message. We'll also nuke whatever
Mailman nukes from messages to avoid phishing and leaking
information.
|
|
That should be use down stream by delivery agents.
|
|
This looks nicer to me (totally subjective and open to bikeshedding
:P)
|
|
Horizontal scrolling is a usability problem for GUI browsers,
so help them avoid it. I love GUI users, really! :)
|
|
Oops, this was an oversight.
|
|
|
|
This should improve navigation as browsers may not make it
obvious there is an Atom feed.
|
|
Otherwise the reply link gets squished.
|
|
URLs may be long, so give each its own line.
|
|
Some advertising is necessary.
|
|
Screen space is precious, and we do not need it in the abbreviated
view.
|
|
These views are not OO, so the "as_" prefix makes little sense
and "as_html" conflicts with Hval, which is OO.
|
|
This should reduce data copies and memory usage, according
to Email::Simple documentation.
|
|
The requests we make to git cat-file --batch are guaranteed to be
smaller than the 512 bytes required by PIPE_BUF, so there will be no
partial writes. Bypass Perl IO layers and write directly to the
pipe to avoid needing IO::Handle here.
|
|
Future versions of Mail::Thread may be released to fix this bug.
However, since it's been about 8 years since the bug was reported..
|
|
Thanks to Ask for the patch in
https://rt.cpan.org/Public/Bug/Display.html?id=22817
|
|
This prevents memory bloat in case we're serving many requests
with a large, diverse set of email addresses (potentially from
malicious spammers).
|
|
This should allow us to more-easily test with Plack.
|
|
IPC::Open* does not work well under mod_perl (probably because
it does funky things with stdout/stderr). So use the POSIX
dup2 functions instead, which work reliably on all POSIX-like
platforms.
|
|
We may not have PATH available on some servers (e.g. webrick)
and must rely on the hardcoded system PATH. My installation of
IPC::Run does not seem to work without PATH set in the env,
however normal Perl "open" calls work fine.
|