Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default journal format #382

Open
173brian opened this issue May 6, 2024 · 3 comments
Open

Default journal format #382

173brian opened this issue May 6, 2024 · 3 comments

Comments

@173brian
Copy link

173brian commented May 6, 2024

Tui-journal stores files by default as txt files. It would be nice to have an option to configure this to enable other formats like markdown--especially given the goal for a RESTful API. Having the ability to control note format could make for more powerful fuzzy searching and thus more powerful note taking/finding abilities.

@AmmarAbouZor
Copy link
Owner

Thanks for the suggestion.
Actually the app saves the data by default as a local SQLite database and it has another json backend. The content of the journal is saved as plain text since there are no other possibility currently to render it as markdown.
Another point is that the markdown format is actually a plain text that is rendered in a special way by web-browser and other GUI software and having that data in that format will not provide any advantages in the fuzzy searching (Hopefully this suggestion isn't some kind of AI hallucinations).

@173brian
Copy link
Author

173brian commented May 7, 2024

Thanks for the reply, not an AI hallucination here, just a person trying to learn more :) I understand the point that the markdown format is essentially just a construct that sits on top of plain text and the clear assumption of tui-journal is that all text is plaintext. You are correct that using the markdown format wouldn't improve fuzzy finding capabilities, I suppose that was just a link I formed in my mind because I usually fuzzy find based off the headers of a document, but the find by content option is format agnostic.

The assumption that all text is plaintext may be true for tui-journal's rendering purposes, but it is not an assumption that holds once a document leaves the confines of the database. Thanks to the elegant mechanism for exporting it is possible to take journal entries beyond the database for other uses as well, but renaming every file being exported as the same .md filetype is a chore that should be automated.

There are useful reasons for this feature that extend far past searching: A default file format used with importing and exporting would allow for syncing notes across machines and applications something would greatly extend the functionality associated with tui-journal. A plugin for batch importing/exporting could transform a shared repo used with other note taking applications like Obsidian into a home for tui-journal as well, allowing it to shine as a blazingly fast tui note application.

I would be happy to help with development if you would consider supporting the feature and need community support.

@AmmarAbouZor
Copy link
Owner

Thanks for the suggestion... I want to make sure that you are know all the current export and import functionality because maybe you can achieve you goal with much simpler way...
Currently we support to kinds of export:

  • The first one is just to export one journal content and you can assign the extension as you want, since it's just the plain text of the journal content.
  • The other one, which is more elegant to sync your journal between many apps and databases is the export in multi-select mode, which let you select many journals at once and export all the journal information like its date, tags and priority. This export has json format which is the most common language to serialize data which make it very easy to write another script that parse the data very easily (since json is support in all languages) and then it can forms the data in any format. This approach is much powerful since it gives the users an easy way to read the data so they can form as they want with a very simple script. ( Like you can sort the journal to different directories based on their tags so you can order them easily in obsidian)

Do you think we need to improve on that mechanism or it's enough for your use-case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants