Date | Commit message (Collapse) |
|
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.
|
|
This hybrid view is better than the old flat, but can
still fall down compared to the old threaded view in
some cases.
|
|
This reverts commit a391cf5aaf7181b5e5e20eb240c7ce50cbdf8fa2
as kernel.org is updating again. Ref:
http://mid.gmane.org/xmqqpor18a2n.fsf@gitster.mtv.corp.google.com
|
|
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.
|