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

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

[Vitaliy Shatrov]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Hello again dear Guixen.
I use emacs-w3m as a browser on  a single board computer.  I want to read, for example, issue #43159.

I can read it on https://debbugs.gnu.org/43159.  It's formatted properly, and the patch is readable too.

But the https://issues.guix.gnu.org/43159
is barely readable, and the patch is unreadable at all.  Even quoted text appear as:
> line > another line > more lines..

I think the issues.guix.gnu.org  should automatically append a link to the debbugs.gnu.org, for all issues.  It can be named like <a>No-JS version here</a>, or so.

The Links browser also can't show issues.guix.gnu.org properly for now.

Thanks.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 876 bytes --]

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

[Mark H Weaver]

Vitaliy Shatrov <guix.vits@disroot.org> writes:

> Hello again dear Guixen.
> I use emacs-w3m as a browser on  a single board computer.  I want to read, for example, issue #43159.
>
> I can read it on https://debbugs.gnu.org/43159.  It's formatted properly, and the patch is readable too.
>
> But the https://issues.guix.gnu.org/43159
> is barely readable, and the patch is unreadable at all.  Even quoted text appear as:
>> line > another line > more lines..

I see similar problems with both 'lynx' and 'dillo' when remote CSS is
disabled.  As you point out, https://debbugs.gnu.org/ works much better
for simpler web browsers.

> I think the issues.guix.gnu.org should automatically append a link to
> the debbugs.gnu.org, for all issues.  It can be named like <a>No-JS
> version here</a>, or so.

I haven't looked carefully, but the issue seems to be related to CSS,
not Javascript.

      Thanks,
        Mark

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

[Mark H Weaver]

Earlier, I wrote:
> I see similar problems with both 'lynx' and 'dillo' when remote CSS is
> disabled.

To be clear, Lynx doesn't have CSS support, so it's unable to properly
render 'issues.guix.gnu.org'.  Dillo can render it unless remote CSS is
disabled.

      Mark

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

[zimoun]

Dear,

If you use Emacs, you should try the package emacs-debbugs.
Then: C-u M-x debbugs-gnu guix,guix-patches n y and last M-x
debbugs-gnu-bugs 43159

It does not solve the CSS and/or Javascript issue but it clearly eases
the readings of bug reports with Emacs.

All the best,
simon

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

[Vitaliy Shatrov]

Really i was a fool.
Thanks for suggesting a tool.
No more dances with web-faces.

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

[Maxim Cournoyer]

Hi Vitaliy,

Vitaliy Shatrov <guix.vits@disroot.org> writes:

Closing since a dedicated tool for use in Emacs (emacs-debbugs) exists,
which works around the shortcomings of the Emacs web browsers (Probably
CSS related, as Mark pointed out).

Thanks,

Maxim

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

[Mark H Weaver]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Vitaliy Shatrov <guix.vits@disroot.org> writes:
>
> Closing since a dedicated tool for use in Emacs (emacs-debbugs) exists,
> which works around the shortcomings of the Emacs web browsers (Probably
> CSS related, as Mark pointed out).

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?

      Mark

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

[zimoun]

Dear Mark,

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?

I am not sure to understand.  Something that generates HTML that works
well with simpler web browsers is <https://debbugs.gnu.org>, isn't it?
From what I understand, the aim (and "raison d'étre) of
<issues.guix.gnu.org> is to generate what is considered as "modern
webapp".

Therefore, what is the concrete request?

 - read the Debbugs with a simple web browser?  Then the answer is
<debbugs.gnu.org>.
 - add a button in <issues.gnu.org> saying "simple html there" and
redirecting to <debbugs.gnu.org>?  If yes, the source code to tweak is
there <https://git.elephly.net/gitweb.cgi?p=software/mumi.git> and I
agree it would be quite easy; I will give a try if no one beats me.
:-)

All the best,
simon

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

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> Dear Mark,
>
> 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?
>
> I am not sure to understand.  Something that generates HTML that works
> well with simpler web browsers is <https://debbugs.gnu.org>, isn't it?
> From what I understand, the aim (and "raison d'étre) of
> <issues.guix.gnu.org> is to generate what is considered as "modern
> webapp".
>
> Therefore, what is the concrete request?
>
>  - read the Debbugs with a simple web browser?  Then the answer is
> <debbugs.gnu.org>.
>  - add a button in <issues.gnu.org> saying "simple html there" and
> redirecting to <debbugs.gnu.org>?  If yes, the source code to tweak is
> there <https://git.elephly.net/gitweb.cgi?p=software/mumi.git> and I
> agree it would be quite easy; I will give a try if no one beats me.
> :-)

As the primary author of mumi (the software behind issues.guix.gnu.org)
I agree with Mark and think this is worth fixing.  I don’t want people
to have to use debbugs.gnu.org with its different features when we could
just make issues.guix.gnu.org do the right thing on simpler browsers.

issues.guix.gnu.org is supposed to offer a “superior” experience to
debbugs.gnu.org — it is supposed to be sufficient to replace it, not to
be merely an alternative view; while a primarily goal is indeed to make
it look “pretty” (i.e. some font and spacing improvements and very
subjective style changes that lean on what many users of Github and
Gitlab may be familiar with), it also provides features that
debbugs.gnu.org does not, such as listing “forgotten” issues, to search
without a somewhat complicated form, or the ability to comment from a
browser.

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.

-- 
Ricardo

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

[Ricardo Wurmus]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

The attached patch seems to fix the worst problems.

I’m marking up each line in a message with a “span” tag and a “line”
class; then I use CSS to visually separate the lines.  Simple browsers
that don’t support this CSS rely on “span” to be an inline tag; likewise
they rely on “div” to be a block tag, no matter what the CSS might say.

So the attached patch changes the tag from “span” to “div”, so simple
browsers will render each line on their own instead of joining them.
This seems to have no negative impact on the rendering in other
browsers.  It also shouldn’t be a problem going forward, as popular
powerful browsers allow me to style these “div” tags without
limitations.

What do you think?

-- 
Ricardo



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: p.patch --]
[-- Type: text/x-patch, Size: 5709 bytes --]

diff --git a/assets/css/screen.css b/assets/css/screen.css
index 684bc01..5d8513d 100644
--- a/assets/css/screen.css
+++ b/assets/css/screen.css
@@ -353,28 +353,28 @@ details {
     display: none;
 }
 
