bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Mark H Weaver]

Ricardo Wurmus <rekado@elephly.net> writes:

>> On Mon, 14 Sep 2020 at 22:58, Mark H Weaver <mhw@netris.org> wrote:
>>
>>> For what it's worth: not everyone uses Emacs, and it would be good to
>>> support users who choose to use simpler software.  I guess that it would
>>> be quite easy to modify the software behind 'issues.guix.gnu.org' to
>>> generate HTML that works well with simpler web browsers, so I'd prefer
>>> to keep this bug open.  What do you think?
[...]
> As the primary author of mumi (the software behind issues.guix.gnu.org)
> I agree with Mark and think this is worth fixing.  [...]

Thank you, Ricardo.

> There is no good reason why this should not be usable by people who use
> a simpler browser (I’m one of these people on some days).  If it turns
> out to be tricky to implement or to cause a degraded experience for
> those who use popular browsers we can still close this, but I think we
> should at least try.

Fair enough.

Thanks also for your proposed patch to change some spans to divs.  It's
a significant improvement, but there remains a very serious problem:
multiple spaces are being collapsed into a single space, and leading
spaces are lost entirely.  This destroys the indentation of all inline
code and patches.  The two solutions I know are (1) to generate 'pre'
elements, or (2) to convert leading spaces and runs of two or more
spaces into runs of 'nbsp' entities.

(I'm deliberately avoiding HTML syntax in this email, for fear that some
email clients may try to render it).

My suggestion would be to generate 'pre' elements.  It would avoid runs
of 'nbsp' entites making the raw html larger and harder to read.  It
would also ensure that a fixed width font is used.

My first thought was to simply modify your patch to change the 'span's
with class "line" into 'pre's instead of 'div's.  If 'pre' comes with
default styling that you don't like, perhaps it could be overridden by
additional code in screen.css.  I guess this approach would likely work
well enough in practice.

However, I've noticed that in Dillo with CSS disabled, generating a
'pre' for each line makes the line spacing larger than would be ideal.
It seems that some vertical padding or margins are added around each
'pre'.  It's likely that many browsers do this in their default styling
for 'pre'.  With this in mind, it would perhaps be better to wrap a
single 'pre' around each message.  Then you could either (1) leave the
lines as 'span's and add a raw CR-LF after each line (which would make
the HTML source code more readable) or (2) change the 'span's to 'div's
as in your proposed patch.

Another issue, which affects Dillo, is that ASCII apostrophes (') are
being converted to 'apos' entities, which are not valid HTML 4.  Dillo
renders these as the raw source, namely "&" followed by "apos" and ";",
which corrupts English text.  I suggest removing the third entry in
%escape-chars in (mumi web sxml).  Is there a reason to keep it?

What do you think?

   Thanks again,
       Mark