Long links

Long links

[Steven Penny]

Sometimes I will have to deal with a long link, like this:

https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/String/lastIndexOf

I prefer to wrap long links if possible. This is allowed with reStructuredText:

    lastIndexOf_

    .. _lastIndexOf: https://developer.mozilla.org/docs/Web/JavaScript/
       Reference/Global_Objects/String/lastIndexOf

and also with AsciiDoc via link syntax:

    link:++https://developer.mozilla.org/docs/Web/JavaScript/Reference/
    Global_Objects/String/lastIndexOf++[lastIndexOf]

or variable syntax:

    :js: https://developer.mozilla.org/docs/Web/JavaScript/Reference

    {js}/Global_Objects/String/lastIndexOf

Does Org Mode have some way to deal with this?

Re: Long links

[Nicolas Goaziou]

Hello,

Steven Penny <svnpenn@gmail.com> writes:

> Sometimes I will have to deal with a long link, like this:
>
> https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/String/lastIndexOf
>
> I prefer to wrap long links if possible. This is allowed with reStructuredText:
>
>     lastIndexOf_
>
>     .. _lastIndexOf: https://developer.mozilla.org/docs/Web/JavaScript/
>        Reference/Global_Objects/String/lastIndexOf
>
> and also with AsciiDoc via link syntax:
>
>     link:++https://developer.mozilla.org/docs/Web/JavaScript/Reference/
>     Global_Objects/String/lastIndexOf++[lastIndexOf]
>
> or variable syntax:
>
>     :js: https://developer.mozilla.org/docs/Web/JavaScript/Reference
>
>     {js}/Global_Objects/String/lastIndexOf
>
> Does Org Mode have some way to deal with this?

You can use angular links, e.g.,

    <https://developer.mozilla.org/docs/Web/JavaScript/Reference/
    Global_Objects/String/lastIndexOf++[lastIndexOf]>

You can also use link abbreviations. Please refer to the manual for that
one.

Regards,

-- 
Nicolas Goaziou

Re: Long links

[Steven Penny]

On Sun, Dec 29, 2019 at 8:08 PM Nicolas Goaziou wrote:
> You can use angular links, e.g.,
>
>     <https://developer.mozilla.org/docs/Web/JavaScript/Reference/
>     Global_Objects/String/lastIndexOf++[lastIndexOf]>
>
> You can also use link abbreviations. Please refer to the manual for that
> one.

Hm, neither one of those methods seem to work with either of these parsers:

- https://github.com/niklasfasching/go-org
- https://github.com/wallyqs/org-ruby

Re: Long links

[Nicolas Goaziou]

Hello,

Steven Penny <svnpenn@gmail.com> writes:

> Hm, neither one of those methods seem to work with either of these parsers:
>
> - https://github.com/niklasfasching/go-org
> - https://github.com/wallyqs/org-ruby

You may want to see with the maintainers of these projects if they want
to implement it.

Regards,

-- 
Nicolas Goaziou

Re: Long links

[Steven Penny]

On Sun, Dec 29, 2019 at 8:08 PM Nicolas Goaziou wrote:
> You can use angular links, e.g.,
>
>     <https://developer.mozilla.org/docs/Web/JavaScript/Reference/
>     Global_Objects/String/lastIndexOf>

