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/5993b2de/attachment.htm>