-.message span.line {
+.message div.line {
     white-space: pre-wrap;
     font-family: monospace;
     display: block;
 }
 
 /* diff styles */
-.message .diff span.line.diff.file {
+.message .diff div.line.diff.file {
     color: #005cc5;
 }
-.message .diff span.line.diff.separator {
+.message .diff div.line.diff.separator {
     color: #005cc5;
 }
-.message .diff span.line.diff.addition {
+.message .diff div.line.diff.addition {
     color: #22863a;
     background-color: #f0fff4;
 }
-.message .diff span.line.diff.deletion {
+.message .diff div.line.diff.deletion {
     color: #b31d28;
     background-color: #ffeef0;
 }
-.message .diff span.line.diff.range {
+.message .diff div.line.diff.range {
     color: #6f42c1;
     font-weight: bold;
 }
@@ -394,7 +394,7 @@ details {
 }
 
 /* quote styles */
-.message .quote span.line {
+.message .quote div.line {
     color: #3868cc;
 }
 
diff --git a/mumi/web/view/utils.scm b/mumi/web/view/utils.scm
index 3c95644..4a4ecb0 100644
--- a/mumi/web/view/utils.scm
+++ b/mumi/web/view/utils.scm
@@ -68,7 +68,7 @@ with the next context."
        (if (string-prefix? "--8<---------------cut here" line)
            (values blocks #f)
            (values (cons (add-block-line! block
-                                          `(span (@ (class "line")) ,line))
+                                          `(div (@ (class "line")) ,line))
                          other-blocks)
                    context)))
       ((eq? context 'diff)
@@ -79,17 +79,17 @@ with the next context."
            (let ((formatted-line
                   (cond
                    ((string= "---" line)
-                    `(span (@ (class "line diff separator")) ,line))
+                    `(div (@ (class "line diff separator")) ,line))
                    ((string-prefix? "+" line)
-                    `(span (@ (class "line diff addition")) ,line))
+                    `(div (@ (class "line diff addition")) ,line))
                    ((and (string-prefix? "-" line)
                          (not (string= "--" line))
                          (not (string= "-- " line)))
-                    `(span (@ (class "line diff deletion")) ,line))
+                    `(div (@ (class "line diff deletion")) ,line))
                    ((string-prefix? "@@" line)
-                    `(span (@ (class "line diff range")) ,line))
+                    `(div (@ (class "line diff range")) ,line))
                    (else
-                    `(span (@ (class "line")) ,line)))))
+                    `(div (@ (class "line")) ,line)))))
              (values (cons (add-block-line! block formatted-line)
                            other-blocks)
                      context))))
@@ -97,7 +97,7 @@ with the next context."
        (if (string-prefix? ">" line)
            ;; Add line to current block
            (values (cons (add-block-line! block
-                                          `(span (@ (class "line")) ,line))
+                                          `(div (@ (class "line")) ,line))
                          other-blocks)
                    context)
            ;; Retry
@@ -124,28 +124,28 @@ with the next context."
                           ((uri-string . rest)
                            (or (and=> (string->uri uri-string)
                                       (lambda (uri)
-                                        `(span (@ (class "line"))
-                                               ,(string-trim-right pre #\<)
-                                               (a (@ (href ,uri-string))
-                                                  ,uri-string)
-                                               ,(string-join rest " "))))
-                               `(span (@ (class "line")) ,line)))))))
+                                        `(div (@ (class "line"))
+                                              ,(string-trim-right pre #\<)
+                                              (a (@ (href ,uri-string))
+                                                 ,uri-string)
+                                              ,(string-join rest " "))))
+                               `(div (@ (class "line")) ,line)))))))
                ((or (string-prefix? "Signed-off-by" line)
                     (string-prefix? "Co-authored-by" line))
-                `(span (@ (class "line commit attribution")) ,line))
+                `(div (@ (class "line commit attribution")) ,line))
                ((or (string-prefix? "From: " line)
                     (string-prefix? "Date: " line)
                     (string-prefix? "Subject: " line))
-                `(span (@ (class "line commit header")) ,line))
+                `(div (@ (class "line commit header")) ,line))
                ((or (string-prefix? "* " line)
                     (string-prefix? " * " line))
-                `(span (@ (class "line commit changelog")) ,line))
+                `(div (@ (class "line commit changelog")) ,line))
                ((string-prefix? "diff --git" line)
-                `(span (@ (class "line diff file")) ,line))
+                `(div (@ (class "line diff file")) ,line))
                ((string-prefix? "--8<---------------cut here" line)
                 "")
                (else
-                `(span (@ (class "line")) ,line)))))
+                `(div (@ (class "line")) ,line)))))
          (if (eq? new-context context)
              (values (cons (add-block-line! block formatted-line)
                            other-blocks)

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

[Jan Nieuwenhuizen]

Ricardo Wurmus writes:

> The attached patch seems to fix the worst problems.

Ohh...thank you!!!  This makes issues at least readable in EWW.

It's a bit annoying to change issues URLs into bugs.gnu.org urls and
this also made me reluctant to share issues URLs -- altough I greatly
appreciate all the work you have been doing here: in heavyweight modern
mouse-shoving-browsers --that I personally try to avoid-- it really
looks beautiful.

> What do you think?

It seems that EWW ignores ’monospace’...

-.message span.line {
+.message div.line {
     white-space: pre-wrap;
     font-family: monospace;
     display: block;
 }

... here, or otherwise "eats" spaces; so diffs/patches are still a bit
annoying to read.  Ideas?

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

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

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

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Earlier, I wrote:
> 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.

Actually, I just found by experimentation that option (2) above doesn't
work well in either Lynx or Dillo.  Option (1) works well in the simple
browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.

       Mark



[-- Attachment #2: Example HTML for Option 1 --]
[-- Type: text/html, Size: 175 bytes --]

[-- Attachment #3: Example HTML for Option 2 --]
[-- Type: text/html, Size: 163 bytes --]

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

[Maxim Cournoyer]

Hello,

Mark H Weaver <mhw@netris.org> writes:

> Earlier, I wrote:
>> 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.
>
> Actually, I just found by experimentation that option (2) above doesn't
> work well in either Lynx or Dillo.  Option (1) works well in the simple
> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>
>        Mark

Friendly ping; it seems not much is missing to close this issue? :-).

Thank you,

Maxim

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

[Mark H Weaver]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Earlier, I wrote:
>>> 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.
>>
>> Actually, I just found by experimentation that option (2) above doesn't
>> work well in either Lynx or Dillo.  Option (1) works well in the simple
>> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>>
>>        Mark
>
> Friendly ping; it seems not much is missing to close this issue? :-).

<https://issues.guix.gnu.org/43159> is still essentially unreadable in
Emacs Eww and Lynx, as well as Dillo when CSS is disabled, because there
are many missing line breaks.

      Thanks,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

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

[Maxim Cournoyer]

Hi,

Mark H Weaver <mhw@netris.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> Earlier, I wrote:
>>>> 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.
>>>
>>> Actually, I just found by experimentation that option (2) above doesn't
>>> work well in either Lynx or Dillo.  Option (1) works well in the simple
>>> browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.
>>>
>>>        Mark
>>
>> Friendly ping; it seems not much is missing to close this issue? :-).
>
> <https://issues.guix.gnu.org/43159> is still essentially unreadable in
> Emacs Eww and Lynx, as well as Dillo when CSS is disabled, because there
> are many missing line breaks.

OK, thanks for the update, Mark.

Maxim

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

[Ricardo Wurmus]

This is now fixed in mumi.  I tested the change in eww and in icecat.

This was easier to implement than when the bug was first reported.  Due
to later developments I could limit the use of “pre” to lines in the
“diff” context, so that message text can still be reflown.

Sorry for the delay, but there was no way for me to take enough time to
work on mumi before.  You are all still more than welcome to contribute
to mumi.

I’m reconfiguring the server hosting issues.guix.gnu.org now, so this
change will go live as soon as that’s done.

-- 
Ricardo

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

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> This is now fixed in mumi.  I tested the change in eww and in icecat.
>
> This was easier to implement than when the bug was first reported.  Due
> to later developments I could limit the use of “pre” to lines in the
> “diff” context, so that message text can still be reflown.
>
> Sorry for the delay, but there was no way for me to take enough time to
> work on mumi before.  You are all still more than welcome to contribute
> to mumi.

No worries.  Thanks very much for fixing it!

> I’m reconfiguring the server hosting issues.guix.gnu.org now, so this
> change will go live as soon as that’s done.

Hmm.  Your mail headers indicate that you wrote the words above more
than 27 hours ago, but the problem persists on issues.guix.gnu.org.  I'm
now looking at <https://issues.guix.gnu.org/43159> with EWW, and the
line breaks in the diffs are still missing, making the diffs unreadable.
I also fetched the same URL with Wget, and there are no <pre> elements
within.  Any idea what's going on?

Anyway, thanks again for fixing this issue in Mumi.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

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

[Ricardo Wurmus]

Hi Mark,

>> I’m reconfiguring the server hosting issues.guix.gnu.org now, so this
>> change will go live as soon as that’s done.
>
> Hmm.  Your mail headers indicate that you wrote the words above more
> than 27 hours ago, but the problem persists on issues.guix.gnu.org.  I'm
> now looking at <https://issues.guix.gnu.org/43159> with EWW, and the
> line breaks in the diffs are still missing, making the diffs unreadable.
> I also fetched the same URL with Wget, and there are no <pre> elements
> within.  Any idea what's going on?

Yes, GC problems on berlin:
https://lists.gnu.org/archive/html/bug-guix/2021-12/msg00130.html

Pretty frustrating.  I only *just* got to reconfigure the machine and
restart mumi.  So it should really be fine now.

-- 
Ricardo

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

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:
> This is now fixed in mumi.  I tested the change in eww and in icecat.
>
> This was easier to implement than when the bug was first reported.  Due
> to later developments I could limit the use of “pre” to lines in the
> “diff” context, so that message text can still be reflown.

This is an enormous improvement, thank you!

However, in both EWW and Lynx, the embedded patches are rendered
double-spaced, i.e. there are empty lines inserted between every two
adjacent lines of every patch.  I guess that's because Mumi wraps each
individual line within its own 'pre' and 'div' elements, instead of
putting the entire patch within a single 'pre' element.

As a result, for users of EWW or Lynx, Mumi is still far inferior to the
web interface of Debian's bug tracking system (used by bugs.gnu.org).

Here's a sample of the HTML generated by Debbugs for a patch in
<https://bugs.gnu.org/43159>:

--8<---------------cut here---------------start------------->8---
<pre class="message">* guix/ui.scm (show-bug-report-information): Link to
&lt;<a href="https://guix.gnu.org/help/">https://guix.gnu.org/help/</a>&gt; instead of &lt;<a href="https://www.gnu.org/gethelp/">https://www.gnu.org/gethelp/</a>&gt;.
The former is much more useful and includes links to GNU manuals.
---
 guix/ui.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/guix/ui.scm b/guix/ui.scm
index 4d90a47bb9..87a1925a4b 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -542,8 +542,9 @@ There is NO WARRANTY, to the extent permitted by law.
 Report bugs to: ~a.&quot;) %guix-bug-report-address)
   (format #t (G_ &quot;
 ~a home page: &lt;~a&gt;&quot;) %guix-package-name %guix-home-page-url)