Can you link to where this is documented? It seems the example you gave here is
not valid, as Org Mode uses square brackets:

    [[https://developer.mozilla.org/docs/Web/JavaScript/Reference]]

https://gnu.org/software/emacs/manual/html_node/org/Link-format

Re: Long links

[Nicolas Goaziou]

Hello,

Steven Penny <svnpenn@gmail.com> writes:

> On Sun, Dec 29, 2019 at 8:08 PM Nicolas Goaziou wrote:
>> You can use angular links, e.g.,
>>
>>     <https://developer.mozilla.org/docs/Web/JavaScript/Reference/
>>     Global_Objects/String/lastIndexOf>
>
> Can you link to where this is documented? It seems the example you gave here is
> not valid

Have you tried it?

> as Org Mode uses square brackets:
>
>     [[https://developer.mozilla.org/docs/Web/JavaScript/Reference]]
>
> https://gnu.org/software/emacs/manual/html_node/org/Link-format

In a recent manual, the section "Link format" starts with:

   Org recognizes plain URIs, possibly wrapped within angle
   brackets[fn:23], and activate them as clickable links.

The example I gave you is an angle link.

Regards,

-- 
Nicolas Goaziou

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 11:44 AM Nicolas Goaziou wrote:
> In a recent manual, the section "Link format" starts with:
>
>    Org recognizes plain URIs, possibly wrapped within angle
>    brackets[fn:23], and activate them as clickable links.
>
> The example I gave you is an angle link.

Yes, I do see that documentation now. I also see this:

> [fn:23] Plain URIs are recognized only for a well-defined set of schemes. See
> External Links. Unlike URI syntax, they cannot contain parenthesis or white
> spaces, either. URIs within angle brackets have no such limitation.

https://github.com/bzg/org-mode/blob/master/doc/org-manual.org#footnotes

However what is troubling is that in both of these pages:

- https://github.com/bzg/org-mode/blob/master/doc/org-guide.org
- https://github.com/bzg/org-mode/blob/master/doc/org-manual.org

not a single example is provided of this syntax. Perhaps one could be added for
clarity?

Re: Long links

[Trey Ethan Harris]

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

If you won’t take a possible XY problem answer amiss: In general, I’ve
found it much easier to use visual-line-mode than to worry about all
this—in fact, I have visual-line-mode set to automatically engage in
org-mode. At some point in 2016 I see from my Git history that I un-filled
all my Org files (i.e., changed “paragraphs” interspersed with newlines
near fill-column to a single line per paragraph no matter how long it is),
so for some ten years before that I was wrapping lines and just got tired
of the hassle.

And when writing longer passages of prose, I also toggle olivetti-mode
on—it rewraps and centers the column of text (not centering every line,
just the column) in a wide window. My olivetti-mode width is set to 70
chars, so even though my fullscreen Emacs is about 166 characters wide; if
I have a single window open I get 70-char-width lines in the middle of the
screen; if I have two windows open side-by-side, they each get a column
margin.

In cases like this, these solutions result in long URL’s getting
interrupted by backlashes in the rightmost column in display, but in the
original file (and if you kill copy by region) the long URL’s are just
present in their original forms.

On Sat, Jan 4, 2020 at 16:58 Steven Penny <svnpenn@gmail.com> wrote:

> On Sat, Jan 4, 2020 at 11:44 AM Nicolas Goaziou wrote:
> > In a recent manual, the section "Link format" starts with:
> >
> >    Org recognizes plain URIs, possibly wrapped within angle
> >    brackets[fn:23], and activate them as clickable links.
> >
> > The example I gave you is an angle link.
>
> Yes, I do see that documentation now. I also see this:
>
> > [fn:23] Plain URIs are recognized only for a well-defined set of
> schemes. See
> > External Links. Unlike URI syntax, they cannot contain parenthesis or
> white
> > spaces, either. URIs within angle brackets have no such limitation.
>
> https://github.com/bzg/org-mode/blob/master/doc/org-manual.org#footnotes
>
> However what is troubling is that in both of these pages:
>
> - https://github.com/bzg/org-mode/blob/master/doc/org-guide.org
> - https://github.com/bzg/org-mode/blob/master/doc/org-manual.org
>
> not a single example is provided of this syntax. Perhaps one could be
> added for
> clarity?
>
>

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

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 4:35 PM Trey Ethan Harris wrote:
> At some point in 2016 I see from my Git history that I un-filled all my Org
> files (i.e., changed “paragraphs” interspersed with newlines near fill-column
> to a single line per paragraph no matter how long it is), so for some ten
> years before that I was wrapping lines and just got tired of the hassle.

Nope. I have been dealing with long links for many years, since at least 2011.
Last month I learned that both reStructuredText and AsciiDoc can deal with them
pretty easily. Now that I know this, I am more included to use Markups that have
that capability.

Re: Long links

[Trey Ethan Harris]

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

On Sat, Jan 4, 2020 at 17:56 Steven Penny <svnpenn@gmail.com> wrote:

> On Sat, Jan 4, 2020 at 4:35 PM Trey Ethan Harris wrote:
> > At some point in 2016 I see from my Git history that I un-filled all my
> Org
> > files (i.e., changed “paragraphs” interspersed with newlines near
> fill-column
> > to a single line per paragraph no matter how long it is), so for some ten
> > years before that I was wrapping lines and just got tired of the hassle.
>
> Nope. I have been dealing with long links for many years, since at least
> 2011.
> Last month I learned that both reStructuredText and AsciiDoc can deal with
> them
> pretty easily. Now that I know this, I am more included to use Markups
> that have
> that capability.
>
Not sure what you mean by “Nope”—I don’t publish the Org files I’m
talking about, but I could show you some sample diffs if you don’t believe
me for some reason...

But my larger point was that for me, _stored_ line length (as opposed to
displayed line length) should be dictated by export, not for some arbitrary
purpose. By doing it this way, source blocks get wrapped according to their
modes’ ordinary behavor (which is what I want if I ever publish the code),
and prose text is stored in “paragraph, 2 × newlines, paragraph, 2 ×
newlines, paragraph” form—which ,for pretty much everything except email
these days, is what you want.

A common purpose I put Org prose to is editing text I will post as web
content, like in a forum; I’ve found a distressingly high proportion of
comments parsers can’t deal with newline-wrapped text and turns each
72-column line into a paragraph. But almost all of these treat blank lines
delimiting paragraphs correctly. So storing my text this way requires the
least post processing—blocks get post processed by content-aware dedicated
exporters, while interstitial text may or may not—but it’s at least always
in a  form that 95% of the time can just be cut-and-paste, if nothing else.

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

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 5:08 PM Trey Ethan Harris wrote:
> But my larger point was that for me, _stored_ line length (as opposed to
> displayed line length) should be dictated by export, not for some arbitrary
> purpose.

I dont think you understand, I want what I work on and publish to be readable.
On my own system thats easy enough, and your method would work fine. But if you
publish to GitHub or other sites, they have their own view of what a proper
display should be.

For example with GitHub, you dont get to choose tab width, and you dont get to
choose wrapping modes. GitHub uses 8 width tabs, and doesnt wrap at all. So if
you have any long lines you have to horizontal scroll, and if you dont like tab
width then you need to use spaces.

Granted I could just set some user CSS, but then anyone else visiting my pages
wont get the benefit of that.

I would please ask that you not comment further on this off topic discussion.
Unless you have an on topic comment regarding breaking long links I am not
interested, thank you.

Re: Long links

[Trey Ethan Harris]

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

On Sat, Jan 4, 2020 at 18:26 Steven Penny <svnpenn@gmail.com> wrote:

> I dont think you understand, I want what I work on and publish to be
> readable.
> On my own system thats easy enough, and your method would work fine. But
> if you
> publish to GitHub or other sites, they have their own view of what a proper
> display should be.
>
> For example with GitHub, you dont get to choose tab width, and you dont
> get to
> choose wrapping modes. GitHub uses 8 width tabs, and doesnt wrap at all.
> So if
> you have any long lines you have to horizontal scroll, and if you dont
> like tab
> width then you need to use spaces.
>
> Granted I could just set some user CSS, but then anyone else visiting my
> pages
> wont get the benefit of that.
>
> I would please ask that you not comment further on this off topic
> discussion.
> Unless you have an on topic comment regarding breaking long links I am not
> interested, thank you.
>

I think you did not explain your issue clearly, then—on GitHub, long lines
and long links are displayed perfectly, as this example with a
434-character line and your originally-mentioned link shows, with no
horizontal scrolling and no special styling:

https://gist.github.com/treyharris/fcfb2558806e35ffc8d3dd4502a06c39

So if neither what the Emacs screen displays nor what the site you say
you’re publishing to displays is on-topic, I don’t know what is on-topic.
What problem are you trying to solve exactly? A URL showing the horizontal
scrolling would be helpful.

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

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 6:18 PM Trey Ethan Harris wrote:
> I think you did not explain your issue clearly, then—on GitHub, long lines and
> long links are displayed perfectly, as this example with a 434-character line
> and your originally-mentioned link shows, with no horizontal scrolling and no
> special styling:
>
> https://gist.github.com/treyharris/fcfb2558806e35ffc8d3dd4502a06c39

If you had browsed beyond even the most basic example, you would see that your
point falls apart:

https://github.com/cup/autumn/blob/master/docs/append-to-array/index.html

Re: Long links

[Trey Ethan Harris]

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

On Sat, Jan 4, 2020 at 19:23 Steven Penny <svnpenn@gmail.com> wrote:

> On Sat, Jan 4, 2020 at 6:18 PM Trey Ethan Harris wrote:
> > I think you did not explain your issue clearly, then—on GitHub, long
> lines and
> > long links are displayed perfectly, as this example with a 434-character
> line
> > and your originally-mentioned link shows, with no horizontal scrolling
> and no
> > special styling:
> >
> > https://gist.github.com/treyharris/fcfb2558806e35ffc8d3dd4502a06c39
>
> If you had browsed beyond even the most basic example, you would see that
> your
> point falls apart:
>
> https://github.com/cup/autumn/blob/master/docs/append-to-array/index.html


Uh... that’s an HTML file—this is the emacs-orgmode mailing list. And
viewing that page as rendered HTML in a browser, there’s no horizontal
scrolling I see (and doesn’t appear to be with your styles as rendered at
https://cup.github.io/autumn/append-to-array/). I was asking for an example
of an Org mode file showing the issue that’s concerning you, not just proof
that GitHub sometimes does horizontal scrolling.

If you’re asking about long lines in general that could be generated as
export from Org-mode to any other format, such as Org *into* HTML, and then
want to limit the lengths of the lines of the exported document code
generated, in characters—and not what is displayed in width as pixels—then
I don’t understand why you’d even be looking at Org-mode’s own link syntax.
Line breaks in an Org file do not, in the general case, propagate into
exported formats (except when line breaks are significant, like in source
blocks). So successfully line-breaking in the middle of a URL in Org
wouldn’t necessarily generate a line-broken URL in the resulting HTML (or
TeX or PDF, source or rendered).

In any case, there will be no single solution to this—any ox library for
Org export you use will have to be modified if they don’t handle
line-breaks the way you want.

If you’re planning on including verbatim Org source examples _in_ the
generated HTML (as you are currently doing for comparing programming
languages), that’s the case where a long Org source line might bleed
visibly into the final rendered output. Are you?

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

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 6:45 PM Trey Ethan Harris wrote:
> Uh... that’s an HTML file—this is the emacs-orgmode mailing list.

My original post:

https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00422.html

was, and is still on topic. Yet you found a way to make 4 posts without
addressing the original post directly.

> And viewing that page as rendered HTML in a browser, there’s no horizontal
> scrolling I see (and doesn’t appear to be with your styles as rendered at
> https://cup.github.io/autumn/append-to-array/).

You should perhaps respond to what ive actually said, rather than what you think
im saying. Again this page here:

https://github.com/cup/autumn/blob/master/docs/append-to-array/index.html

is an example of GitHub not wrapping and requiring horizontal scrolling.

> I was asking for an example of an Org mode file showing the issue that’s
> concerning you, not just proof that GitHub sometimes does horizontal scrolling.

again, see original post for example problem:

https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00422.html

> In any case, there will be no single solution to this—any ox library for Org
> export you use will have to be modified if they don’t handle line-breaks the
> way you want.

it seems you didnt even read all the responses, some good suggestions were
posted here:

https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00423.html

Re: Long links

[Trey Ethan Harris]

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

On Sat, Jan 4, 2020 at 19:58 Steven Penny <svnpenn@gmail.com> wrote:

> On Sat, Jan 4, 2020 at 6:45 PM Trey Ethan Harris wrote:
> > Uh... that’s an HTML file—this is the emacs-orgmode mailing list.
>
> My original post:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00422.html
>
> was, and is still on topic. Yet you found a way to make 4 posts without
> addressing the original post directly.


I literally included the link mentioned in your first post in my example
Org file to address the question of whether it would cause horizontal
scrolling. I couldn’t more directly address the original post without
inventing new syntax for software that doesn’t exist.


> > And viewing that page as rendered HTML in a browser, there’s no
> horizontal
> > scrolling I see (and doesn’t appear to be with your styles as rendered at
> > https://cup.github.io/autumn/append-to-array/).
>
> You should perhaps respond to what ive actually said, rather than what you
> think
> im saying. Again this page here:
>
> https://github.com/cup/autumn/blob/master/docs/append-to-array/index.html
>
> is an example of GitHub not wrapping and requiring horizontal scrolling.


...and which, again, has nothing to do with Org whatsoever—it’s simply an
existence proof that GitHub sometimes does horizontal scrolling, which is
entirely irrelevant to anything having anything to do with Org. (If you
make your browser window narrow enough or use a phone, even the RST,
asciiDoc and other examples you gave will horizontal-scroll, too!)


> > I was asking for an example of an Org mode file showing the issue that’s
> > concerning you, not just proof that GitHub sometimes does horizontal
> scrolling.
>
> again, see original post for example problem:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00422.html
>


You said you want to “deal with” long links in Org. But your example HTML
file linked to has nothing to do with Org syntax AFAICT—it’s just a file
that happens to horizontally scroll when viewed as source on GitHub.

None of those links in your first post have any Org syntax in them. And
it’s not what the links point to—they are about JavaScript. Org syntax has
nothing to do with JavaScript.

The links as given in the original post *themselves* are long—so I assumed
that was the point. But as I showed, that doesn’t matter in how they’re
displayed in Emacs if you select the right display mode; and that doesn’t
matter in how they’re displayed on GitHub in an Org file (again, I used
exactly the very link you started the just-linked-to post with in my Org
file).


> > In any case, there will be no single solution to this—any ox library for
> Org
> > export you use will have to be modified if they don’t handle line-breaks
> the
> > way you want.
>
> it seems you didnt even read all the responses, some good suggestions were
> posted here:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00423.html
>

I absolutely did read that—I read the entire thread before responding since
it seemed that none of he suggestions thus far had actually worked.

GitHub doesn’t deal with the “good suggestions” correctly, so I didn’t
include them in my first Gist posted. I tried them first—I not only did
read the mail you’re claiming I didn’t, I wrote a new Org file to test the
suggestions within before posting anything. But here’s a Gist displaying a
rendered Org file using those “good suggestions”:

https://gist.github.com/treyharris/9dd193a4a1e34f0ba1619e8b04aecff1

It doesn’t handle the link correctly, and, if you make it long enough on a
given line, the bare sliced-in-twain URL you must cut and paste and remove
spaces from if you want to use the URL will still horizontally scroll.

Since it doesn’t work on GitHub—which is where you said you published to
and care about—I’m mystified on how it’s a “good suggestion” where my
syntax is not. (No disrespect meant to Nicolas at all—they *were* good
suggestions, insofar as they were worth trying. But I tried them.)

I answered suggesting a different course because I thought you cared about
how it actually displayed, not how it might display if the software worked
differently than it does.

The other “good suggestion” was link abbreviations. My Gist given above
gives one of those as well, and that one, GitHub doesn’t even make any
attempt at—it just displays it as plain text.

Note: if GitHub did deal with these “good suggestions” correctly, it would
display just “lastIndexOf”—just like my Gist does in its first hyperlink,
except mine says “long link” where that says “lastIndexOf”. But yet
apparently that working example is *not* a “good suggestion”, though,
compared to the ones that don’t work. (If you generally find examples that
don’t work acceptable, you can just insert {{{dwim}}} into any place in
your file you want a link, and it’ll do what you mean, whatever that is. It
works great on every implementation that supports it!)

If you are being incredibly clear and I’m being incredibly obtuse,
fine—I’ll drop it and someone who can divine what the heck you’re asking
for can respond instead. Or, you can continue attacking me for not reading
what you wrote when I literally included quoted material from you in a file
I published to illustrate the issue. Be my guest.

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

Re: Long links

[Steven Penny]

On Sat, Jan 4, 2020 at 8:13 PM Trey Ethan Harris wrote:
> I literally included the link mentioned in your first post in my example Org
> file to address the question of whether it would cause horizontal scrolling.

which would have been nice if my question was, "how to I configure my software
to wrap without inserting newlines?" but the question actually was, how to enter
newline that are removed in the output.

> ...and which, again, has nothing to do with Org whatsoever—it’s simply an
> existence proof that GitHub sometimes does horizontal scrolling, which is
> entirely irrelevant to anything having anything to do with Org. (If you make
> your browser window narrow enough or use a phone, even the RST, asciiDoc and
> other examples you gave will horizontal-scroll, too!)

yes, and I would have never made this point had you not insisted on starting an
off topic conversation.

> You said you want to “deal with” long links in Org. But your example HTML file
> linked to has nothing to do with Org syntax AFAICT—it’s just a file that
> happens to horizontally scroll when viewed as source on GitHub.

again you seems to be totally missing the point here.

i can set my paragraphs to be single line as youve suggested. and with org mode
files, even GitHub will render them correctly.

But as you can imagine, I dont only work with Org Mode files. I also work with
Python files, Go, Dart and a number of other types. And none of these other
types get the wrapping on GitHub. So in order to have the best result across all
my files, I prefer to do hard wrapping. That is easy enough to handle in all
cases except the one ive presented in the original post.

The one that youve yet to address directly. Now again I dont wish to discuss or
get into further the merits of hard wrapping vers soft. So perhaps you can take
that discussion elsewhere and keep this on topic.

Next we know you will say why someone is using spaces over tabs, or emac over
vim, or red over blue bikeshed. Stop.

Re: Long links

[Adam Porter]

Steven Penny <svnpenn@gmail.com> writes:

> yes, and I would have never made this point had you not insisted on
> starting an off topic conversation.
>
> Next we know you will say why someone is using spaces over tabs, or
> emac over vim, or red over blue bikeshed. Stop.

This rude one-upsmanship is uncalled for.  The gentleman attempted to
offer you a solution you did not appear to be aware of.  If, in fact,
one of you misunderstood the other, or he offered you a solution you
can't use, no harm has been done--thank him for his offer and move on.
Or, if you can't be kind, let it be unanswered.

Re: Long links

[Fraga, Eric]

On Saturday,  4 Jan 2020 at 20:57, Steven Penny wrote:
> But as you can imagine, I dont only work with Org Mode files. I also work with
> Python files, Go, Dart and a number of other types. And none of these other
> types get the wrapping on GitHub.

As it may be.  But maybe I'm missing the point as well.  I do not see
what github's behaviour has to do with org mode's display of links
(angle brackets or not).  Should you be asking github to change?

Your original post simply said you wished to wrap long lines and you
said "Does Org Mode have some way to deal with this?".  Trey gave you
one way: use visual-line-mode (which is also what I use and have done
for years).  His response was on-topic.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Re: Long links

[Steven Penny]

On Sun, Jan 5, 2020 at 2:03 AM Fraga, Eric wrote:
> Your original post simply said you wished to wrap long lines and you
> said "Does Org Mode have some way to deal with this?".  Trey gave you
> one way: use visual-line-mode (which is also what I use and have done
> for years).  His response was on-topic.

If I was not clear initially I apologize, but I think in the mails since I have
made it exceeding clear what the expected input and output should be. But just
in case, here it is again. For this Org Mode input or similar (note the multiple
lines):

https://lists.gnu.org/
archive/html

this HTML output should be produced:

<a href="https://lists.gnu.org/archive/html">https://lists.gnu.org/archive/html</a>

Some valid suggestions are here already:

https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00423.html

So you can understand why I was annoyed when Trey started his off topic
discussion about hard versus soft wrapping.

Re: Long links

[Eduardo Ochs]

Hi Steven,

On Sun, 5 Jan 2020 at 11:03, Steven Penny <svnpenn@gmail.com> wrote:
>
> So you can understand why I was annoyed when Trey started his off
> topic discussion about hard versus soft wrapping.

We understand, but now lots of people are annoyed with you.

Trey wrote his e-mails very carefully, and even if his suggestions
weren't exactly what you were looking for they were given in good
faith and they were useful to other people - for example to me.

Most people here read e-mails paying attention both to their technical
contents and to the "social contents" of them... in terms of social
contents Trey's e-mails were impeccable, and this one was especially
brilliant:

https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00029.html

I want to be like him when I grow up.

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/#eev
    http://angg.twu.net/emacsconf2019.html