@R ProTip: Start with #Barathrum songs like Last Day In Heaven :p
Subscribing to #Brilliant or something like that could actually be quite beneficial if learning programming conflicts with the battle for procrastination, since it's basically gamification of learning (I have something similar in mind, if I ever manage to release #epistropy).
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
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.
I actually have an idea, that would make #epistropy command line usable to overcome it's current shortcoming of note retrieval even without a gui.
question: is it possible to call an editor (e.g. #vim) in a way where the saved output is automatically routed to the next next command from a calling wrapper? effectively I want something like a temp file, that is automatically processed when saving without a custom filepath. is piping sufficient for this or would i need to use some api?
The basic syntax will be hardcoded with an option to turn certain elements on or off.
Because #epistropy is supposed to have a very general and mostly subject independent use case, I plan to make the syntax extendable by either scripting, recompiling or even an in-app editor. Though this will probably be moved to after the 1.0 release, in order to first test the design without the added complexity. Besides, one can always fork the code.
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
The name #epistropy is a combination of #episteme (knowledge) and #entropy (a measure for information), which are the two main concepts behind it's conception at aiming to condense knowledge.
I've had the rough idea for this project ever since I got into philosophy some 15 years ago. During my time studying physics at university the ideas manifested more and more, mainly because of frustration with rehashing the same concepts over and over in every textbook. Actual designing only started 2018
Starting #epistropydev with this toot. Search the hashtag for updates on the development process of my app/framework/library #epistropy written in #rustlang with planned #python scripting support.
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 )
Halbeard
Halbeard