#epistropydev 11

So the motivation purposes of this hashtag based blog haven't worked out that well in the last two months. The #homeoffice situation has a great deal to with it, as my current working environment isn't ideal due to various reasons. Hoping to move soon and get some proper equipment (eyeing for a #ryzen notebook).

Until then I'll prioritize working on songs rather than code to keep my sanity. But it doesn't mean the development will halt completely.

#epistropydev 10

Deviating the #epistropy #markup syntax more and more from the #markdown inspiration.

Originally I intended to keep it as similar as possible so users can port their markdown notes easily to the format exactly as they are. This feature will be a import function instead.

Some of the problems, that are even present in the #commonmark specification are e.g. handling of whitespace indent with mixing of tabs and whitespace, which could lead to incoherent syntax highlighting

#epistropydev 9

Not finding that much time to work on the code of the project but the language keeps evolving nicely. This includes more breaking changes, so I might wait with the finalization of the first definite concept for at least another month. This means v0.1 will most likely not be ready before april.

Hopefully I manage implement a parser for the base elements this month though.

#epistropydev 8

Stacking #rustlang enums for the parser AST structure

can a nested enum with 3 levels of nesting can be considered a design flaw or is this more common than my imagination allows?

What I'm thinking of is splitting the parser tokens into a compiled core branch and a user extendable branch. The core branch has variants for container nodes and leaf nodes. Each of those variants has variants for every core syntax element. The user extendable variant is a placeholder for now.

#epistropydev 7

looking into the #rustlang crate #nom for #parser implementation. It is a parser combinator library, which allows for building up each parsing step with a custom function instead of defining the grammar of a context free language as in the case of parser generators (if I understand correctly).

#epistropydev 6

I'm actually glad that the development process of #epistropy didn't advance that over the course of last year. This left a lot of time to evolve the design naturally.

Currently I'm finding ways to make the combination of base syntax elements have an #intuitive meaning to the point where they could even be seen as grammar elements of a natural language.

#epistropydev 5

Created the #rustlang crate and started working on #unitTests for the #regex | #regularExpression generation

The parser works in a two step process, by first finding the markers for block elements and afterwards processing the inline. This is almost the same as in the #markdown | #commonmark implementation, but I had some alterations, which allowed for more complex syntax.

The regular expressions are generated by collecting all syntax elements, making one regex for each step

#epistropydev 4

Current #roadmap until summer with a snippet written in the #epistropy #markup:

++[plan] Roadmap
1** parser & api --> [v:0.1]
2** visualization --> [v:0.2]
3** task planning || semantic calender --> [v:0.3]
4** knowledge retrieval --> [v:0.4]

first public release of the code either with version 0.2 or more likely 0.4, earlier versions might be used for #atom plugins (e.g. syntax highlighting).

Regarding the syntax: every symbol has a meaning, example is quite advanced

#epistropydev 3
The current design aims at establishing the #markup in a way, where you could create the input for the app in any basic editor (although indentation support is recommended).

The same language will be used in the gui or web app for faster input than by #WYSIWYG. The gui is more for reorganizing the notes, or thinking with them interactively.

I will release the #syntax once the repository or crate becomes public. Right now, its design changes every couple of weeks.