💾 Archived View for station.martinrue.com › skyjake › c872ffe3fe2b477895a4eb7d1e555062 captured on 2024-02-05 at 10:46:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
gemini://skyjake.fi/gemlog/2021-10_mark-it-down.gmi
I'm curious if folks here have thoughts regarding Markdown in Geminispace?
Obviously we don't want sites doing browser-specific content, but on the other hand, the Gemini protocol is media-type-agnostic. It's the community that has to decide which content types are appropriate, and while Gemtext has many great qualities, it's also a bit of straightjacket.
2 years ago · 👍 gnuserland, martin
[1] gemini://skyjake.fi/gemlog/2021-10_mark-it-down.gmi
@remyabel
toggle the sidebar
If your window is wide enough that there's space on the left and right side of the URL bar, you can right-click there. But yeah, I should add a sidebar toggle button.
Emacs style bindings
I'll review the keys used on Linux and/or add a configurable keybinding here. I'm mostly on macOS personally, so I won't catch all the discrepancies...
multimonitor UI scaling
Lagrange asks SDL for monitor DPI values and trusts that they are valid. If your monitors actually have similar DPI, then you should use the DPI override environment variable (see Help). · 2 years ago
@remyabel Regarding usability issues, anything specific you want to highlight? Full keyboard access and multiple windows are near the top for me, at least. · 2 years ago
@remyabel I agree with pretty much everything you say there. This direction is not a priority at the moment, more of an experiment with what could be. I will likely make it a MIME hook and see how far it can go as a tool external to Lagrange.
Prioritization is always top of mind, but every now and then it's refreshing to look at new avenues. In this case, the text renderer and font system are now advanced enough to do proper rich text rendering, so of course I'm eager to kick the tires and see how well it works. · 2 years ago
not saying that you shouldn't do it, but it takes discipline to keep a standard alive. that's my opinion though, and I view the world as a pessimist. if you just assume things are going to stay as they are after touching the playing field, I think it's going to bite you. I may be wrong of course · 2 years ago
@reidrac it comes down to market share. skyjake has built something that is similar to chrome. titan is a different use case, that doesn't count much. but the way you consume content is by default gemtext. unless some bigger capsule deviates, effectively gating that content, unless you use Lagrange of course. how do you think chrome got its market share 😅 · 2 years ago
i did read gemini://idiomdrottning.org/re-mark-it-down
and i some how agree on the idea in its principle
but as in specs a server can serve any text/xyz like text/plain or default text/gemini or text/latex or text/markdown
to be honest the best would be text plain for screenreaders, sadly it does not support any links
if a gemini browser supports text/markdown it would be realy awesome or even if firefox and alike would support gemini and a like
the text/gemini is some thing in between and after this blog i think even headings lists blocks and emojis should get forbiden, just like text/plain with links and limited server side scripts, how ever md should not affect gmi · 2 years ago
you did it! you managed to create a discussion as big as nothing else in the past 3 months. except maybe some gemtext spec changes on the mailing list. well done! and regarding my stance on it? I side with idiomdrottning here. they nailed it in their blog · 2 years ago
i would like color codes in ascii pictures with background, may it could be done with the preformat alt text like
fancy picture
i also would like blinking characters (ansi) (sorry for that)
i also like markdown and see the problem with line warp
most md editors support html comments may this can help out to detect tables similat to codeblocks
<!--Tablestart-->
a|b
=|=
1|2
<!--Tableend-->
or such a thing
so if it comes to text nearly nothing has to get converted
some md editors support moving ll links to bottom or moving all footnotes to bottom, they have labels no need to link it.
Pictures could turn into link lines.
peace · 2 years ago
@mntn That's certainly doable. If I end up writing a table renderer, it could be used to display .csv files inline like that. But IMO it's still nicer if the document format itself can contain tables without needing a constellation of small files. · 2 years ago
Re: tables, why not text/csv? A client could always inline display of .csv like many do with images. · 2 years ago
@gnuserland Thanks! 😊
Your book project sounds great, it's nice to see GemPub getting more adoption. · 2 years ago
I'd like to elaborate my thoughts better.
Anyone has for Gemini different expectations, for me Gemini is about freedom and free-culture.
I am writing a book (without stress) it will be published first on Gemini and as Gempub. Anyone will be able to read this book.
Then I will publish this book in other formats as well when I can take advantage of better text sophistication. These versions won't be free. These will the refined version that you pay to read, but if you don't want pay you can always read the GemPub version.
Gemini allows me that much more than just HTML. I can write fast in any text editor (actually I am working mainly on Micro), I don't need to bother about bold, cursive, tables, etc...
I would never started this without Gemini, I tried with Write-Freely but I wouldn't so free as in Gemini, where I am also able to host my own Capsule! · 2 years ago
@skyjake by the way nice article, and reading MD documents on Lagrange will be a real pleasure! 👍 · 2 years ago
Could we translate a table in a line per line gemtext? 🤔
Anyway I don't miss tables at all... 😎
The simplicity is what fascinating me the most, if writing in gemtext should start to be complicated would be a shame.
Although MD is simple just because is related to HTML, the complexity is of course elsewhere.
To close anyone should with its client whatever he/she wants, however the Internet Browser Battle has an economic reason behind...
Does it Gemini have the same concerning? 🤷♂️ · 2 years ago
@lykso Bold and italic are nice, but tables would be the killer feature for me. I always find myself creating a table or two when writing documentation. The Lagrange Help page for example has a few. Prerendered ASCII tables are not adaptive to screen sizes...
The Help page would be a prime candidate for converting into Markdown, especially with it benefiting from named links for cross-referencing. But I kinda like the dogfooding aspect of having all internal pages be in Gemtext as well. 😊 · 2 years ago
I'm not opposed to a slimmed-down version of Markdown being supported. The only things I miss from Markdown myself are bolding and italicizing text for emphasis, FWIW. *This* and **this** still seem to get the point across, but would look a bit nicer rendered as they are in Markdown.
Whatever is chosen, it should still be readable when rendered as plaintext. Otherwise it runs the risk of forcing other clients to start supporting it as well, and this way lies client bloat (IMO). · 2 years ago
@khuxkm it's more the tendency to wite markdown for the rendered effect, rather than source readability. This was taken from one of my currently open tabs: https://raw.githubusercontent.com/balderdashy/sails/master/README.md · 2 years ago
"Most modern markdown no longer reads well without being parsed and rendered." Source? Most of the Markdown I write is perfectly readable without needing parsing (and the small amount that isn't is because I need raw HTML for some things). · 2 years ago
I'll go one further and suggest that I would be fine with ANSI codes being allowed in Gemini, I just think that they should be optional and should definitely be included or excluded explicitly via the spec. · 2 years ago
@marmaladefoo
content should not imply any particular front end technology
I'll point out that ANSI (color) codes are in use already, for example on AstroBotany. Font style codes are not fundamentally any different.
I agree that gemtext is all about separation of content from presentation. I'd be happy to see the text/gemini spec require that clients must filter out all ANSI codes. · 2 years ago
ANSI codes in gemtext
I'll likely make ANSI control code support optional and off by default for Gemtext.
The reasons why this option would even exist are:
1) Terminal-based clients support ANSI escapes for free unless they are specially filtered out. Wouldn't it be advantageous to have feature parity between terminal and GUI clients?
2) ANSI escapes are not forbidden in the text/gemini spec.
I totally see the problem with endorsing and/or encouraging the use of these, though. · 2 years ago
Generally I feel that we shouldn't be creating features that cause people to mangle their Gemtext for a specific client. If the client can use the plain text to present things in a novel way then I'm all for it, as long as it doesn't become an expectation for all clients. · 2 years ago
Re: ANSI support, if Lagrange uses that internally for presentation there's obviously no issue. I'd hate to see it start cropping up in Gemtext. Amfora supports it in preformatted text blocks and that already seems a bit strange to me, even though I just happily used the underlying code to build in source code highlighting. · 2 years ago
There's no problem publishing Markdown (or HTML, or PDFs) on your capsule, I just wouldn't expect most clients to support it natively. · 2 years ago
I was more concerned at your remarks that you will support ANSI codes in gemtext. I think this is a direction to be avoided - ANSI codes are really a very specific implementation technology (console control codes) inlined into text. Its like having <font> tags embedded in gemtext or other content and expecting that clients will render it. I think this is something to be discouraged and that content should not imply any particular front end technology. · 2 years ago
I think clients should support whatever media types they like. But there should be no expectation that anything is in fact supported apart from text/gemini and text/plain. So probably most clients will simply render markdown as plain text, or fire off an external helper app if it is configured. · 2 years ago
My straightjacket is my ability to write well and express myself clearly and coherently. Shortcomings of gemtext are way down my todo list.
Most modern markdown no longer reads well without being parsed and rendered. That's not true of gemtext. · 2 years ago
That's actually something I mentioned in my gemlog, I think gemtext being as 'restrictive' as it is feels like a blessing actually, give outside of a few headings and lists you don't have to bother formatting what you write to make it look nice, it's all down to the individual client. And while markdown is nice, it's all but necessary imo, you just have to read a book to see how versatile and expressive writing is in itself! · 2 years ago