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.
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
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.
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.
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).
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.
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
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
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.
The current development history since starting with #python in October 2018 (with about half of the time inactive due to work):
- sketched basic datastructures
- learned more advanced python stuff & programming principles, which held off development for quite some time
- kept getting lost in the details of PEG parsers & parser theory
- decided to write a custom parser because the #markup language is too context sensitive
- already used the language for notetaking throughout
Epistropy is an approach at reusable #notetaking, which builds up a personal #wiki, that can be used for more efficient #knowledge retrieval | #visualization | #creativeThinking | #communication | #learning
with a simple #markup language at it's base ( inspired by #markdown & #latex )
Alright, I'd say that my #rustlang confidence has surpassed the minimal level to start the project (see previous toots). Technically I've learned this in a little more than a week, if you only count spare time. So one could definitely learn Rust properly in two weeks, assuming the right motivation and sufficiently quick understanding.
I'm considering tooting about the development process with a casual diary under the tag #epistropydev to keep me motivated. More info soon.
Linux Geeks doing what Linux Geeks do..