| Date | Commit message (Collapse) |
|---|
|
This will relieve callers of the need to decode the data
we store internally in Xapian
|
|
Quit repeating ourselves and use a common MID module
instead.
|
|
We need to make the indexer executable and installable
while we're at it.
|
|
This shall allow us to search for replies/threads more easily.
|
|
This fixes a minor test failure in t/cgi.t
Tested with perl 5.18.2-2ubuntu1 on Ubuntu 14.04.3 LTS
|
|
Unneeded since commit e022d3377fd2c50fd9931bf96394728958a90bf3
("huge refactor of encoding handling")
|
|
This fixes the fallback to message encoding if the message
itself was not UTF-8
|
|
It's seems less ambiguous to parse a consistent in quiet lists
where messages are sparse.
|
|
We'll be using this in the future for displaying per-thread
views.
|
|
This should hopefully reduce the delay between when a user fails
to send plain-text to when an admin such as myself notices the
HTML mail in a sea of spam.
Unfortunately, this can lead to backscatter, so avoid doing it
until its passed through spamc, at least.
|
|
This avoids some runtime penalties associated with recompiling
a regexp based on a constant local variable.
|
|
This is probably more compliant, and saves us a few bytes
on the uncompressed HTML.
|
|
Oops, noticed by manual inspection. One day we'll run tidy in tests
to validate.
|
|
We can't add newlines to links, unfortunately, because
quote-folding is line-based and (being regexp-based) needs
to happen after linkification.
|
|
SpamAssassin queries URI blacklists, so it's probably OK
to enable this without being used as a linkfarm.
|
|
Some mailers may omit the Content-Type header entirely,
so do detection and try to get the message through.
|
|
Ugh, apparently there's a (yet-to-be-fixed) bug in the Filter
code which caused an HTML message portion of a multipart message
to be displayed on the web UI. Account for that and nuke it.
|
|
This is occasionally useful and we're not as starved for screen
space now now that sender+timestamps are on a separate line.
|
|
These may not be permanent, after all.
Better threading support can be done for message views, so
and the current index layout is still too busy and suboptimal.
|
|
"original" is a bit misleading, since we strip needless junk
like HTML from messages before it ever hits git.
|
|
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.
|