💾 Archived View for gemi.dev › gemini-mailing-list › 000215.gmi captured on 2024-08-31 at 16:13:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi! When studying the documentation about the text format (and reading the mailing list messages) i started to think that the same argumentation that lead to adding a space after the list item marker (the '*') are valid to the heading marker as well. For example if i starts a line mentioning an IRC channel like that: #channel [...] this would be presented to the user as an header of level 1 which is not. The same would be true if i mention a tag for a social network. As for the list item i think would be a good idea to add a space to the header mark: so from "#" to "#<space>" and so on for header level 2 and 3. Not really sure if this is correct, though so i am looking forward for your comments. Bye! C.
On Sun, Jun 14, 2020 at 11:07:31AM +0200, cage wrote: > For example if i starts a line mentioning an IRC channel like that: > > #channel [...] > > this would be presented to the user as an header of level 1 which is > not. > > The same would be true if i mention a tag for a social network. I guess this is just as good an argument as the *emphasised* words clashing with list items thing. AFAIK it hasn't been spotted in the wild yet, but that's probably just a function of Geminispace being young and small. > As for the list item i think would be a good idea to add a space to > the header mark: so from "#" to "#<space>" and so on for header level > 2 and 3. This would be covered by Petite Abeille's proposal to just put a mandatory space after *all* the special line indicators. Is it silly that I'm sad this would require (on account of ### sub-sub-headings) changing "It is possible to unambiguously determine a line's type purely by inspecting its first three characters" to "first four characters"? It is silly. But three just feels like a much more *natural* choice of entirely arbitrary small number... Cheers, Solderpunk
On Sun, Jun 14, 2020 at 10:16:20AM +0000, solderpunk wrote: Hi solderpunk! > On Sun, Jun 14, 2020 at 11:07:31AM +0200, cage wrote: > > For example if i starts a line mentioning an IRC channel like that: > > > > #channel [...] > > > > this would be presented to the user as an header of level 1 which is > > not. > > > > The same would be true if i mention a tag for a social network. > > I guess this is just as good an argument as the *emphasised* words > clashing with list items thing. AFAIK it hasn't been spotted in the > wild yet, but that's probably just a function of Geminispace being young > and small. yes, and probably even less likely to occurs than the emphasis. > > As for the list item i think would be a good idea to add a space to > > the header mark: so from "#" to "#<space>" and so on for header level > > 2 and 3. > > This would be covered by Petite Abeille's proposal to just put a > mandatory space after *all* the special line indicators. > > Is it silly that I'm sad this would require (on account of > ### sub-sub-headings) changing "It is possible to unambiguously > determine a line's type purely by inspecting its first three characters" > to "first four characters"? It is silly. But three just feels like a > much more *natural* choice of entirely arbitrary small number... :) Well i think i can sort of understand, if i would need to choose to change the sentence above to "It is possible to unambiguously determine a line's type purely by inspecting its first *four* characters", and remove the sentence for inexplicable (even to me) reason i would choose the second! ;-D Anyway, i am starting writing a parser, it is refreshing (for my mind) the fact that the syntax is so simple and still effective! :) Bye! C.
Hi all I want to return to a heading lines proposal raised by cage back in June. gemini://gemi.dev/gemini-mailing-list/messages/001662.gmi I would like headers to require a space after the #, at least for the first level. Headings: # Foo ## Bar ### Baz ##Bar if you really want to ###Baz if you really want to The reason being that I'd love to use hashtags in my posts and I'd love to add them at the end, like this: #Backup #Administration I guess I can live with the requirement to add some filler text in front of the first tag: Tags: #Backup #Administration But I think requiring a space after level 1 headings would make more sense. What do you think? Cheers Alex
It should be rare for hashtags to appear at the beginning of a line (even in your example they didn't), but in such a case there could indeed be a conflict. In such cases perhaps something like \# could be used to start a line. The space idea also seems good to me and maybe more efficient. Personally I always space my headers as you suggested. Ben -- gemini://kwiecien.us/
IMO a better (way better) option will be just use `=` for headings but that conflicts with current spec & all the existing software. Requiring (at least one) space after # is equally good as long as it's applied to all headings & not just level 1 headings; it is probably not a good idea to introduce new corner cases when doing changes like this in spec. ________________________________ From: Gemini <gemini-bounces@lists.orbitalfox.eu> on behalf of Alex Schroeder <alex@gnu.org> Sent: Wednesday, July 22, 2020 7:55 To: Gemini <gemini at lists.orbitalfox.eu> Subject: [SPECS text/gemini] Heading lines proposal Hi all I want to return to a heading lines proposal raised by cage back in June. gemini://gemi.dev/gemini-mailing-list/messages/001662.gmi I would like headers to require a space after the #, at least for the first level. Headings: # Foo ## Bar ### Baz ##Bar if you really want to ###Baz if you really want to The reason being that I'd love to use hashtags in my posts and I'd love to add them at the end, like this: #Backup #Administration I guess I can live with the requirement to add some filler text in front of the first tag: Tags: #Backup #Administration But I think requiring a space after level 1 headings would make more sense. What do you think? Cheers Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200722/2ed6 6f0a/attachment-0001.htm>
I'm in favor of requiring at least one space after all headline levels for consistency. Sebastian Higgins <bctnry at outlook.com> writes: > IMO a better (way better) option will be just use `=` for headings but that conflicts with current spec & all the existing software. Requiring (at least one) space after # is equally good as long as it's applied to all headings & not just level 1 headings; it is probably not a good idea to introduce new corner cases when doing changes like this in spec. > ________________________________ > From: Gemini <gemini-bounces at lists.orbitalfox.eu> on behalf of Alex Schroeder <alex at gnu.org> > Sent: Wednesday, July 22, 2020 7:55 > To: Gemini <gemini at lists.orbitalfox.eu> > Subject: [SPECS text/gemini] Heading lines proposal > > Hi all > I want to return to a heading lines proposal raised by cage back in > June. > gemini://gemi.dev/gemini-mailing-list/messages/001662.gmi > > I would like headers to require a space after the #, at least for the > first level. > > Headings: > > # Foo > ## Bar > ### Baz > ##Bar if you really want to > ###Baz if you really want to > > The reason being that I'd love to use hashtags in my posts and I'd love > to add them at the end, like this: > > #Backup #Administration > > I guess I can live with the requirement to add some filler text in > front of the first tag: > > Tags: #Backup #Administration > > But I think requiring a space after level 1 headings would make more > sense. What do you think? > > Cheers > Alex -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
On Wednesday, July 22, 2020 9:55 AM, Alex Schroeder <alex at gnu.org> wrote: > #Backup #Administration Seems that hashtag don't like to be alone... Maybe 1 x #word could be a heading and several x #word could be hashtags... freD.
I'm certainly in favor of this; It could help make parsing headers a bit easier, make formatting more consistent and prevent problems with these sort of situations. ~luna -- Email domain proudly hosted at https://migadu.com
I'm certainly in favor of this; It could help make parsing headers a bit easier, make formatting more consistent and prevent problems with these sort of situations. ~luna -- Email domain proudly hosted at https://migadu.com
On Wed Jul 22, 2020 at 10:06 PM CEST, defdefred wrote: > Seems that hashtag don't like to be alone... > Maybe 1 x #word could be a heading and several x #word could be > hashtags... I have my doubts. On my blog I have 4788 pages with tags but 2325 of them have just one tag. Cheers Alex
I think geminitext should be readable even when it is not being rendered. Something like this isn't readable: ##something but this is: ## something So I like this proposal. I think everyone is using a space even though it's not mandatory yet. Paper
On Thursday 23 July 2020 13:56, Alex Schroeder <alex at gnu.org> wrote: > I have my doubts. On my blog I have 4788 pages with tags but 2325 of > them have just one tag. Leasiness? :-)
Okay, I am happy with this idea (in fact, for a minute or two I was thinking "didn't we already do this?!" - no, that was with list items, to avoid ambiguity with *this* kind of emphasis). At this point it seems like we may as well go "whole hog" and insist on at least one space after *all* the line type markers - that would mean quote lines starting with "> " and link lines starting with "=> ". Does anybody object to *that*? I strongly suspect that almost everybody is actually writing their content that way anyway, but perhaps not... Cheers, Solderpunk
> On Jul 23, 2020, at 21:33, Solderpunk <solderpunk at posteo.net> wrote: > > At this point it seems like we may as well go "whole hog" and insist on > at least one space after *all* the line type markers - that would mean > quote lines starting with "> " and link lines starting with "=> ". Amen.
Sounds like a good plan to me :D ~luna -- Email domain proudly hosted at https://migadu.com
On 2020-07-23 (Thursday) at 19:33, Solderpunk <solderpunk at posteo.net> wrote: > Okay, I am happy with this idea (in fact, for a minute or two I was > thinking "didn't we already do this?!" - no, that was with list items, > to avoid ambiguity with *this* kind of emphasis). > > At this point it seems like we may as well go "whole hog" and insist on > at least one space after *all* the line type markers - that would mean > quote lines starting with "> " and link lines starting with "=> ". Does > anybody object to *that*? I strongly suspect that almost everybody is > actually writing their content that way anyway, but perhaps not... The only possible problem is that, with '###' lines, clients will have to read *four* characters from the beginning of a line to determine what it is -- but I don't think that's asking too much. I am 100% on board with this proposal. -- ~ acdw acdw.net | breadpunk.club/~breadw
On Thu, Jul 23, 2020 at 09:33:43PM +0200, Solderpunk wrote: Hi! > At this point it seems like we may as well go "whole hog" and insist on > at least one space after *all* the line type markers - that would mean > quote lines starting with "> " and link lines starting with "=> ". In my opinion this is the best thing to do! (even if i have to change the parser a bit ;-D ;-D) Bye! C.
> At this point it seems like we may as well go "whole hog" and insist on > at least one space after all the line type markers - that would mean > quote lines starting with "> " and link lines starting with "=> ". Does > anybody object to that? I do sort of object to this. I don't think there's much value in switching the other definitions when a need hasn't been demonstrated. I have seen many links that don't have a space after the "=>", and I don't see why there needs to be a space after the quote marker either. It's nicer to read in both cases, but I'm not in favour of creating changes when they don't seem to be required. Why not just change the heading lines? Cheers, makeworld
Requiring a space for structural formatting seems wise. I don't believe the proposal implied that navigational formatting (=>) would require one. But regarding quotes, although the > prefix may be visually familiar from text threads its use is inconsistent at best with regard to space before or after. Requiring a space will definitely break multiply-nested multi-line things (or make them redundant). Which brings me to... If quotes are only meant for a single depth, but represent semantic rather than structural formatting (sourced content, could reasonably have an author or other meaningful attribution), would it make more sense to treat them like preformatted lines (line toggled) and retire the prefix entirely? If they are really only for visual distinction... Well I guess I don't think they ought to be. So as long as you're talking about updating the spec... Context: Hi! Long time observer (nearly a week!) first time poster. I hadn't seen deedum when I first began using my enthusiasm for both classic gopher and a lighter better secure-er web to begin writing dart/flutter libraries for Gemini. I'm a very low vision user and this approach to content is very welcome. It's been a fun exercise and there still seems to be room for a formal library on pubget and so forth, and I am imagining a kind conversational model where browsing and contributing are possible within the same experience. Anywho... Things I noticed in this process where I've tried to include robust edge case tests and simulate workflows that may be common to streamline anybody's ability to create content:
It was thus said that the Great Mad Ogrit once stated: > Requiring a space for structural formatting seems wise. I don't believe the > proposal implied that navigational formatting (=>) would require one. > > But regarding quotes, although the > prefix may be visually familiar from > text threads its use is inconsistent at best with regard to space before or > after. Requiring a space will definitely break multiply-nested multi-line > things (or make them redundant). The gemtext spec doesn't allow nesting at all, so multply-nested multi-line things are already a problem (as I found out when trying to convert HTML to gemtext). > Which brings me to... If quotes are only meant for a single depth, but > represent semantic rather than structural formatting (sourced content, > could reasonably have an author or other meaningful attribution), would it > make more sense to treat them like preformatted lines (line toggled) and > retire the prefix entirely? No. My blog (phlog, gemlog) makes extensive use of both <BLOCKQUOTE> and <PRE> tags. For instance this post from last year: gemini://gemini.conman.org/2019/03/31.1 In the originial HTML (http://boston.conman.org/2019/03/31.1), the format is something long the lines of: <BLOCKQUOTE> <P>...</P> <P>...</P> </BLOCKQUOTE> <P>...</P> <PRE> ... </PRE> <P>...</P> And while I had to go back quite a bit to find an entry with both a blockquote and preformatted text, I do use blockquotes and preformatted text quite often, and they have different semantic meanings. That post, by the way, shows how I deal with ordered lists in HTML (when gemtext only supports a type of unordered list). > * Quoted content when visually distinct has more in common with > preformatted content in that, while it can be wrapped and flowed, you're > often quoting something by copy-pasting at which point the original layout > can be relevant True. Trying to quote preformatted text is not easy with gemtext. That's one of the reasons I still prefer HTML (which Gemini *can* serve, by the way). -spc
I'm on board. It improves human readability, and ensures consistency. On Thu, Jul 23, 2020, 2:38 PM Solderpunk <solderpunk at posteo.net> wrote: > Okay, I am happy with this idea (in fact, for a minute or two I was > thinking "didn't we already do this?!" - no, that was with list items, > to avoid ambiguity with *this* kind of emphasis). > > At this point it seems like we may as well go "whole hog" and insist on > at least one space after *all* the line type markers - that would mean > quote lines starting with "> " and link lines starting with "=> ". Does > anybody object to *that*? I strongly suspect that almost everybody is > actually writing their content that way anyway, but perhaps not... > > Cheers, > Solderpunk > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200723/be32 a321/attachment.htm>
On Thu, Jul 23, 2020, 8:44 PM Sean Conner <sean at conman.org> wrote: > It was thus said that the Great Mad Ogrit once stated: > > Requiring a space for structural formatting seems wise. I don't believe > the > > proposal implied that navigational formatting (=>) would require one. > > > > But regarding quotes, although the > prefix may be visually familiar from > > text threads its use is inconsistent at best with regard to space before > or > > after. Requiring a space will definitely break multiply-nested multi-line > > things (or make them redundant). > > The gemtext spec doesn't allow nesting at all, so multply-nested > multi-line things are already a problem (as I found out when trying to > convert HTML to gemtext). > Right, so unless I'm willing to manually clean up copy-pasted material I end up with a bunch of individual lines treated as quote lines that then also contain superfluous text like >>>, >> > >, and >|>>|. > > > Which brings me to... If quotes are only meant for a single depth, but > > represent semantic rather than structural formatting (sourced content, > > could reasonably have an author or other meaningful attribution), would > it > > make more sense to treat them like preformatted lines (line toggled) and > > retire the prefix entirely? > > No. My blog (phlog, gemlog) makes extensive use of both <BLOCKQUOTE> and > <PRE> tags. For instance this post from last year: > > Sorry, I think I was being imprecise. I wasn't proposing to not support quotes as a separate concept from pre, but rather add an additional line toggle, eg ___ or something unlikely to appear in nominal plaintext, which would be handled in the same manner as pre - a toggle for blockquote, allowing for things like: So I tried ```lang=go func primes ()... ``` But Hofstadter's paper said ___src=gemini://princip.ia/hoff.gmi?335 Remember to add a terminal case like ```lang=python def isPrime()... ``` ___ (The src= is just a silly example and definitely serves a different purpose than lang=) Of course, you made me realize this would significantly complicate the toggle approach in the case of unmatched toggles overlapping and the inevitable nesting of alternating toggles. Come to think of it, I assume that pasting gemtext containing pre inside of pre toggles would still require some manual editing, for instance to add white space before the embedded pre. I'm guessing this is why nesting of any kind is not supported :-) I haven't fully grokked the archives yet so this may have already been discussed. > > > True. Trying to quote preformatted text is not easy with gemtext. > That's > one of the reasons I still prefer HTML (which Gemini *can* serve, by the > way) > My hope with supporting and popularizing gemtext is specifically to counteract the ways in which HTML has become very easy to make very inaccessible - even just the semantics of layout and flow. I'm in it to make and support an accessible client with font sizes I can read / screen-read no matter what the content is :) Even markdown, as many things do, has become just this side of easy to make hard to read and hard to make easy to edit and copy paste universally, so I do really value the notion of an intrinsic format that is easy to understand and reliably forward only parse-able. I originally felt the line toggle approach seemed like an odd burden on the client given the simplicity and line orientedness of the rest of the format, but I recognize it has the benefit of not requiring an an author to touch up content, reducing the barrier to entry of copy paste or generally including things that are otherwise hard to reformat (eg turn a funky table into tsv and dump it in pre). Obviously, the above silly example could just be decomposed into a single quote line, a single pre-block, and a link. But doing that requires the person composing this text to think about and do that decomposition possibly from text that they are simply copy pasting an existing pre-block in existing gemtext. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200724/5993 b2de/attachment.htm>
I also support the "spaces after all line type markers" idea, And I agree with the other poster (Paper?) that one of gemtext's best qualities is that it is intrinsically (and intuitively) human-readable even without rendering. It is, in fact, a totally WYSIWYG format. Into the future! Gary P.S. Astrobotany is going to need to update its links though... Ryan Knipe <sario528 at gmail.com> writes: > I'm on board. It improves human readability, and ensures consistency. > > On Thu, Jul 23, 2020, 2:38 PM Solderpunk <solderpunk at posteo.net> wrote: > >> Okay, I am happy with this idea (in fact, for a minute or two I was >> thinking "didn't we already do this?!" - no, that was with list items, >> to avoid ambiguity with *this* kind of emphasis). >> >> At this point it seems like we may as well go "whole hog" and insist on >> at least one space after *all* the line type markers - that would mean >> quote lines starting with "> " and link lines starting with "=> ". Does >> anybody object to *that*? I strongly suspect that almost everybody is >> actually writing their content that way anyway, but perhaps not... >> >> Cheers, >> Solderpunk >> -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
On Thu, Jul 23, 2020 at 10:08:02PM +0000, colecmac at protonmail.com wrote: Hi! > > At this point it seems like we may as well go "whole hog" and insist on > > at least one space after all the line type markers - that would mean > > quote lines starting with "> " and link lines starting with "=> ". Does > > anybody object to that? > > > I do sort of object to this. I don't think there's much value in switching > the other definitions when a need hasn't been demonstrated. I have seen many > links that don't have a space after the "=>", and I don't see why there needs to > be a space after the quote marker either. It's nicer to read in both cases, > but I'm not in favour of creating changes when they don't seem to be required. > > Why not just change the heading lines? This is a good question, let me show my opinion about why i agree with these changes. In short to me, the reason to put a space after ">" or "=>" is the same that changed "*" to "*<space>". If, in a distant future, a new convention appears for identify a word, or a text starting with a word using ">" (for example) the gemini parser will steps in an inconvenience like the ones we are discussing in this thread with "#". Because is (in my opinion) unlikely that a person (i mean an human being :-)) writing a text that will be read by other persons, marks a word using a string prefix that include a word separator (including space) after and before or in the middle of it i think would be a good idea change the format to require a space for any of the symbols Solderpunk mentioned. This is, of course, probably not the only reason to make this changes (and maybe is not very valid :)) but i can not find any better at this time! ;D I hope i was able to explain my point even with my bad English! Bye! C.
On Fri Jul 24, 2020 at 12:08 AM CEST, wrote: > Why not just change the heading lines? I guess my main motivation was to make the spec more regular/consistent. If half the line type markers require a space and half of them don't, writing an correct client requires constant reference back to the spec to double check these fine details. Ideally Gemini should "fit in your head" easily, as somebody else described it, and consistency goes a long way toward that. Cheres, Solderpunk
---