Date | Commit message (Collapse) |
|
This should avoid warnings during thread skeleton generation if
ever the Xapian database disagrees with View.pm about which is
the proper direct parent of a message. We will treat the data
in Xapian as the truth (if Xapian is available).
|
|
Some mail clients do not seem to handle '+' as a space in query
parameters for the mail subject, use the more common '%20' for
compatibility.
|
|
This reverts commit 3c9dd6619f825f0515e7e4afa1bd55c99c1a68d3
("thread: fix sorting without topmost")
and reinstates the "topmost" routine for sorting purposes.
|
|
Each node has an entire arrayref of its children nowadays, so
there's no need to waste time and memory creating another one.
|
|
This starts to show noticeable performance improvements when
attempting to thread over 400 messages; but the improvement
may not be measurable with less.
However, the resulting code is much shorter and (IMHO)
much easier to understand.
|
|
This bug was hidden, and we may not be able to efficiently
implement a topmost subroutine with the hash-based (vs
linked-list) based container for threading in the next
commit.
|
|
It doesn't buy us much and copying to a new array is slower;
but probably not measurable in real-world use.
|
|
This roughly doubles performance due to the reduction in
object creation and abstraction layers.
|
|
Copying large arrays is expensive, so avoid it.
This reduces /$INBOX/ time by around 1%.
|
|
Introduce our own SearchThread class for threading messages.
This should allow us to specialize and optimize away objects
in future commits.
|
|
We will not care for inexact threading by subject or pruning.
|
|
Email::MIME internally assumes "text/plain" for messages
missing a Content-Type, but does not expose that in the
Email::MIME::content_type API method. We must assume it
ourselves to avoid uninitialized value warnings for the
rare (nowadays) MUAs which do not set it.
|
|
For some reason, Alpine will set X-UNKNOWN for valid UTF-8.
Since we favor UTF-8 HTML anyways, try forcing Email::MIME to
handle text/plain as UTF-8 which might show up better.
At least this change renders
<alpine.DEB.2.20.1608131214070.4924@virtualbox>
properly by showing "•" (•) instead of
"⠢" (•)
Reported-by: Thomas Ferris Nicolaisen <tfnico@gmail.com>
|
|
Alpine seems to set charset=X-UNKNOWN for valid UTF-8 text,
which causes Email::MIME::body_str to fail as X-UNKNOWN
is not a valid encoding. So, blindly display the body
as plain-text but warn users about possibly mangled text.
Reported-by: Thomas Ferris Nicolaisen <tfnico@gmail.com>
|
|
There is no point in using an array to join on an
empty string (my original intention was probably to
join on "\n").
This is only preparation for the next change to show
a warning to in the attachment link.
|
|
Ensure we usually strip one level of '<>' from Message-IDs,
since our internal SQLite, Xapian, and SHA-1 storage all
assume that.
Realistically, we screw up if somebody has '<<' or '>>',
but those are screwed up mail clients and we can deal with
it another time. Currently, this means some messages with
'>>' in References or Message-Id are not handled correctly,
yet, but we match the behavior of Mail::Thread in keeping
the extra '>'.
|
|
Based on reading RFC 3986, it seems '@', ':', '!', '$', '&',
"'", '; '(', ')', '*', '+', ',', ';', '=' are all allowed
in path-absolute where we have the Message-ID.
In any case, it seems '@' is fairly common in path components
nowadays and too common in Message-IDs.
|
|
|
|
Because buggy mail clients exist and generate invalid
In-Reply-To headers we cannot handle across the board...
|
|
This is necessary to delimit messages when viewed without
threading.
|
|
When using <ul><li>..., we already setup <pre> tags
in thread_index_entry, so having an extra </pre> tag
causes validation errors.
Fixes: 6ef9b216156c ("view: use <hr> to delineate in /$MID/T/ view")
|
|
The sacrifice in vertical space might be worth it to improve
ease-of-reading, as it's unreasonable to expect an entire
message thread to be able to fit into a single window.
https://public-inbox.org/git/20160805093544.scvl4yshkfg2l26p@sigill.intra.peff.net/
Cc: Jeff King <peff@peff.net>
|
|
Sometimes messages have an empty In-Reply-To header which throws
threaders off. This actually causes public-inbox-httpd to die,
which is probably bad and will be fixed elsewhere.
|
|
Having long Cc: lines is inevitable for large threads
with many participants, and git-send-email only gained
the ability to recognize ',' in the "--cc" arg recently
with the release of git v2.6.0 in September 2015.
|
|
Clearly label "Thread overview" and "Reply instructions"
so users can quickly skip stuff they're not interested in.
Additionally, note the fact the thread view allows quick
navigation within the thread to avoid extra network requests
and improve the display for single-message threads.
Finally, use <hr> to better-delineate sections of each page.
|
|
We only care about the thread skeleton if we have
multiple messages in a thread, single message threads
can just go to the top of the message.
|
|
|
|
This probably makes the most sense as it's structured like
a changelog.
|
|
This reduces the amount of mbox/Atom links while keeping
better track of overall thread count. We no longer loop
to fill up slots to simplify the code a bit and hopefully
get better grouping.
|
|
Hopefully this can reduce memory overhead for people that
use one-shot CGI.
|
|
This is closer to the behavior of thread-aware MUAs.
|
|
It should be harmless if the "[this message]" text goes past
the boundary as we bold the entire line to make it stand out.
|
|
No need for ' / ' delimiters on lines dedicated for hyperlinks.
|
|
We now generate all of our HTML using WwwStream which
forces us to have consistent headers and footers in
the HTML itself.
This also makes the search-capable vs search-less installs
go to the new.html endpoint to maintain consistency
(in case an admin decides to enable Xapian).
|
|
We only need XHTML-compatibility inside Atom feeds, as
anecdotally, feed readers are stricter than normal browsers and
some do not support HTML, only XHTML. So we will continue to
accomodate them. However we favor HTML elsewhere since it
tends to be smaller than the equivalent well-formed XHTML.
|
|
Oops :x
|
|
Exposing compressed Message-IDs in URLs was a mistake,
remove a remnant of it.
|
|
There is no point for diverting readers' attention with
an unnecessary link, here.
|
|
Plack::Request will check the request body by merely
calling "param", totally unnecessary and sneaky.
|
|
Oops, fortunately this branch is only exposed to non-Xapian
users, right now.
|
|
Oops :x I really need to whip check-inbox.perl into
shape or at least start running it, again.
Fixes: e29518088b3f ("view: fix up some HTML injection via Message-ID vectors")
|
|
This fixes the '^' (up) link in the $INBOX/new.html endpoint
for search-less displays.
|
|
Storage is precious when it is forever and distributed.
And public-inbox aims to not only end Eternal September(*),
but to build a world less-centralized than Usenet ever was:
forkable discussion groups
(*) https://en.wikipedia.org/wiki/Eternal_September
|
|
This should make formatting more apparent since we can rely
on <pre> semantics.
|
|
This encapsulates an entire PSGI response array, hopefully
making it easier to generate responses and avoid typos when
setting the Content-Type.
|
|
Oops, this endpoint needs testing :x
|
|
* thread-view-skel:
view: show thread size when linking to summary
view: default to flat/hybrid thread display
view: fix up some HTML injection via Message-ID vectors
www: reinstate old thread view as an option
view: show more nearby messages in flat thread view
view: tweak thread/index header slightly
feed: add $INBOX/new.html endpoint
view: merge $state hash with existing $ctx
view: show thread context in the thread-aware flat view
www: use WwwStream for dumping thread and search views
www: implement hybrid flat+thread conversation view
|
|
This should give readers a better idea of what to expect.
|
|
This is friendlier for people on small screens and usually
eliminates the need to scroll horizontally.
|
|
Oops, these were only introduced during the hybrid flat thread
view reworking and never deployed.
|