-  (display (G_ &quot;
-General help using GNU software: &lt;<a href="http://www.gnu.org/gethelp/&gt;&quot;)">http://www.gnu.org/gethelp/&gt;&quot;)</a>)
+  (format #t (G_ &quot;
+General help using Guix and GNU software: &lt;~a&gt;&quot;)
+           &quot;<a href="https://guix.gnu.org/help/&quot;">https://guix.gnu.org/help/&quot;</a>)
   (newline))
 
 (define (augmented-system-error-handler file)
-- 
2.28.0




</pre>
--8<---------------cut here---------------end--------------->8---

Here's the corresponding HTML generated by Mumi for the same 'diff':
(I've added newlines and indentation to make it more readable, but in
fact there were no newlines in this portion of Mumi's HTML output)

--8<---------------cut here---------------start------------->8---
<div class="block text">
  <div class="line commit changelog"><a class="line-anchor" id="1-lineno0" href="#1-lineno0"></a>* guix/ui.scm (show-bug-report-information): Link to</div>
  <div class="line"><a class="line-anchor" id="1-lineno1" href="#1-lineno1"></a><a href="https://guix.gnu.org/help/">https://guix.gnu.org/help/</a> instead of  https://www.gnu.org/gethelp/ .</div>
  <div class="line"><a class="line-anchor" id="1-lineno2" href="#1-lineno2"></a>The former is much more useful and includes links to GNU manuals.</div>
  <div class="line"><a class="line-anchor" id="1-lineno3" href="#1-lineno3"></a>---</div>
  <div class="line"><a class="line-anchor" id="1-lineno4" href="#1-lineno4"></a> guix/ui.scm | 5 +++--</div>
  <div class="line"><a class="line-anchor" id="1-lineno5" href="#1-lineno5"></a> 1 file changed, 3 insertions(+), 2 deletions(-)</div>
  <br />
</div>
<details class="block diff" open="open">
  <summary>Toggle diff (18 lines)</summary>
  <div class="line diff file"><a class="line-anchor" id="1-lineno7" href="#1-lineno7"></a>diff --git a/guix/ui.scm b/guix/ui.scm</div>
  <div class="line"><a class="line-anchor" id="1-lineno8" href="#1-lineno8"></a><pre>index 4d90a47bb9..87a1925a4b 100644</pre></div>
  <div class="line diff deletion"><a class="line-anchor" id="1-lineno9" href="#1-lineno9"></a><pre>--- a/guix/ui.scm</pre></div>
  <div class="line diff addition"><a class="line-anchor" id="1-lineno10" href="#1-lineno10"></a><pre>+++ b/guix/ui.scm</pre></div>
  <div class="line diff range"><a class="line-anchor" id="1-lineno11" href="#1-lineno11"></a><pre>@@ -542,8 +542,9 @@ There is NO WARRANTY, to the extent permitted by law.</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno12" href="#1-lineno12"></a><pre> Report bugs to: ~a.&quot;) %guix-bug-report-address)</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno13" href="#1-lineno13"></a><pre>   (format #t (G_ &quot;</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno14" href="#1-lineno14"></a><pre> ~a home page: &lt;~a&gt;&quot;) %guix-package-name %guix-home-page-url)</pre></div>
  <div class="line diff deletion"><a class="line-anchor" id="1-lineno15" href="#1-lineno15"></a><pre>-  (display (G_ &quot;</pre></div>
  <div class="line diff deletion"><a class="line-anchor" id="1-lineno16" href="#1-lineno16"></a><pre>-General help using GNU software: &lt;http://www.gnu.org/gethelp/&gt;&quot;))</pre></div>
  <div class="line diff addition"><a class="line-anchor" id="1-lineno17" href="#1-lineno17"></a><pre>+  (format #t (G_ &quot;</pre></div>
  <div class="line diff addition"><a class="line-anchor" id="1-lineno18" href="#1-lineno18"></a><pre>+General help using Guix and GNU software: &lt;~a&gt;&quot;)</pre></div>
  <div class="line diff addition"><a class="line-anchor" id="1-lineno19" href="#1-lineno19"></a><pre>+           &quot;https://guix.gnu.org/help/&quot;)</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno20" href="#1-lineno20"></a><pre>   (newline))</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno21" href="#1-lineno21"></a><pre> </pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno22" href="#1-lineno22"></a><pre> (define (augmented-system-error-handler file)</pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno23" href="#1-lineno23"></a><pre>-- </pre></div>
  <div class="line"><a class="line-anchor" id="1-lineno24" href="#1-lineno24"></a><pre>2.28.0</pre></div>
</details>
--8<---------------cut here---------------end--------------->8---

I don't know if enough people care about this, though.  I suppose there
are some advantages to Mumi's method of rendering patches, e.g. to
enable better CSS styling of patches for the majority of users who
prefer to do almost everything within a modern web browser.

In any case, Mumi is now usable in simple web browsers, and that's a
great improvement.  Thanks for taking the time to work on it, Ricardo.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

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

[Ricardo Wurmus]

Hi Mark,

> However, in both EWW and Lynx, the embedded patches are rendered
> double-spaced, i.e. there are empty lines inserted between every two
> adjacent lines of every patch.  I guess that's because Mumi wraps each
> individual line within its own 'pre' and 'div' elements, instead of
> putting the entire patch within a single 'pre' element.

It does indeed wrap each line, because otherwise we can’t style the
lines e.g. to highlight additions with green and deletions with red.

People who use Emacs anyway will have Emacs apply its own fontification,
so that’s of no use to them.  But people who use Emacs would probably
want to use the Emacs interface to Debbugs anyway.

The extra spacing between lines as seen in EWW is not intentional, and I
did not see this in my local tests.  (Perhaps different patches render
differently in EWW?)  I’ll add this to my TODO list.

> As a result, for users of EWW or Lynx, Mumi is still far inferior to the
> web interface of Debian's bug tracking system (used by bugs.gnu.org).

Note that you can also view the raw messages.  Every message part has
its own link; following that link you can see the unstyled plain text
rendering.

There’s nothing wrong with the sample HTML you posted.  Yes, mumi’s is
more verbose than just wrapping text in <pre>…</pre> because we need
more markup to tell browsers how to style the patch.

-- 
Ricardo

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

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

>> However, in both EWW and Lynx, the embedded patches are rendered
>> double-spaced, i.e. there are empty lines inserted between every two
>> adjacent lines of every patch.  I guess that's because Mumi wraps each
>> individual line within its own 'pre' and 'div' elements, instead of
>> putting the entire patch within a single 'pre' element.
>
> It does indeed wrap each line, because otherwise we can’t style the
> lines e.g. to highlight additions with green and deletions with red.

I think I've found a way to fix the double-spacing problem in EWW and
Lynx without sacrificing styling: put the entire patch within a single
'pre' element, and then put each line within a 'span' element.  The
styling of each line can then be applied to the 'span's.

What do you think?

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

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

[Jan Nieuwenhuizen]

Ricardo Wurmus writes:

> This is now fixed in mumi.  I tested the change in eww and in icecat.

Lovely, thank you!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com