Enable markdown + view hotkeys

[deusnovus]

Hi again, it's been great using Meld Encrypt since closing down #48 but it would be also really practical to include the default markdown hotkeys, like Command + B for bold, Command + I for italics etc.

Also, until we figure out a way to have Live Preview enabled in encrypted notes, it would be nice to be able to switch between Reading and Source via a hotkey, since global Obsidian hotkeys don't interact with this plugin.

[julian-poidevin]

Also interested by such a feature.

[sbeanss]

I'm interested too.

Thanks.

[meld-cp]

The .encrypted note editor is separate and independent from Obsidian's markdown editor, which makes it difficult to have a like-for-like editing experience between .encrypted and .md files. Until there's a way to hook into the save-to/read-from disk api without corrupting notes, editing .encrypted notes will be very limited.

Having said that, v2.3.0 adds the ability to quickly decrypt or encrypt an existing note (bind it to a hotkey). So, the workflow could be to temporally decrypt the note to disk, edit it with all the nice Obsidian features, then re-encrypt it when done.

[Gewerd-Strauss]

The issue with encrypt-in-place is that it compromises notes as soon as you have file backup set up. As an example, both the Obsidian-Git plugin, as well as the official sync are capable of syncing up these files while unencrypted.

For git this is at least salvageable because you could resort to naming all your notes à la XX - crypt and then add * - crypt.md to your gitignore.

However, obsidian's own sync does not allow for this. You can still put the encrypted note into an ignored folder, but then you loose the safety of backing them up altogether. In the end, obsidian's sync forces you to choose between redundancy and safety - and obviously those two things are fairly interconnected.

A potential solution:
I would suggest the following:

1. The plugin creates a specific "reading" vault folder, say root\meld-encrypt, into which notes get decrypted when decrypting a note.
2. You could then blacklist this folder from your sync/git/... to never commit the unencrypted information.
3. The file.encrypted-file must then be ensured to never reside within this aforementioned "reading"-folder, so as to never risk encrypted data not being committed due to the file being in an ignored location. _Let the user put it anywhere, but if it is in this folder just dump it back to the vault root. The user can handle putting it back to where it belonged.
4. When the user closes the decrypted file, or closes obsidian, or even after x minutes of inactivity (or whatever), delete all files in the "reading"-folder, so the data does not remain on-disk.

This allows the user to back up their encrypted data within a non-ignored folder via whatever solution they choose to use, while still ensuring data-integrity as achievable within obsidian. Obviously data could still be snatched as soon as the user decrypts the file by malicious software on the computer, but that problem obviously already exists for the current solution (which converts file.encrypted to file.md in-place), and I don't see how that could be fixed without implementing markdown-rendering for file.encrypted-views (which you mentioned is difficult due to how the special file-type fails to interface with obsidian.)