3

Note: This question is very specific to the research of computer science languages. The Comp Sci SE community thought it best to post here instead of there.

I love taking notes in my native programming environment, but I'm tired of plain white text with loose structure. I'm looking for a language or data-interchange format, not markdown or clever emacs tricks.

I'm curious about a new solution to note-taking that involves a light aspect of programming. This could be a DSL, but I'm really not looking for anything like git markdown. What I'm imagining is something like below. Syntax highlighting could help visually separate aspects of notes and I can imagine doing some fun linking and structuring in a compilation step.

Creating this language would be a fun research topic for me, but I want to see if its been done before. This looks a little python'ish, but I'm imagining something like this (or could be compiled to this):

topic
    an elementary intro to fruit

concept
    fruit exists in many different colors, shapes, and sizes

list:[colors, shape, size]
    orange
        colors: orange, green, yellow
        size: small
        shape: round
    banana
        colors: yellow, green
        shape: long

terms
    fructose: something to do with sugar
    hue: a form of color

related
    trees > tree-fruits.txt
    humans > ../human-notes/
    farms > ../../farms
  • Could you explain what's wrong with Markdown? – svick Dec 2 '14 at 18:54
  • @svick Markdown is fine, I just don't want markdown. Markdown is used like HTML: for layout and emphasis. I want to do more after I structure my text in a syntax (ie elicit meaning). – y3sh Dec 2 '14 at 22:53
  • What kind of meaning? What I see in your sample are headings, links, unordered lists and definition lists. Out of these, Markdown supports all except definition lists, but even those seem to be supported by some dialects. – svick Dec 2 '14 at 23:07
  • You should check out Org if you use emacs. Even if you don't use emacs, Org makes it worth learning. – Sean Allred Jan 17 '15 at 16:03
  • @svick Not sure if this is a problem with Markdown per se but its implementation in Sublime Text 3 for Windows leaves something to be desired. – alex Feb 23 '18 at 14:00
2

If you're looking for human-writable format for specifying structured data (as opposed to just human-readable formats like JSON and XML), have a look at YAML. It's not specific to note-taking, but I think it could work here.

Using it, your example could be written like:

topic:
    an elementary intro to fruit

concept:
    fruit exists in many different colors, shapes, and sizes

list:
    orange:
        colors: [ orange, green, yellow ]
        size: small
        shape: round
    banana:
        colors: [ yellow, green ]
        shape: long

terms:
    fructose: something to do with sugar
    hue: a form of color

related:
    trees: tree-fruits.txt
    humans:  ../human-notes/
    farms: ../../farms
  • Great -- I never considered yaml, but i think it might fight the context – y3sh Dec 3 '14 at 14:32
2

I think that it would be worth your time to take a look at the Sphinx python document generation tool. It was originally created for the new Python documentation and relies heavily on Restructured Text.

Goals of Restructured Text:

From the web site.

  1. Readable. The marked-up text must be easy to read without any prior knowledge of the markup language. It should be as easily read in raw form as in processed form.
  2. Unobtrusive. The markup that is used should be as simple and unobtrusive as possible. The simplicity of markup constructs should be roughly proportional to their frequency of use. The most common constructs, with natural and obvious markup, should be the simplest and most unobtrusive. Less common constructs, for which there is no natural or obvious markup, should be distinctive.
  3. Unambiguous. The rules for markup must not be open for interpretation. For any given input, there should be one and only one possible output (including error output).
  4. Unsurprising. Markup constructs should not cause unexpected output upon processing. As a fallback, there must be a way to prevent unwanted markup processing when a markup construct is used in a non-markup context (for example, when documenting the markup syntax itself).
  5. Intuitive. Markup should be as obvious and easily remembered as possible, for the author as well as for the reader. Constructs should take their cues from such naturally occurring sources as plaintext email messages, newsgroup postings, and text documentation such as README.txt files.
  6. Easy. It should be easy to mark up text using any ordinary text editor.
  7. Scalable. The markup should be applicable regardless of the length of the text.
  8. Powerful. The markup should provide enough constructs to produce a reasonably rich structured document.
  9. Language-neutral. The markup should apply to multiple natural (as well as artificial) languages, not only English.
  10. Extensible. The markup should provide a simple syntax and interface for adding more complex general markup, and custom markup.
  11. Output-format-neutral. The markup will be appropriate for processing to multiple output formats, and will not be biased toward any particular format.
  • 1
    As much as this document generation tool seems nice, the goal I'm after is not to generate structured documentation, but to provide simple language constructs while typing notes about anything (ie non-programming related). – y3sh Dec 2 '14 at 22:48
  • That is the restructured text part - Sphinx is used to pull it all together. – Steve Barnes Dec 3 '14 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.