Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

[Daniel Clemente <n142857@gmail.com>]

The 3 small problems mentioned above are fixed, thanks.
Encryption is faster, and safer now. The part about communicating the
encryption status (communicating „this is actually encrypted on disk
even when you're seeing it unencrypted“) can be improved later if
others find the current behaviour confusing.

In the „Back to top level“ situation I mentioned, the encryption
prompt is canceled, and I'm happy that now I don't lose the section I
was encrypting.
Maybe you wanted to have org-crypt also catch this case (encryption
prompt canceled) to be able to show a „could not encrypt“ message. But
I think it's good enough as it is: it stays unencrypted, and on the
next attempt to save it, there will be another encryption password
prompt.

I found minor but unrelated issues, e.g. if you have an empty section like this:

************* abc2                                                    :crypt:
************* def

… if you rename the abc2 header, e.g. to abc, it will ask the
encryption password again, even when the contents (an empty header)
didn't change.

Another minor and weird bug: inline blocks. The part about showing the
unencrypted contents while keeping the disk contents encrypted doesn't
seem to work with encrypted inline blocks: they're saved encrypted,
but they're displayed encrypted. In fact they can't be displayed
unencrypted even if you call org-decrypt-contents. Maybe inline
encrypted blocks aren't supported.
To test this:
***** section
********************** this is an inline block
                 :crypt:
Content.

If you want you can split this to other threads or just ignore these
edge cases for now.

On Sat, 20 Jul 2024 at 14:12, Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Daniel Clemente <n142857@gmail.com> writes:
>
> > But org-crypt still feels strange. For instance, I decrypt a header,
> > add a space somewhere else and save. It's saved, but the header is
> > still visibly unencrypted in Emacs; that's unexpected, because
> > org-crypt-use-before-save-magic promised to „automatically encrypt
> > entries before a file is saved to disk“.
> > I checked the file from outside Emacs and I see that the header is
> > actually encrypted, so technically it did what it promised to do
> > though I don't see it in Emacs.
> > So there's a discordance between what I see and what is saved. Maybe
> > it's feature, not a bug: „you still see the decrypted contents but you
> > can trust that when they're saved they'll be saved encrypted“. This
> > may be clarified in the docstring. If it's a feature, I think it may
> > be useful; I just don't like having to trust that the silent
> > background-auto-encryption is working (I'll often want to verify the
> > file from outside Emacs). But users may have different preferences.
> > This may be material for another thread.
>
> Yup, I consider this as a feature. Especially for people using
> auto-save-visited-mode and similar. If saving is triggered on timer,
> while editing encrypted heading, encrypting everything in the middle of
> typing is not fun.
>
> > Minor thing, not important now: the cursor jumps to the end of the
> > header after a C-x C-s when in the middle of a currently-decrypted
> > block without changes.
>
> Should be better now on the latest version of the branch.
>
> > Another minor thing: I use a key that calls
> > (org-save-all-org-buffers), and if I press it e.g. from the *scratch*
> > buffer it may ask me the „Passphrase for symmetric encryption“
> > question (because I edited some crypted section) but I don't know
> > which buffer it's asking about. But it's not a problem because if I
> > press C-g then I'll see it.
>
> Should also be better now.
>
> > I see a new problem: with (org-crypt-use-before-save-magic) enabled, I
> > edit a decrypted section, press C-x C-s to save and it asks me for the
> > encryption password. Here, if I press C-g, org-crypt would catch it
> > and then tell me that it won't be able to encrypt due to the C-g.
> > However I'm not pressing C-g, what I'm doing is opening another TTY
> > frame (I'm running TTY emacsclient, with no X support, but under
> > urxvt); this makes the minibuffer disappear, and I see „Back to top
> > level“, and the whole contents of the section being encrypted are
> > lost.
>
> I tried to reproduce with the latest version of the branch. Seems to
> work fine. May you test?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>