URLs get line-wrapped

Jaimie

Which breaks the autodetect for URLs, see my link in Message-ID: <0984929086@a6d6ac3baf684f8e8b01d1e1650d91dc.local>

Although my followup with the same URL in <> works, I think the line-wrapper should probably not force a line wrap when there's no breaking spaces in the line? Similar to quoted lines starting with a >
Although to be fair it did a nice job of treating - as a good breaking point 🙂

Andre

When does this happen?
In the reader or editor?

And what I understand, this just happens with message-id's?

Jaimie

I was pointing at a message with the example, with that message ID. Here's the raw text of the message:

There's a whole Brit games series, slightly odd selection to my eye and
nothing since 1997 or so, but still.
https://shop.royalmail.com/special-stamp-issues/video-games/video-games-stamp-set

And what came out and was sent to Usenet was wrapped. On downloading and viewing it, Usenapps "Oh it's a URL" parser didn't catch the whole link.

There's a whole Brit games series, slightly odd selection to my eye and
nothing since 1997 or so, but still.
https://shop.royalmail.com/special-stamp-issues/video-games/video-games-stamp
-set

(edit: exactly like the forum parser doesn't catch the whole link 😀)

If I wrap the URL in angle brackets <https://shop.royalmail.com/special-stamp-issues/video-games/video-games-stamp-set>, Usenapp does not break it into two lines. Hurray, thank you!

But users like me are dumb, and because the composition window doesn't wordwrap at 72 chars I don't realise how dumb until after the unbracketed URL is posted when it's too late and then I have to do a dumb looking followup saying "I was dumb, here's the URL again but properly this time". I don't mind looking dumb, but if machines can make me look smart I'm all for it.

It is a small detail, to be sure.

Andre

You are not dump, but it’s rather a mistake you only make once.
But I’ll see if I can make something like adding the brackets automatically.

Andre

In v0.66: Urls that are posted are automatically wrapped between angle brackets.

It's a bit experimental though.

Andre

Can this be marked as solved?

Jaimie

Afraid not - for a trial I used the same URL, and then Replied to it (you can see this in uk.test). The parser gets confused and the result is this...

On 1 Feb 2020 at 01:12:25 GMT, "Jaimie Vandenbergh"
<jaimie@usually.sessile.org> wrote:
>
><https://shop.royalmail.com/special-stamp-issues/video-games/video-games-stam> p-set
>
wrap one

Andre

Did you enter the whole url as one part into the window or did you pressed <enter> after games-stam?

What the parser does is takes everything after http(s): up to a space or linefeed and then include that part between angle brackets.

So it's important to enter one long url.

Jaimie

I wasn't sure, so I just tried it again. It's kinda odd.

Here's the initial post, I pasted the URL without <brackets> so those were successfully autoadded:

I hit reply and see this in the compose window,

I add some more text and then after I refresh I look at what went out,

It's awfully close to right, but has an extra > and has deleted two returns.

Andre

It was an experimental feature, but I'm going to remove it.
There are too many pitfalls and it's not possible to check them all.

Usenapp will remove all linefeeds in urls where possible and post them like that in both edited and quoted text.

Jaimie

Right - that fits. I was just going to post this pic from another newsreader, which now makes sense. Broken links for anyone not using usenapp.

I'd suggest going to the simple fix of just not wrapping continuous text, only add breaks on spaces even if it means going over the 72 char boundary. Other clients can sort out their own views, but "healing" a hard-wrapped URL is a difficult task.

Andre

Yes, it sad that not all clients see the text between the brackets as a part of the url.

Jaimie

Ooh, yeah. The code that removes hard-returns in URLS is way too enthusiastic:

The text "APFS volumes share space, so their apparent numbers can definitely be" in green should be in blue on the next line. (Message-ID: <r13ume$1r7a$1@gioia.aioe.org>)

Andre

I know and working on it right now.

Jaimie

Thumbs up! I'll leave you to it 🙂

Andre

I've just tested it in uk.test and it seems to be fixed in the next update.

Jaimie

Just had a look and it's still mangling lines after a URL, I put a comment on that thread.

Andre

The latest post in uk.test was not showing correctly in v0.67.1.
That version had a function that rebuild the original posting, but didn't do it very well.

That function is removed in v0.67.2.

Anyway, quoting and parsing urls is fine now.

Jaimie

Looks good! That was confusing, but of course you're right. Clients which try to improve on the raw message have to be absolutely flawless in their execution otherwise it's just not worth it. It's bad enough with character sets! Which Usenapp does seem to handle flawlessly.