Date | Commit message (Collapse) |
|
Context is important, but so is conserving precious screen
space. Decisions :<
|
|
This makes the top permalink/raw as well as the In-Reply-To
show up without search. While we're at it, try to make
the links on the thread index from the "X siblings, Y replies"
more obvious.
|
|
This reduces the level of indirection to reach certain objects
within the hash and there are no namespace or lifetime conflicts
anyways.
|
|
This lets user have a small window of the context of
the current message relative to other threads.
|
|
This allows us the HTTP server to react to backpressure
from slow clients when writing. As a side effect, this
also makes it easier for us to maintain a consistent
header/footer across our HTML.
|
|
This should be more accessible to readers on narrow terminals
(or giant fonts) while providing a chronological view which
is also aware of message threading relationships.
|
|
Oops, we cannot have bare '&' in mailto: links, either.
|
|
Oops, but apparently this does not trigger errors?
|
|
Angle brackets around the --in-reply-to= arg for git send-email
has been optional since git v1.5.3.2, so strip them and make the
command-line argument easier-to-type.
|
|
Address::names is sufficient to handle what from_name did.
|
|
It is important to show the decentralized nature of
communication in our web views.
|
|
I've setup my own mirror on https://git-htmldocs.bogomips.org/
since kernel.org is no longer updated, and I don't believe
in endorsing commercial hosting sites or interests.
Unfortunately, it still contains JavaScript and CSS, but it's
generated by AsciiDoc. Oh well, it's all Free Software, at
least.
Junio C Hamano writes:
> On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong <e@80x24.org> wrote:
> > Just wondering, who updates
> > https://kernel.org/pub/software/scm/git/docs/
> > and why hasn't it been updated in a while?
> > (currently it says Last updated 2015-06-06 at the bottom)
>
> Nobody. It is too cumbersome to use their upload tool to update many
> files (it is geared towards updating a handful of tarballs at a time).
ref:
http://mid.gmane.org/20160622190018.GA786@dcvr.yhbt.net/
http://mid.gmane.org/CAPc5daUiUv-EEv7ouQ=K+Q8S64QVV5wn4H6+TuF0wLeo123K5Q@mail.gmail.com
http://mid.gmane.org/20160622214811.GA19633@dcvr.yhbt.net
|
|
We want to ensure the actual message gets shown, and less
important info does not destroy things.
|
|
This fixes a bug where a message replying to a ghost would
accidentally be added to the wrong topic in the index/topic
view.
Before commit 76d8f68dc273e54809ad69cfe49e141003f790ef ("view:
avoid recursion in topic index"), we would refuse to indent a
topic which started with a ghost which hid the problem. Now we
inform the user the thread started elsewhere.
|
|
Showing "(no subject)" seems like a common fallback for
messages without a Subject header.
|
|
Since we have a common pattern, for walking threads,
extract it into a function and reduce the amount of code
we haev.
This will make it easier to switch to an event-driven interface
for getline, too.
|
|
Recursion can cause problems, so do our best to avoid it
even in the topic index.
|
|
This should let us generate HTML for arbitrarily deep
threads without blowing the stack.
How it renders on the client side is another matter...
|
|
This should help prevent OOM errors from arbitrarily
deep threads and will make our streaming interface
easier-to-implement.
|
|
We can stuff this into the state hash to reduce stack size and
hopefully improve readability.
|
|
This makes the string creation somewhat simpler hopefully
makes the code easier-to-reason with.
|
|
This should help avoid having too many fake top-level
messages in the topic view since we only have a partial
window for threading results.
|
|
Favor Inbox objects as our primary source of truth to simplify
our code. This increases our coupling with PSGI to make it
easier to write tests in the future.
A lot of this code was originally designed to be usable
standalone without PSGI or CGI at all; but that might increase
development effort.
|
|
We don't want to blindly append a trailing newline
if the message ends in quoted text leading to a <span>,
as a newline is already added to a <span>...
|
|
Fold addressee fields to better delimit destinations,
reduce horizontal rule <hr /> to reduce scrolling,
and use spaces to indent "git send-email" example.
|
|
This will allow us to commonalize HTML generation in the future
and is the start of moving existing HTML generation to a "pull"
streaming model (from the existing "push" one).
Using the getline/close pull model is superior to the existing
$fh->write streaming as it allows us to throttle response
generation based on backpressure from slow clients.
|
|
We need to ensure we show the message body ASAP since
the thread generation via Xapian could take a while
and maybe even raise an exception or crash.
|
|
While we may end up mirroring lists which allow HTML mail,
encourage plain-text for compatibility since all current
inboxes we host are text-only.
|
|
Oops, needless waste of space.
|
|
Oops :x Add an additional test for live data for any
unprintable characters, too, since this could be a dangerous
source of HTML injection.
|
|
This should reduce link following for replies and improve
visibility. This should also reduce cache overhead/footprint
for crawlers.
|
|
No need to duplicate the string when transforming it;
learned from studying SpamAssassin 3.4.1
|
|
git has stricter requirements for ident names (no '<>')
which Email::Address allows.
Even in 1.908, Email::Address also has an incomplete fix for
CVE-2015-7686 with a DoS-able regexp for comments. Since we
don't care for or need all the RFC compliance of Email::Address,
avoiding it entirely may be preferable.
Email::Address will still be installed as a requirement for
Email::MIME, but it is only used by the
Email::MIME::header_str_set which we do not use
|
|
The offset argument must be an integer for Xapian,
however users (or bots) type the darndest things.
AFAIK this has no security implications besides triggering
a warning (which could lead to out-of-space-errors)
|
|
Having a file start with '.' or '-' can be confusing
and for users, so do not allow it.
|
|
For attachments without a filename or description, reduce
the amount of precious screen space required to display
a link to it.
|
|
We shall ensure links continue working for this.
|
|
This can be useful for lists where the convention is to
attach (rather than inline) patches into the message body.
|
|
msg_iter lets us know the index of the attachment,
allow us to make more sensible labels and in a future
commit, hyperlinks to download attachments.
|
|
Or is it "encoding"? Gah, Perl character set handling
confuses me no matter how many times I RTFM :<
This contains placeholders for attachment downloading
which will be in a future commit.
|
|
Oops, but perhaps the "reply" endpoint should be embedded
into the permalink message view itself to reduce URLs.
|
|
Remove unnecessary wrapper subroutines and constants
which are only used once.
|
|
Oops, we need to escape Message-IDs since they can contain
bad characters such as '%' in them. '@' actually seems fine
and does not need to be escaped; however, but we've been
doing it forever.
|
|
A public-inbox is NOT necessarily a mailing list, but it
could serve as an input point for zero, one, or infinite
mailing lists :D
|
|
Broken threads should be exposed to hopefully encourage people to
use proper mail clients which set In-Reply-To headers.
|
|
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.
|