Currently, the markdown preview is always recomputed, even without changes to the source markdown file. There would be several ways of improving this very poor design:
[ ] store a hash of the source code files if a preview has been generated. When reasking to preview, check the hash, and skip to display if nothing changed
[ ] make an incremental modification. When adding a new note to an existing notebook, it could be beneficial to compute the markdown preview only for the tiny bit we are interested in (plus, this could be used in previewing the note before posting it).
[ ] thread the preview away. While launching the application, and finding notebooks in the home folder, always assume that the user will want to preview it, and start in a separate thread (if available) the previewing. This way, the UI is not blocked, and the response will be faster.
We have to think of a way to store these hashes of already previewed files:
in the same way we store the preferences of the code? (so registry in Windows)
First: I don't have a problem with the current speed. But it's allways a good thing to improve it.
storing hashes sounds good. I would store them in the tempfolders as they belong to the tempfiles and html-files. The only thing we have to think of are the config-entries that can change and need a recompution even when the hash adds up
being able to compute the single notes sounds good in general, as you said, for a preview. Maybe we can generate a template-file where we only have to put the notes in. This could lead to different templates where the user can choose from.
threading is a nice thing in general, but the last thing I read was that it's still a mess in python. If it's possible without too much hassle, sure..
Currently, the markdown preview is always recomputed, even without changes to the source markdown file. There would be several ways of improving this very poor design:
We have to think of a way to store these hashes of already previewed files:
.noteorganiser
?