| Date | Commit message (Collapse) |
|---|
|
Replies are only direct replies, but followups could be any message
further down the thread. The latter is more useful.
|
|
No need to create a new hash when we can reuse the existing one
more.
|
|
This parameter hasn't been used since
commit 5adf8d639e9b5abd4cbac975d70ddc0fb76541fc
("feed: dead code elimination around dropped endpoints")
|
|
/t/ always falls back to subject path searching anyways,
so there's little lost besides perhaps more readable URLs.
Unfortunately people still use non-compliant mail clients which fail
to set In-Reply-To or References headers :<
|
|
We no longer do "smart" time displays as of
commit ea0e8649f90d1fd0850a41c0ca16642faadf4f14
("view: simplify timestamp generation").
In retrospect, that commit also made us more cache-friendly, too.
|
|
We will not require Search::Xapian to be installed.
|
|
* origin/search:
view: deduplicate common code for loading search results
SearchMsg: ensure metadata for ghost messages mid
implement /s/$SUBJECT_PATH.html lookups
search: remove unnecessary xpfx export
www: /t/$MESSAGE_ID.html for threads
view: hoist out index_walk function
view: reply threading adjustment
thread: common sorting code
view: display replies in per-message view
search: make search results more OO
extract redundant Message-ID handling code
search: implement index_sync to fixup indexer
initial search backend implementation
|
|
Was too sleepy to be coding last night :x
|
|
No point in wasting bytes even if gets compressed over
the wire, it'll use more memory when rendering on the
client.
|
|
We will reuse it for thread views when powered by Xapian.
|
|
More to come later.
|
|
Ghosts have no document data in them.
Perhaps we should just rely on terms for Message-ID
and avoid storing that in the document data...
|
|
Quick-and-dirty wiring up of to Subject: paths.
This may prove more memorizable and easier-to-share than
/t/$MESSAGE_ID.html links, but less strict.
This changes our schema version to 1, since we now
use lower-case subject paths.
|
|
SearchMsg calls it with the full module path anyways.
|
|
This should bring up nearly the entire thread a given
Message-ID is linked to.
|
|
We will reuse it for thread views when powered by Xapian.
|
|
Give changes in subject their own line to reduce line wrapping,
but avoid showing any redundant subjects by maintaining a hash
of subjects already displayed.
|
|
We'll be sharing the same threading, so it makes sense to sort
replies using the same code and message headers without repeating
ourselves.
This also standardizes on sorting on X-PI-TS (Unix epoch in seconds)
instead over using X-PI-Date differently in two different places
|
|
This can be used to quickly scan for replies in a message without
displaying an entire thread.
|
|
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
|
|
We must inject headers properly for injecting ham, otherwise
List-Id headers get dropped.
|
|
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.
|
|
We want to be able to reject errors back to the MTA.
|
|
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 want to be able to prioritize spam downstream to check for
borderline cases.
|
|
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.
|
|
SpamAssassin queries URI blacklists, so it's probably OK
to start generating links in the future...
|
|
This prevents process growth when importing large messages.
Memory growth could be due to the sliding sbrk window in glibc malloc
or a circular reference in the Email::* Perl code somewhere.
|
|
PublicInbox::Config->lookup won't return unknown keys
|
|
This should alleviate fears of interrupting the process.
|
|
|
|
Some mailing lists (e.g. git@vger.kernel.org) accept messages
via Bcc: and possibly other things which get rejected by
the strict PublicInbox::Filter rules. So rely on ssoma-mda
instead.
This prefers a recent revision of ssoma-mda (commit 7fce38e9
onwards) to display subject/author/date information in the
commit message.
|
|
Newer systems may use .json instead of .yml
|
|
Some mailers may omit the Content-Type header entirely,
so do detection and try to get the message through.
|
|
Apparently it's not a problem with recent archives.
|
|
We start with zero and only store the next valid ID.
|
|
This allows incremental imports of slrn spools, ideal for
tracking lists via gmane.
|
|
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.
|