3 ms·

This is just the way i have the scripts setup since it makes more sense for me for paragraphs to be full nodes that contain their children content, but it is tr

by Crinus 8y ago

This is just the way i have the scripts setup since it makes more sense for me for paragraphs to be full nodes that contain their children content, but it is trivial to make empty P nodes act as paragraph separators.

enriquto 8y ago
It is not a trivial matter when you are writing the markup manually. If you require to open and close paragraphs it becomes very cumbersome for no real gain (just a tiny amount of convenience for the programmer of the parser). The ideal case is TeX, where paragraphs are separated by a blank line.
- Crinus 8y ago
  With trivial i meant that it is trivial to have a script that makes @P; a separator (or start marker) if you prefer to work that way. I made the system script-driven with a generic syntax exactly because i didn't want to hardcode any specific way of working with the nodes. As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code, which often needs some style of its own and sometimes that depends on context. To me seeing where a paragraph - or any other "long" element - begins and ends can be helpful and if anything, i consider the lack of syntax for this in my markup as a negative (but i couldn't come up with a clean and unambiguous syntax for adding an optional "closing" bit). I compensate for that using comments (which look like @# Blah until the end of line), but it is a workaround. And also FWIW i prefer to have the markup map to the underlying tree of nodes clearly than introduce "magic" that in some cases can make things harder even for writers. Keep in mind though that this is for long(ish) documents, like a large tutorial, guide, manual, etc not short comments like this one here. For anything that is around the size of a common blog post or shorter, something more adhoc like Markdown is probably better.
  - enriquto 8y ago
    > As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code just to nitpick: except for APL, white space is treated in a special way in all programming languages to separate tokens :) Using it to separate text (words and paragraphs) makes perfect sense in this context.
    - Crinus 8y ago
      Perhaps i used a wrong description, but i meant having special cases/multiple uses and specifically about text markup languages. If every other element of the document tree, like sections, links, emphasis, references, images, figures, etc is marked using explicit syntax then using whitespace for paragraphs is inconsistent and can often be misleading since this will also need to be context sensitive as you do not want paragraphs to be inserted in every node that can have children. But this is obviously a stylistic preference as to me that sounds too much trouble for no gain at all - which is basically your response above :-P. But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor that uses these nodes behind the scenes instead of having the user write the markup by hand. But that is obviously much harder to implement (and if the tool handles the nodes for you the syntax doesn't matter at all anyway). Still, to me that is the ideal:-).
      - enriquto 8y ago
        > But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor you will pry plain text editors from my cold, dead hands!

by Crinus 8y ago

enriquto 8y ago

It is not a trivial matter when you are writing the markup manually. If you require to open and close paragraphs it becomes very cumbersome for no real gain (just a tiny amount of convenience for the programmer of the parser). The ideal case is TeX, where paragraphs are separated by a blank line.

Crinus 8y ago
With trivial i meant that it is trivial to have a script that makes @P; a separator (or start marker) if you prefer to work that way. I made the system script-driven with a generic syntax exactly because i didn't want to hardcode any specific way of working with the nodes. As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code, which often needs some style of its own and sometimes that depends on context. To me seeing where a paragraph - or any other "long" element - begins and ends can be helpful and if anything, i consider the lack of syntax for this in my markup as a negative (but i couldn't come up with a clean and unambiguous syntax for adding an optional "closing" bit). I compensate for that using comments (which look like @# Blah until the end of line), but it is a workaround. And also FWIW i prefer to have the markup map to the underlying tree of nodes clearly than introduce "magic" that in some cases can make things harder even for writers. Keep in mind though that this is for long(ish) documents, like a large tutorial, guide, manual, etc not short comments like this one here. For anything that is around the size of a common blog post or shorter, something more adhoc like Markdown is probably better.
- enriquto 8y ago
  > As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code just to nitpick: except for APL, white space is treated in a special way in all programming languages to separate tokens :) Using it to separate text (words and paragraphs) makes perfect sense in this context.
  - Crinus 8y ago
    Perhaps i used a wrong description, but i meant having special cases/multiple uses and specifically about text markup languages. If every other element of the document tree, like sections, links, emphasis, references, images, figures, etc is marked using explicit syntax then using whitespace for paragraphs is inconsistent and can often be misleading since this will also need to be context sensitive as you do not want paragraphs to be inserted in every node that can have children. But this is obviously a stylistic preference as to me that sounds too much trouble for no gain at all - which is basically your response above :-P. But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor that uses these nodes behind the scenes instead of having the user write the markup by hand. But that is obviously much harder to implement (and if the tool handles the nodes for you the syntax doesn't matter at all anyway). Still, to me that is the ideal:-).
    - enriquto 8y ago
      > But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor you will pry plain text editors from my cold, dead hands!