Re: Long links
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 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? > >
Re: Long links
On Sat, Jan 4, 2020 at 19:23 Steven Penny 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?
Re: Long links
On Sat, Jan 4, 2020 at 19:58 Steven Penny 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, w
Re: Long links
On Sat, Jan 4, 2020 at 18:26 Steven Penny 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.
Re: Long links
On Sat, Jan 4, 2020 at 17:56 Steven Penny 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.
Re: issue tracker?
On Tue, May 19, 2020 at 15:49 Russell Adams wrote: > Is there a problem with submitting issues via the mailing list? Has > something > gone unaddressed? Do you have any statistics to show that there is > decreased > participation because you have to use email? Is something really > inefficient at > the moment? Did you have patches ignored? I think you have the null hypothesis backwards here. Do you have any statistics to show that issues _are not_ dropping through the cracks? Sending a “ping?” message on a ML is generally considered poor netiquette, and even if it were expected here, would make many requesters uncomfortable. That’s one of the fundamental things any tracker does—keeps statistics on and forces every issue to _some_ resolution, even if it’s “will not fix” or “on hold”. Things don’t just peter out and get forgotten like on email threads. (I have not done the exercise of perusing old email threads to see if I can find issues being dropped on the floor. But I’ve already found several apparent existence proofs. Whether they’re common or rare is a question I can’t answer without doing tedious manual work that is the entire raison d’être of a tracker.) I wouldn’t dispute that the Linux kernel ML, for the most part, works. But the Linux kernel mailing list is a rather different beast than the potential users of an issue tracker for any other software project I can imagine—the technical acumen expected of contributors is high, quotidian back-and-forth user-assistance exchanges with non-contributors are not tolerated, people are usually expected to offer fixes as working code and not simply prose bug reports or feature requests (except for critical or security issues), and patches and pull requests on the mailing list are dealt with using a distributed version-control system that was purpose-built for the task (though happens to have worked well enough to because the most widely-used DVCS period).