Re: Recurring "please do" patterns in debian-mentors
"Paul Cager" <firstname.lastname@example.org> wrote:
> The policy *does* distinguish between lines starting with one space
> (paragraphs with word-wrapping) and lines starting with two or more spaces
> (non-wrapped if panning is possible, otherwise hard-wrapped), so I think
> there is a strong policy basis for the "Homepage" comment. Apart from
> anything else, it makes cutting and pasting URLs easier.
I wouldn't be so sure.
If len("Homepage: " + URL) <= screen_width, then both cases lead to the
same result. But if this is not true, what do you expect from the
frontend when a single leading space was used? Word-wrapping will cause
something like that:
Case 1 (single leading space)
which means you can copy and paste URLs in *one* step that are much
longer than in the case of two leading spaces:
Case 2a (two leading spaces, panning enabled)
-> you have to pan the screen to access the second part of the URL
-> copy/paste needs *two* steps
Case 2b (two leading spaces, hard wrapping instead of panning)
-> copy/paste is likely to need two steps, but not necessarily
And even then, I am being too kind to the two-leading-spaces cases,
because in both 2a and 2b, the front-end should use the last character
of the first line to indicate that the line is incomplete. Otherwise, in
case 2a, you cannot know that you have to pan in order to see the full
URL, and in case 2b, you cannot know (without resorting to the context)
that the second line is actually the continuation of the first line. And
that special "continuation character" would presumably kill the
possibility of copy-pasting the URL in one step in case 2b.
OK, there remains an obscure point in case 1, when the URL is longer
than a screen line. Should it be hyphenated? And if so, how, where? But
it isn't really worse than what happens in case 2, and is only triggered
with very long URLs (you start having problems in case 2 with shorter
Anyway, the URL should be a control field; then, we wouldn't be having
this rather pointless discussion.
 Well, not quite: the single-leading-space case wins because Policy
says that the leading space "will usually be stripped off", whereas
in the case of two leading spaces, "None, one or two initial spaces
may be deleted". As a consequence, the usable length of a line is
"usually" greater or equal in the one-leading-space case than in
the two-leading-spaces case. But that's a detail.