| Date | Commit message (Collapse) |
|---|
|
This can makes navigation easier with some browsers or
or browser extensions.
ref: https://www.w3.org/TR/html/links.html#sequential-link-types
|
|
Oops, gotta test this :x
|
|
This shouldn't show up in other browsers (tested with w3m, too),
but the extra newline makes a difference for delineating
messages when viewed with lynx.
|
|
This will allow potential tinkerers to switch away from the '` '
prefix more easily.
|
|
Allowing readers new to a topic to follow in chronological order
probably makes the most sense. Reverse chronological order may
reduce scrolling (e.g. log view); but nearly all non-threaded
conversation displays seem to be chronological so perhaps
there's a good reason for that.
|
|
Allow the Subject: <-> skeleton line to point to each other so
the reader can bounce around between them without refocusing
their browser.
|
|
Quote-folding was a major design mistake pre-1.0. Since this
project is still in its infancy and unlikely to be in wide
use at the moment, redirect the /f/ endpoints back to the
plain message.
|
|
...And mark quotes as <span class="q"> since it barely
costs us anything and allows users to choose colors
themselves with custom, user-supplied CSS.
Reduce allocations of the Linkify object, too.
|
|
Quote-folding can be detrimental as it fails to hide the
real problem of over-quoting.
Over-quoting wastes bandwidth and space for all readers, not
just WWW readers of the public-inbox. So hopefully removing
quote-folding support from the WWW interface can shame those
repliers into quoting only relevant portions of what they reply
to.
|
|
Oops, $MESSAGE_ID/f/R/ screws up rather badly.
|
|
Oops. While we're at it, simplify the calls to do threading
slightly by reducing the places where we touch Mail::Thread
globals.
Fixes: 56164afc2034 (view: allow topics to be "bumped" by new replies)
|
|
This ought to prevent new replies from getting lost for readers
relying on the WWW index interface.
|
|
In the per-message view, we still need to account for threads
lacking a common parent. This can happen when threads are
broken by some broken clients or if somebody sends the same
message twice to the same inbox with a different Message-ID.
|
|
Shorten lines used for long Message-IDs in the
inline thread view for per-message views for readability.
|
|
Keeping readers informed of ghost messages is important,
so do not ever prune them. Previously, ghosts could get
pruned and sole children would get promoted as the new
root.
|
|
These were the vestigial remains of our previous use of
of Message-ID compression.
|
|
The "next/prev" links seem a bit awkward and I don't use them as
much as I expected to. However, move the "raw" message link
near the top since it's most useful for checking or reinforcing
the validity of the message via GPG or just reading headers.
Turn the Subject line into a permalink to the message, since
that's probably the common behavior anyways for other messaging
systems. Make the "[threaded|flat]" view links to always
visible for bookmark-ability despite the lack of a "permalink"
label.
|
|
Reduce stack depth of arguments and rely more on state hashref
to store response state. We may end up shoving everything
in ctx eventually.
|
|
It's probably a bad idea to strip extraneous whitespace
from some headers as an extra space may convey useful
information.
Newlines don't seem to be preserved by Email::MIME or
Email::Simple anyways, so there's no danger in breaking
formatting.
|
|
Ugh, this enabled-iff-xapian-is-available code really
needs better testing...
|
|
Message-IDs should not be MIME encoded, but in case they are,
use the raw form for compatibility with ssoma and possibly
other tools. This prevents a potential problem where a
malicious client could confuse our storage layer into indexing
incorrect contents.
|
|
This will allow us to more easily reuse it elsewhere.
|
|
We now keep intermediate blank lines in messages, since it
could be used to denote logical gaps in the message
(such as giving readers a chance to opt out of "spoiler"
information).
However leading blank lines, trailing blank lines, and
trailing whitespace have no useful value we can discern;
so drop those entirely to prevent clients from eating up
vertical whitespace.
|
|
It's often not that much information and may be useful
to reduce HTTP requests a reader will want to make.
|
|
Setting the "In-Reply-To:" header via mailto: links is not
well-supported and should probably not be encouraged unless
the client situation improves.
So instead, teach users more widely-supported ways of setting
the In-Reply-To: header to ensure proper threading of replies.
|
|
For future changes, this will allow us to more quickly notice
if we keep the heavy Email::MIME object around too long.
It has the side effect of avoiding extra method calls with
Email::MIME which forwards header calls to the header_obj.
|
|
In an single-message thread with a ghost parent, we need to
go up level from the current Message-ID before appending the
parent message to us.
|
|
Dropping "[FOO]" prefixes for the purposes of summarization
is tricky and we end up with odd display behavior.
Just show Subject line changes as the writer intended
(with the exception of normalization to strip the "Re: ")
|
|
We should not hide the parent Message-ID in this view;
give the user the option to find the message in other archives.
|
|
The word "skip" can be confusing. Instead, spell out "scroll down"
for the user to read and only display that text when the thread
is sufficiently long.
|
|
There's no need to HTML escape a timestamp we generate ourselves.
We need to preserve the leading space and can't use the "oneline"
semantics to preserve alignment.
|
|
Inevitably, somebody will care about semantic HTML; but
preserving the original intent of the email author is
important.
|
|
Oops :x
|
|
Not needed, but this is good documentation. Some of these values
should never have newlines.
|
|
The threaded search view is somewhat alien to new users,
so ensure we label the word "relevance" for them.
|
|
Oops, the rarely-accessed threaded search view was completely
broken. Additionally, the normal threading depths were broken
when we attempted to go up-thread and replies got nested
improperly
Followup to commit be984ce279776d4513b4ca1bff05ebecafdd1bad
("view: thread using <ul> instead of <table>")
|
|
Linking to the expanded thread page probably makes more sense
as it avoid unnecessary scanning for the thread summary.
|
|
We already use "` " (backtick + space) to denote one indentation
level, so do not excessively indent and always pad with one
level less of spaces.
The 'x' operator in Perl handles negative values, so subtracting
one from level=0 will result in an empty string without spaces.
|
|
On second viewing, this does render small cues which makes the
output more pleasant for lynx users. We avoid injecting the
root (level=0) message into a list since it still wastes
precious horizontal whitespace on small displays.
This also results in small reductions in bandwidth usage as
it takes fewer tags/whitespace to render unordered lists.
|
|
Hopefully, "mbox.gz" is sufficiently understandabe that
we can get rid of the "title" attribute in <a> tags
(we already omitted the title in other pages).
Additionally, drop the '@' in front of the date.
The date should be obvious and is not necessary for
headers without author attribution.
|
|
If we bite the bullet and rely on inline CSS, we might as well
only specify it once per page instead of inline in every <pre>
tag which may handle UGC. So this actually saves us a small
amount of bandwith on most pages which have multiple <pre>
start tags.
|
|
Ghost message links didn't show up too well after
commit bc067a7562a586bed92401fe1084bbe423b9451a
("view: move thread info near top of single view")
Additionally, attribution lacked a space when subjects changed
mid-thread.
|
|
Most framed mail viewing software has message ancestry
information near the top instead of bottom (mutt, gmane,
sylpheed, thunderbird) as it can help improve context.
Traditional netiquette also favors writing replies below
quoted (older) text for this reason; so move the thread
summary to the top of the message for context.
Since threads may be long, add a "skip" anchor link to jump to
the message body quickly, and align the date to the left column
so it's easier to tell the relative age of messages.
While we're at it, remove quotes from "id" attributes to
improve ease-of-grep-ability.
|
|
Users may be iterating through lists and come up with nothing
|
|
We'll be using it for more than just cat-file.
Adding a `popen' API for internal use allows us to save a bunch
of code in other places.
|
|
User-generated content (UGC) may have excessively long lines
which screw up rendering. This is the only bit of CSS we use.
|
|
Avoid truncating messages if we requested the root anchor.
This regression appeared in
commit 62ee3cb36dd08f17e444e96dc80108464ee10cba
("view: do not shorten top-level messages in thread view")
Also, make the "More..." link more prominent, as readers
should be made aware they're not reading the full message.
|
|
Avoid the visual noise entirely by using a space instead.
I sometimes have difficulty distinguishing '0' from '8' while
other users may mistake it for an 'O' character. Most digital
clocks I've seen will omit displaying a leading zero for the
hour, too.
This may also save transfer time by allowing better compression
(since there is a space between the date and time anyways) and
perhaps reduce client rendering time on some displays.
We'll leave the leading zero for minutes since that seems pretty
standard for digital clocks.
|
|
It's potentially unsafe (leading to hidden messages) at any level.
|
|
Just because a message is currently alone does not mean
the links won't be valid in the future when more messages
show up.
|