💾 Archived View for gemi.dev › gemini-mailing-list › 000088.gmi captured on 2023-11-04 at 12:24:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hello, I have an idea for quickly and vastly expanding the amount of content that is available in Geminispace. What about a Wikipedia mirror/proxy? I put proxy in quotes because it would modify the documents it returned in order to be largely text based. The main thing that's tripping <https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the fact that wikipedia <https://en.wikipedia.org> articles are written <https://en.wikipedia.org/wiki/Writing> with a lot of inline links. And navigating those links is a key part of the Wikipedia browsing experience. My naive read of the text/gemini format is that I would have to do something like: The main thing that's => gemini://gem.wiki-mirror.pizza/article.cgi?Tripping tripping me up is the fact that => gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia articles are => gemini://gem.wiki-mirror.pizza/article.cgi?Writing written with a lot of inline links. Which seems really clunky. The other option I'm considering is serving text/markdown, which I assume most Gemini clients would display as plain text. The problem then is that [links won't be clickable](http://dev/null). But maybe the mere existence of so much markdown content would incentivize some client author to add native support? Feedback is appreciated, thanks! -Travis
Personally, I think markdown would make the most sense in this usecase. > I have an idea for quickly and vastly expanding the amount of content > that is available in Geminispace. What about a Wikipedia mirror/proxy? I think this idea is kinda flawed. I can only speak for myself, but I'm guessing that most people here want the Geminispace to expand naturally, and for interesting and unique content to come up. There's nothing wrong with a Wikipedia proxy, but I feel like it misses the point a bit. If I want to read Wikipedia, I would just use Firefox. makeworld ??????? Original Message ??????? On Friday, May 15, 2020 6:10 PM, Travis Briggs <audiodude at gmail.com> wrote: > Hello, > > I have an idea for quickly and vastly expanding the amount of content that is available in Geminispace. What about a Wikipedia mirror/proxy? I put proxy in quotes because it would modify the documents it returned in order to be largely text based. > > The main thing that's tripping me up is the fact that wikipedia articles are written with a lot of inline links. And navigating those links is a key part of the Wikipedia browsing experience. > > My naive read of the text/gemini format is that I would have to do something?like: > > The main thing that's > =>?gemini://gem.wiki-mirror.pizza/article.cgi?Tripping?tripping > me up is the fact that > => gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia > articles are > => gemini://gem.wiki-mirror.pizza/article.cgi?Writing written > with a lot of inline links. > > Which seems really clunky. The other option I'm considering is serving text/markdown, which I assume most Gemini clients would display as plain text. The problem then is that [links won't be clickable](http://dev/null). But maybe the mere existence of so much markdown content would incentivize some client author to add native support? > > Feedback is appreciated, thanks! > -Travis
It was thus said that the Great Travis Briggs once stated: > Hello, > > I have an idea for quickly and vastly expanding the amount of content that > is available in Geminispace. What about a Wikipedia mirror/proxy? I put > proxy in quotes because it would modify the documents it returned in order > to be largely text based. > > The main thing that's tripping > <https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the fact > that wikipedia <https://en.wikipedia.org> articles are written > <https://en.wikipedia.org/wiki/Writing> with a lot of inline links. And > navigating those links is a key part of the Wikipedia browsing experience. > > My naive read of the text/gemini format is that I would have to do > something like: > > The main thing that's > => gemini://gem.wiki-mirror.pizza/article.cgi?Tripping tripping > me up is the fact that > => gemini://gem.wiki-mirror.pizza/article.cgi?Wikipedia wikipedia > articles are > => gemini://gem.wiki-mirror.pizza/article.cgi?Writing written > with a lot of inline links. > > Which seems really clunky. The other option I'm considering is serving > text/markdown, which I assume most Gemini clients would display as plain > text. The problem then is that [links won't be clickable](http://dev/null). > But maybe the mere existence of so much markdown content would incentivize > some client author to add native support? Okay, here's a blog post I made a few days ago [1] and how it could be rendered into a text/gemini. -spc [1] http://boston.conman.org/2020/04/23.1 === Of course, after I point the finger to LibreSSL [1] for the memory leak, I find the leak ? in my own code. => gemini://boston.conman.org/2020/04/22.1 [1] Sigh. Not knowing what else to do, I thought I would go through my TLS Lua module [2] to make sure I didn't miss anything. That's when I noticed that I was keeping a reference to a connection so that I can deal with the callbacks [3] from libtls. I was expecting the __gc() method to clean things up, but with a (non-weak) reference, that was never going to happen. => https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c [2] => https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c#L107 [3] Yes, just because you are using a garbage collected language doesn't mean you can't still have memory leaks. I verified that, yes indeed, the references were being kept around after the request was finished. It was then straightforward to fix the issue. That's not to say that libtls still isn't leaking memory?it is, but (it seems) only when you initialize it (which means it's not as bad). But I'll know in a day or two if I fixed the leak. I hope that was it.
On Fri, May 15, 2020 at 3:23 PM Sean Conner <sean at conman.org> wrote: > Okay, here's a blog post I made a few days ago [1] and how it could be > rendered into a text/gemini. > This looks like a really nice idea. Do you think it's a problem that for long Wikipedia articles, the refs could go into the hundreds or even thousands [1345]? [1345] //dev/nul -Travis
I was actually thinking of this problem today with respect to converting content with in-line linking to Gemini format. So far the best idea I could imagine is that during the conversion process the linked items are marked (for example, number in superscript) in reference to a list of links provided below, basically as a footnote or appendix either to the paragraph, section, or the entire page. Maybe not ideal, but with a little experimentation this method could result in a format that's pleasing/readable and also navigable especially if the user can manipulate their client to jump to the link they want... for example, by numbers or tabbing through them or some other jump mechanism. Or maybe Gemini should support in-line links of its own? It's already got some markdown elements in other aspects of page formatting. On 5/16/20 2:40 AM, Travis Briggs wrote: > The main thing that's tripping > <https://en.wikipedia.org/wiki/Psychedelic_experience> me up is the > fact that wikipedia <https://en.wikipedia.org> articles are written > <https://en.wikipedia.org/wiki/Writing> with a lot of inline links.
We need to make our own wiki ;) On 5/16/20 2:49 AM, colecmac at protonmail.com wrote: > I'm guessing that most people here want the Geminispace to expand > naturally
It was thus said that the Great Travis Briggs once stated: > On Fri, May 15, 2020 at 3:23 PM Sean Conner <sean at conman.org> wrote: > > > Okay, here's a blog post I made a few days ago [1] and how it could be > > rendered into a text/gemini. > > This looks like a really nice idea. Do you think it's a problem that for > long Wikipedia articles, the refs could go into the hundreds or even > thousands [1345]? Don't know until I see it. But I don't think it will be that bad, given the links appear below the paragraph they're found in. -spc (Give it a try if you can ... )
It was thus said that the Great Ben once stated: > Or maybe Gemini should support in-line links of its own? It's already > got some markdown elements in other aspects of page formatting. As I said before, check the archives [1] for previous discussions. It won't be hard to find them, as they make up about half the posts so far. -spc (It's a popular bike shedding topic ... ) [1] https://lists.orbitalfox.eu/archives/gemini/
This was done for gopher and can be found here: gopher://gopherpedia.com:70/1 You may be able to pick up some tricks from what they did (and possibly improve upon it). I have used gopherpedia a good amount and would probably use a gemini version. That said, I do think it would be nice to build out original (non-web-mirroring) content. But that certainly doesnt mean that we cant or should have some degree of both! --? Sent with https://mailfence.com Secure and private email
Hmm this convention of using square bracket note-citations inline, followed by the URL. It seems nice and gemini-friendly. How widely used is that? Can it be "recommended" as a good practice if you want to do inline links? I'm thinking if it is a sufficiently established practice, clients can look for this pattern. And then when a suitably designed client if it sees this, could reverse the process to provide an inline clickable link, and then no need to duplicate the URL in the displayed content e.g. Source of "some text with a citation [1] more text etc => gemini://domain/path [1] next paragraph" is then simply rendered as "some text with a citation [1] more text etc next paragraph" and when rendered by the client, the "[1]" is an active element. Regards - Luke On 15-May-2020 23:41, Sean Conner wrote: > It was thus said that the Great Ben once stated: >> Or maybe Gemini should support in-line links of its own? It's already >> got some markdown elements in other aspects of page formatting. > As I said before, check the archives [1] for previous discussions. It > won't be hard to find them, as they make up about half the posts so far. > > -spc (It's a popular bike shedding topic ... ) > > [1] https://lists.orbitalfox.eu/archives/gemini/ >
Thanks for the pointer, that's really helpful and cool and basically exactly what I was hoping to accomplish. Basically a "Simpsons did it" moment for me. Ah well. But I've contacted the author and maybe I can get some insight into what could be done differently the second time around. Cheers, -Travis On Fri, May 15, 2020 at 3:55 PM Brian Evans <b__m__e at mailfence.com> wrote: > This was done for gopher and can be found here: > > gopher://gopherpedia.com:70/1 > > You may be able to pick up some tricks from what they did (and possibly > improve upon it). > I have used gopherpedia a good amount and would probably use a gemini > version. That said, > I do think it would be nice to build out original (non-web-mirroring) > content. But that certainly > doesnt mean that we cant or should have some degree of both! > > > -- > Sent with https://mailfence.com > Secure and private email >
On Sat, May 16, 2020 at 02:55:25AM +0430, Ben wrote: > Or maybe Gemini should support in-line links of its own? It's already got > some markdown elements in other aspects of page formatting. I'm really not keen on adding in-line links. It would significantly increase the effort involved in parsing text/gemini documents - instead of peeking at the first 3 characters of a line and then being able to handle it, every line has to be split up into words and each word tested individually. Yes, there are e.g. Markdown libraries out there which will do this, but they're only usable if we adopt Markdown wholesale, which brings in a whole load of other problems. Not to mention that almost none of those libraries do anything other than convert to HTML, etc.). The current text/gemini definition was very carefully and painstakingly arrived at after a lot of discussion. I'm not saying it's perfect, but I think any future changes to it will be very minor, and something like a switch to in-line links is pretty well off-the-table at this point. I acknowledge that when you are used to being able to link in-line, not being able to feels weird and different and like you are forced into clunky ways of formatting your text. But the one-line-per-link format has real advantages, aside from extreme simplicity of parsing of presentation. It makes links extremely easy to find, and it encourages neat, well-organised layout where links are put into related lists. It works very well in particular for "landing pages" - text/gemini as a whole does, actually - the combination of headers, subheaders and sub-subheaders via #, ## and ###, with one-line-per-link, strongly encourages you to structure your site neatly and to layout the entire structure on the front page so that navigation is an absolute breeze. Chalk and cheese, when compared to modern websites. For content it doesn't always work as well, but before deciding that it just cannot work I propose we make a concerted effort to develop new writing habits/conventions which work with it as well as possible. Cheers, Solderpunk
On Sat, May 16, 2020 at 12:09:05AM +0100, Luke Emmet wrote: > How widely used is that? Can it be "recommended" as a good practice if you > want to do inline links? It's extremely widely used on Gopher, where you can't do any actual linking from within content pages (without resorting to ugly hacks that work well in practice but are definitely a violation of the spirit of the protocol). Cheers, Solderpunk
On 17-May-2020 09:40, solderpunk wrote: > On Sat, May 16, 2020 at 02:55:25AM +0430, Ben wrote: > >> Or maybe Gemini should support in-line links of its own? It's already got >> some markdown elements in other aspects of page formatting. > I'm really not keen on adding in-line links. It would significantly > increase the effort involved in parsing text/gemini documents - instead > of peeking at the first 3 characters of a line and then being able to > handle it, every line has to be split up into words and each word tested > individually. I think certain common idioms can be implemented by a client as a UI pretification, for example the frequently seen square bracket citations could be expanded [like this] or this [1]. The community could encourage this idiom as it is very gemini-friendly. => scheme://domain/path1 [like this] => scheme://domain/path2 [1] I'm working on a UI playground to explore some of these ideas, among others, hope to have something to show soon. - Luke
Luke Emmet <luke.emmet at gmail.com> writes: > I think certain common idioms can be implemented by a client as a UI > pretification, for example the frequently seen square bracket > citations could be expanded [like this] or this [1]. The community > could encourage this idiom as it is very gemini-friendly. > > => scheme://domain/path1 [like this] > => scheme://domain/path2 [1] I think something like this as a "best practice" is our best substitute for inline links. I'd add a short link description after the bracketed expression in the link line, like this[3] => gemini://domain/path3 [1] Further discussion of link formats I had tried things like *, ?, ?, as in print, but they're not that great visually, especially without the ability to superscript them. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
May 18, 2020 12:41 AM, "Jason McBrayer" <jmcbray at carcosa.net> wrote: > => gemini://domain/path3 [1] Further discussion of link formats > > I had tried things like *, ?, ?, as in print, but they're not that great > visually, especially without the ability to superscript them. technically you can use unicode with superscript block, like: x???? and whatnot, but that's...probably not the best way to go about it I like your format the best of the ones I've seen so far
I for one am Unicode-positive... it's actually one of the main reasons I chose to start using Gemini in the first place, so I could create pages/documents that use it. They might not render in old Unix terminals, but nowadays even my Linux desktop has support for crazy things like emoji that I now see even while I'm using irssi. We just have to embrace it. On 5/18/20 2:18 AM, jan6 at tilde.ninja wrote: > but that's...probably not the best way to go about it -- gemini://kwiecien.us/
---