| Date | Commit message (Collapse) |
|---|
|
This allows us to generate links without caring about discoverability
and remains reasonably WYSIWYG for folks editing our documentation in
their favorite $EDITOR
|
|
Occasionally we'll use these for links.
|
|
Sometimes people send HTML email and I forget to fixup in my
MUA during moderation. Automatically strip out HTML portions
instead.
|
|
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.
|
|
I often forget how to run this
|
|
"original" is a bit misleading, since we strip needless junk
like HTML from messages before it ever hits git.
|
|
Because some folks will want to receive email.
|
|
|
|
While we're at it, fix up a typo.
|
|
This reduces unnecessary white space and consistently places
the attribution under the Subject.
|
|
At the cost of some vertical whitespace.
More bikeshedding...
|
|
We must support multi-address mailing lists, so we do not
clobber existing addresses. However, we need to ensure
idempotency and ensure existing addresses are not reset.
Furthermore, we were not parsing the existing config correctly
due to a leaking $/.
|
|
Often times any succession of "---" denotes the rest of the
message is too long to review at once.
|
|
This hopefully allows easier setup.
|
|
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.
|
|
We need to ensure the HTML output is not mangled, either.
|
|
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.
|
|
Some readers may not be familiar with ssoma internals such as
ssoma-rm.
|
|
Some of these projects are not well known, so link to them
to help new users.
|
|
Even with txt2pre, the maintenance/discoverability burden is too
high and lynx still uses too much memory. Unfortunately, we'll have
to keep our INSTALL.html for a while longer on the server since it's
linked, but not index.html!
|
|
Oops.
|
|
Marketing is hard!
|
|
We can be stricter about HTML email, since none of the lists
hosted here accept HTML.
|