Date | Commit message (Collapse) |
|
This is necessary to retain consistent spacing around bullet
points.
Fixes: 666844ae42b5b17f ("reply: handle address obfuscation :<")
|
|
We can show users a lightly-obfuscated Bourne shell command
for invoking "git send-email" for address obfuscation. However,
I'm not sure if the mailto: arg will work effectively since
URL encoding is probably too well-known to be effective.
|
|
This is lightly-tested and seems to work. I'm still
hesitant to support this, but the alternative of receiving death
threats for displaying unobfuscated addresses seems to
be not worth it.
|
|
This allows us to support centralized mailing lists (which suck,
but better than no mailing list at all).
|
|
We'll be adding more reply options for centralized mailing
lists. So split out the logic so it's easy-to-find.
Organizing code is hard :<
|
|
Otherwise funky filenames can cause HTML injection
vulnerabilities (hope you have JavaScript disabled!)
|
|
It seems possible for git-send-email(1) to generate repeated
repeated instances of References and In-Reply-To headers,
as evidenced in:
https://public-inbox.org/git/20161111124541.8216-17-vascomalmeida@sapo.pt/raw
This causes a mismatch between how our search indexer threads
and how our HTML view handles threading. In the future, View.pm
will use the smsg-parsed {references} field and avoid redoing
Email::MIME header parsing.
We will still need to figure out a way to deal with messages
with repeated Message-IDs, at some point, too.
|
|
This should fix problems with multipart messages where
text/plain parts lack a header.
cf. git clone --mirror https://github.com/rjbs/Email-MIME.git
refs/pull/28/head
In the future, we may still introduce as streaming
interface to reduce memory usage on large emails.
|
|
This results in over 1% speedup doing $MESSAGE_ID/T/ HTML
generation for a 368-message thread.
|
|
This results in a half percent speedup or so doing
$MESSAGE_ID/T/ HTML generation for a 368 message thread.
|
|
This allows a 3-4% speedup in $MESSAGE_ID/T/ page generation
speed for a 368+ message thread. It also more faithfully
preserves the message as intended; even if the it makes the
sender look like a space-wasting slob :P
|
|
And add a comment about it to remind our future selves.
|
|
This simplifies callers to prevent errors and avoids
needless object-orientation in favor of a single procedure
call to handle threading and ordering.
|
|
Instead, only preload the ->mid field for threading,
as we only need ->thread and ->path once in Search->get_thread
(but we will need the ->mid field repeatedly).
This more than doubles View->load_results performance on
according to thread-all on an inbox with over 300K messages.
|
|
In addition to needing to retry enquire queries, we also need
to protect document loading from the Xapian DB and retry on
modification, as it seems to throw the same errors.
Checking the $@ ref for Search::Xapian::DatabaseModifiedError
is actually in the test suite for both the XS and SWIG Xapian
bindings, so we should be good as far as forward/backwards
compatibility.
|
|
This makes life easier for the threading algorithm, as we can
use the implied ordering of timestamps to avoid temporary ghosts
and resulting container vivication.
This would've also allowed us to hide the bug (in most cases)
fixed by the patch titled "thread: last Reference always wins",
in case that needs to be reverted due to infinite looping.
|
|
This should reduce the number of subroutine calls needed
for the common case of real (non-ghost) messages as well
as shortening code.
|
|
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.
|