Zettelkasten-Team / Zettelkasten

Zettelkasten-Developer-Builds
http://zettelkasten.danielluedecke.de
GNU General Public License v3.0
733 stars 93 forks source link

Only support markdown in future releases? #224

Closed Elmari closed 2 months ago

Elmari commented 4 years ago

Continuation of the idea of #195: We should perhaps consider supporting only markdown in the future and converting old ubb-sheets to markdown, since markdown formatting seems simpler and more standardized than BB code, at least to me. What are your thoughts on that @strengejacke @RalfBarkow ?

strengejacke commented 4 years ago

Yes, that was the "long term" goal I had in mind. At startup, the Zettelkasten checks the current data base version (https://github.com/sjPlot/Zettelkasten/blob/master/src/main/java/de/danielluedecke/zettelkasten/tasks/UpdateFileTask.java) and then updates the data base, if required.

We should somehow softly deprecate this, e.g. when user still enters ubb-tags by hand, that these will be converted to markdown when the entry is saved. Internally, we should definitely convert all UBB to markdown when this feature is implemented (to update the database).

RalfBarkow commented 4 years ago

covertUbbToHtml

RalfBarkow commented 4 years ago

Is there an easy way to autoconvert UBB syntax to Markdown syntax?

Elmari commented 4 years ago

I think the easiest solution would be to convert the ubb code to html (as already implemented) and then convert the html back to markdown (see also flexmark section on that)

RalfBarkow commented 4 years ago

[…] e.g. when user still enters ubb-tags by hand, that these will be converted to markdown when the entry is saved. Internally, we should definitely convert all UBB to markdown when this feature is implemented (to update the database).

Could we use a common rich text editor and strip down the resulting (X)HTML to the set we want to allow in the Zettelkasten application?

Cf. Issue https://github.com/sjPlot/Zettelkasten/issues/131

Could we use something like Quill ?

Elmari commented 4 years ago

So far it was not planned by Daniel to include a richtext editor (see here). Richtext inserts could also be solved by inserting the copied text as markdown. If we should implement a WYSIWYG editor I would rather use JavaFX instead of JS. We would have to use a JavaFX component to implement JS anyway, which would be fiddly.

RalfBarkow commented 4 years ago

See gotchamana / CrazyNote for using 3rd party JavaScript library Quill via WebView with Java/Kotlin.

RalfBarkow commented 4 years ago

Let me just note, that I plan to expand on this question "Only support markdown in future releases?" at a later point in time. For now, I'd like to mention that I feel the need for a more general solution as to agree upon the one and only format. Given the resent hipe around Roam Research and the revival of Org mode and good old Emacs, one might as well argue for Org mode plain text files as another candidate format.

alltagsverstand commented 4 years ago

Important question with a view to this topic: are you guys planning only to completely switch to markdown syntax as default (and maybe only) format? Or does it include the goal to rework the basic structure of the Zettelkasten architecture such that notes will be stored as single text files?

I have no idea of how much of a redesign this would need, so apologize for appearing demanding... :wink: But in my view, this latter solution would make the zkn3 much more future proof as it would easily be possible to migrate from (and to) other apps, as well as to establish an internal linking structure that can be identified by every modern markdown editor or outliner! And it would open up the possibility to share my zettelkasten data with other apps - and maybe even with other people (though at this point this possibility doesn't strike me personally....)

RalfBarkow commented 3 years ago

@alltagsverstand Perhaps it is better not to think of that one format, but to use something like the concatext.

This gives us an unbroken sequence of text without markup or links-- which we call the concatext.

github-actions[bot] commented 2 months ago

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] commented 2 months ago

This issue was closed because it has been inactive for 14 days since being marked as stale.