Re: Long links

[Trey Ethan Harris]

On Sat, Jan 4, 2020 at 19:58 Steven Penny <address@hidden> 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.