Closed bouncepaw closed 2 years ago
I take back my proposal for the temporary syntax, gotta migrate to the final one immediately. Here's how I see it.
This library exposes a function MigrateRocketLinks
that takes source text of a document with the old syntax and migrates to the new one.
I think it can be done without using the rest of the lib, a self-contained procedure working on strings.
The basic algorithm:
\s*=>
, write the line as is, goto 1>
, look at the rest of the line|
after it and write the stringThis algorithm will handle almost all cases. It won't handle weird cases like:
* => link
Whatever.
Why have a task-specific parser when there is an already working Mycomarkup parser? Well, it handles deserialization (myco to data), but not serialization (data to myco) yet.
When this algorithm shall be used? In Mycorrhiza, on start, a special file cache/mycomarkup-rocket-migration-marker
shall be looked for. If it does not exists, this procedure will be called on every textual hypha, all changes will be saved as one commit by wikimind
and the file will be created. Then the program will init as usual. In a few versions we can delete this algorithm and forget it like a nightmare.
Actually, the migration took part some time ago, no need to keep this issue open anymore
See also this heavily-related Mycorrhiza issue.
Current rocket links syntax is bad because of how different it is from all other Mycomarkup blocks. You can't have a hypha link with spaces, you have to replace the spaces with underscores. Also, the link text comes after a first space, not after
|
, like in inline links.I propose this new syntax:
It is not compatible with the current syntax. Moreover, we can't have them both at the same time (like with headings) because the
=>
is not going anywhere.To somehow address it I propose this temporary syntax:
Basically, if there is
|
in the rocket, the new logic is used. Otherwise, the old one is used. This is generally backward-compatible (haven't seen|
being used in display text!) and lets people use the new syntax already.Then a forced migration will happen. I think it should happen at the same time as the forced migration to the new heading syntax.