[HN Gopher] Show HN: Podlite - a lightweight markup language for...
___________________________________________________________________
Show HN: Podlite - a lightweight markup language for organizing
knowledge
Unbound by any specific domain, programming language, or concept,
Podlite stands out as a universal markup language In addition, the
support for Markdown markup as a standard block adds convenience
and allows for the use of familiar syntax for text formatting It's
perfect for documentation, educational materials, blogging, and
much more for organizing knowledge. One of the key features of
Podlite is its extensibility. This allows for defining unique and
domain-specific blocks and expanding the language's functionality
according to the requirements of your project. The Podlite
specification is published under the Artistic license 2.0. Site:
https://podlite.org Thank You!
Author : zagap
Score : 104 points
Date : 2024-04-24 08:35 UTC (14 hours ago)
(HTM) web link (podlite.org)
(TXT) w3m dump (podlite.org)
| WA wrote:
| What's the main advantage over AsciiDoc?
|
| Although it's already on your roadmap, but it definitely needs
| more complex examples. Fiddled around a bit with links to same-
| doc references. Got it to work, but took a while.
| asystole wrote:
| I'm still upset that Markdown ended up getting all the
| mindshare. AsciiDoc is so much nicer.
| Ringz wrote:
| I'm still upset that Markdown ended up getting all the
| mindshare and doesn't evolve. All the fragmentation through
| different markdown flavors doesn't help.
| fwip wrote:
| Evolution in the biological world usually looks a lot like
| fragmentation, at least in the short term.
| Ringz wrote:
| You are right. It would be interesting to compare
| evolution from a computer scientific and biological point
| of view. To find out if they are similar...
|
| I believe that natural evolution makes it easier to let
| the bad branches die out.
| bandyaboot wrote:
| We need a specification for the forced extinction of
| markup languages that fail to gain traction.
| threatofrain wrote:
| The original core markdown being privately owned and frozen
| doomed it to having a politically funny future.
| aspyct wrote:
| I'm happy that something at all got all the mindshare.
| Otherwise we'd still each be using something different.
|
| Markdown is perfectly usable.
| everforward wrote:
| AsciiDoc is much nicer, but has the unfortunate flaw of
| having basically one implementation and it's in Ruby (the JS
| one is just transpiled, the Java one runs on JRuby, not sure
| about Go and Haskell).
|
| They don't even have a Python library, which basically
| guarantees that AsciiDoc won't be taught in colleges.
|
| I like AsciiDoc, but not nearly enough to mess around with
| installing Ruby and Gems and then having to do the same for
| anyone else at work that needs to build the docs for whatever
| reason.
|
| Ruby is basically a non-starter for me in general. Dependency
| management and interpreter versioning is a pain in the ass
| for interpreted languages, so I'd rather have as few as
| possible on my system. I've already got Perl and Python
| installed by default, I'd rather not add a third.
| dash2 wrote:
| Damian Conway... a name to conjure with.
|
| What are the advantages of the Podlite design?
| zagap wrote:
| It's extensible and not tied to any specific programming
| language, allowing for constructs like this ( mix chunks of
| markdown and build TOC ):
|
| ---
|
| =toc head1, head2, head3
|
| =begin markdown # header from markdown ##
| second level =end markdown =head1 This
| is header from Podlite
|
| ---
|
| https://pod6.in/#p=%3Dtoc+head1%2C+head2%2C+head3%0A%0A%3Dbe...
| dash2 wrote:
| That's an interesting feature. What is its advantage, i.e.
| how and when is it useful?
| zagap wrote:
| I agree with you on this. It's a cool feature.
|
| What I find most interesting is that there's no need to
| choose between Podlite and Markdown; you can use both and
| switch between them as needed.
|
| I think Podlite could be really useful in document
| management systems and electronic publishing. But... let's
| see what practical uses Podlite will find.
|
| thank you
| kkfx wrote:
| Please, anytime you try to imitate parts of org-mode, consider
| org-mode, markup and abilities.
| exe34 wrote:
| I had all kinds of plans for my knowledge management for over a
| decade. Then I started using org-roam and now the activation
| energy to consider anything else is so high that I'm stuck in a
| local minimum.
| okibry wrote:
| What do you mean ?
| exe34 wrote:
| I had the idea that handwriting, an infinite canvas and
| cross linking between ideas were going to be a big part of
| my external knowledge base. So I learnt a lot of technical
| skills that would allow me to put something like that
| together. Then right around the time I got an eink tablet
| and thought I'd start making something, I started using
| org-roam and it seems more than enough to contain all the
| information I tend to want to record. If I really want to
| handwrite or sketch something, I'll just do it on paper and
| snap a picture, crop it and paste it in Emacs (I have a
| script that copies it into a subdirectory) and the whole
| thing lives in a git repo.
| kkfx wrote:
| You might like artist mode (while personally I use it
| only to "fill" pdf non-fillable form with TiKz) :-)
| exe34 wrote:
| Nice, will have a look
| lyu07282 wrote:
| also if you find yourself inventing a new complex syntax for
| yet another markup language... consider doing something else
| instead
| simonw wrote:
| It took me a few clicks but here's an example Podlite document
| for anyone who likes to jump straight into examples:
| https://github.com/podlite/podlite-specs/blob/main/Specifica...
|
| This introductory blog post from February is useful too:
| https://podlite.org/2024/2/21/1/introducing-podlite-a-lightw...
| chj wrote:
| Isn't it the way perl scripts write their documentation? I don't
| know what makes it good for personal knowledge systems from
| reading the introduction
| apgwoz wrote:
| Perl's POD, yes. But you're right! The spec authors are Perl
| folx, and this is clearly derivative. What's kind of
| interesting is that POD stands for "Plain Old Documentation"
| and then there's a "lite" version of it... so "lite-r Plain Old
| Documentation" --- I don't see a clear summary of the
| differences, though.
| alexisread wrote:
| Looks nice, I have a couple of questions:
|
| Does this use a single pass for the parser? Is there an EBNF
| spec? What sort of diagrams does it support?
|
| Thanks
| zagap wrote:
| This is a specification, it does not declare how
| implementations work.
|
| At the moment only typescript implementation exists and here is
| PEG grammars from it:
| https://github.com/podlite/podlite/blob/main/packages/podlit...
|
| At the moment it supports Mermaid diagrams:
|
| https://pod6.in/#p=%3Dbegin+Mermaid++%3Acaption%28%27Caption...
| zagap wrote:
| The existing typescript implemetation builds a complete AST
| (Abstract Syntax Tree), over which middlewares are run in
| several passes. Yes, there are multiple passes over the tree.
| This is necessary, among other things, to build a table of
| contents (TOC). thank you
| alexisread wrote:
| Might not work for my use case then. djot is single-pass so
| dovetails better with forth-style languages. I do like the
| blocks and mistake marking though :)
| austinjp wrote:
| Interesting. Have you been using djot for anything
| substantial, like technical/academic publishing, large
| projects like entire books, or similar? How does it fare
| and what is your toolchain? Thanks in advance!
| k8si wrote:
| Please put concrete examples right at the top of the page you're
| publicizing!
| zagap wrote:
| The specification for the Podlite markup language is written
| using Podlite markup itself.
|
| https://github.com/podlite/podlite-specs/blob/main/Specifica...
|
| Also online playground is available here: https://pod6.in/
|
| Thanks for your interest in Podlite! with best, Alex
| jon_richards wrote:
| That playground is cool. I wonder if there are any 2-way
| playgrounds where the right side is also editable using a
| Word / Google Docs style interface (and the changes are
| reflected in the code-style interface on the left). I've
| always wanted something like that for teaching non-technical
| people the basics of Markdown. Bonus points if it's
| collaborative.
| bachmeier wrote:
| While I think this is worth exploring, at a certain point you end
| up doing so much that you could just write raw HTML, and then
| you'd have the advantage of being able to display it directly in
| the browser and using Javascript's powerful querying features.
| ThinkBeat wrote:
| Reading through the source for the specifications was
| interesitng. There is a lot of good stuff here, but there is so
| much to learn but I dont see enough benefits to push me to learn
| it when I already have Latex,Markdown and straight HTML in my
| toolbox.
|
| I would like to be proven wrong though.
| TrueDuality wrote:
| Ouch. IMHO the reason markdown became so popular is because how
| simple it is, how well the syntax generally stays out of the way
| of the content, and its almost entire lack of mixing formatting
| with document structure.
|
| This is VERY heavy, and VERY invasive. The entire lack of opinion
| in "use whatever markup you like as long as its wrapped in our
| markup" seems like an extra awful complication. I'd be curious to
| hear about what concrete problems the authors of this spec were
| trying to solve and why they went so far.
| fabianholzer wrote:
| Interesting approach.
|
| I would love to have a notation to get a various ways of
| representing of intellectual tasks into a single document. A real
| killer feature in my eyes would be if a kind of umbrella markup
| language would support a convenient two-way binding for creating
| and manipulating notations, so for example that diagrams could
| not only be rendered in a desktop app, but also be manipulated
| with the markup being automatically being updated. I guess the
| problem is that light-weight implies too little structure to make
| such a thing easy to implement...
| pixelcodev wrote:
| Hey, I'm Lee! I like this, nice work! :)
___________________________________________________________________
(page generated 2024-04-24 23:01 UTC)