💾 Archived View for gemi.dev › gemini-mailing-list › 000166.gmi captured on 2023-12-28 at 15:42:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Hi, While testing a GUI text/gemini renderer I noticed that if a line starts with an ASCII-emphasised word like this:
This makes so much sense! IMO the whitespace should be mandatory. Just curious, why wasn't `-` (hyphen) for bullet lists? ~fkfd
On Sun, May 31, 2020 at 01:55:26PM +1000, Thomas Karpiniec wrote: > Hi, > > While testing a GUI text/gemini renderer I noticed that if a line > starts with an ASCII-emphasised word like this: > > *Great* times are ahead > > Then a spec-compliant browser will turn that into a bullet: > > ? Great* times are ahead Yeah, I have noticed this too. It's minor, like you say, but I will admit it grates on me. I guess there are a bunch of things we could do about this. Solutions that involve changing the spec:
All makes sense to me! On Sun, May 31, 2020 at 10:09:46AM +0000, solderpunk wrote: > Solutions that don't involve changing the spec: > > * Authors could take care to introduce a leading space before text lines > which begin with emphasised words. > * Geminispace could adopt a convention of emphasising words like _this_ > instead of like *this* (or any other way not involving *s). I didn't think of such a simple workaround (the leading space). You're right, I expect it would become common knowledge that you have to look out for that while composing gemini text. Not worth making breaking changes for in any case. Cheers, Tom
On May 31, 2020 6:09:46 PM GMT+08:00, solderpunk <solderpunk at SDF.ORG> wrote: >On Sun, May 31, 2020 at 01:55:26PM +1000, Thomas Karpiniec wrote: >I'm a little reluctant to change this now as it will make (a little, >yes) work for many people, and chances are good at least half of the >people who made things excitedly on the first weekend after the HN >article have now gotten bored and left and won't change anything, so >we'll end up with long-term visible inconsistencies (which will give >some people the idea that both * and - are valid, ala Markdown, >perpetuating the situation). It would be a shame to do that for the >sake of something so minor. But hey look, the magic of free software suggests there's nothing that's set in stone. All can be patched. Personally I don't believe a jury-rigged weekend project would be used by more than a dozen people - who will hop to better clients eventually. The more we postpone refining the spec, the harder it will become to actually do it. That said, my stance is that we deprecate * and adopt - for bullet lists. ~fkfd
Hey!
> It would be a shame to do that for the
> sake of something so minor. Then again, maybe I should be less afraid
> of breaking things. All the content that exists today will hopefully be
> a small percentage of all the content what will be created...
Don't be afraid of breaking things for a better spec. I would still
consider Gemini experimental, so that's okay.
My approach would be:
* Mark `*` at the begin of the line deprecated as a list identifier
and to be removed in the next iteration of the spec
* Declare " *" as the list identifier
It makes lists indented and stand out, also remove the ambiguity.
Right now, my parser would break on that, but it's an easy fix in pretty
much all programming languages as well as the plain text documents:
[]$ sed 's/^*/ */'
Regards
- xq
I suggest we simply add a space after the asterisk if it?s a list item. I also see no harm in supporting both asterisk and the minus for list items.
On Sun, May 31, 2020 at 01:46:28PM +0200, Alex Schroeder wrote: > I also see no harm in supporting both asterisk and the minus for list items. I guess I see it as "indirect harm". It adds words to the spec and bytes to clients without any real advantage. What's the point in having more than one easy and familiar and unambiguous way to designate something? Sure, it's not going to add *many* words or bytes, but taking ideas like simplicity and minimalism seriously means pushing back against small enroachments. Gemini is explicitly "heavier than Gopher", but that shouldn't mean we happily take on weight without giving it thought. Cheers, Solderpunk
gemini-request at lists.orbitalfox.eu wrote:
> Message: 6
> Date: Sun, 31 May 2020 20:21:17 +1000
> From: Thomas Karpiniec<tkarpiniec at icloud.com>
> To: Gemini application layer protocol<gemini at lists.orbitalfox.eu>
> Subject: Re: Ambiguity in unordered list item definition
> Message-ID:<20200531102117.GA48485 at allanon.local>
> Content-Type: text/plain; charset=us-ascii
>
> All makes sense to me!
>
> On Sun, May 31, 2020 at 10:09:46AM +0000, solderpunk wrote:
>> Solutions that don't involve changing the spec:
>>
>> * Authors could take care to introduce a leading space before text lines
>> which begin with emphasised words.
>> * Geminispace could adopt a convention of emphasising words like_this_
>> instead of like*this* (or any other way not involving *s).
> I didn't think of such a simple workaround (the leading space). You're
> right, I expect it would become common knowledge that you have to look
> out for that while composing gemini text.
>
> Not worth making breaking changes for in any case.
>
> Cheers,
>
> Tom
Doesn't it make more sense to do the *reverse* (see what I did there?),
by requiring bullet lines to have a space *after* the *?
Because the normal standard for "ascii bold" has no spaces between the
leading * and the bolded word, as you can see in my mail (if it hasn't
been already rendered in bold by your mail program.
It would make sense for a bullet to be a space away from the text it is
bulleting, so that ^[[:star:]][[:space:]] would be a bulleted list,
while [[:star:]]Thing I want to emphasize[[:star:]]
So only really sloppy ascii-type text would break this, and so then
maybe it should. And most bulleters would be doing this already (I see
that that's what I did for my bullets, I'm used to mediawiki, and
markdown is the same
https://wordpress.com/support/markdown-quick-reference/
Bullet Lists
* Item * Item
On Sun, May 31, 2020 at 11:51:09PM -0700, Pete D. wrote: > Doesn't it make more sense to do the *reverse* (see what I did there?), by > requiring bullet lines to have a space *after* the *? > Because the normal standard for "ascii bold" has no spaces between the > leading * and the bolded word, as you can see in my mail (if it hasn't been > already rendered in bold by your mail program. Ah, I must say, I like "* " better than " *"! If we did it that way I suspect much fewer people would need to make changes to their content, which is a good thing. Cheers, Solderpunk
On Mon, Jun 01, 2020 at 08:06:01AM +0000, solderpunk wrote: > Ah, I must say, I like "* " better than " *"! If we did it that way I > suspect much fewer people would need to make changes to their content, > which is a good thing. Oops, that's what I meant in the first place! Unfortunately I too was ambiguous. I didn't realise in the subsequent discussion that I was misunderstood. So to restate it clearly, what I was trying to propose was changing bullets from a line starting with "*" to a line starting with "* ". Cheers, Tom
On Mon, Jun 01, 2020 at 06:12:47PM +1000, Thomas Karpiniec wrote: > Oops, that's what I meant in the first place! Unfortunately I too was > ambiguous. I didn't realise in the subsequent discussion that I was > misunderstood. > > So to restate it clearly, what I was trying to propose was changing > bullets from a line starting with "*" to a line starting with "* ". Oh, great! Does anybody *not* like this idea? Cheers, Solderpunk
Interestingly, I could find no existing link lines in Geminispace that would go out-of-spec with this change. There *are* a number of what appear to be intended boldings words at the beginning of lines that would actually go in-spec with this change, since right now they're technically list items, which seems unintentional to me. You can find an example on this page: gemini://carcosa.net/journal/20190925-status.gmi Aside from several more serendipitous boldings like that, the only other thing of note I found, which would require an actual change by Mozz, is this page of tests: gemini://mozz.us/files/text_formatting_test_20200303.gmi So, I'm in favor of this change! Yours faithfully, Natalie
---
Previous Thread: [ANN] Diohsc: incredibly ordinary haskell client