Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

2023-02-11 Thread Alain . Cochard
Ihor Radchenko writes on Sat 11 Feb 2023 18:22: > We can indeed at such warning, but it will probably be not very > helpful. I don't understand this. And isn't it better to have a more accurate manual anyway? Apart from that, since the default value in 9.6 is 'smart' ('nil' in 9.5), I wonder

Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

2023-02-11 Thread Ihor Radchenko
alain.coch...@unistra.fr writes: > At any rate, shouldn't "2.2.3 Catching invisible edits" be a little > bit more specific about what kind of invisible edits are concerned? > Or perhaps just a warning that it is not all of them. We can indeed at such warning, but it will probably be not very

Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

2023-02-11 Thread Alain . Cochard
Ihor Radchenko writes on Fri 10 Feb 2023 09:56: > Only a handful of interactive commands support invisible edit > checks. In particular: self-insert-command (typing), deleting char > forward/backward, and `org-meta-return'. > > I guess we may instead provide a defcustom and hook the check

Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

2023-02-10 Thread Ihor Radchenko
alain.coch...@unistra.fr writes: >M-x undo > > I visually see no change, but I can observe by unfolding the headline > that 'bar' has disappeared. In my understanding of the documentation > above and of the docstring for org-fold-catch-invisible-edits, this > should only happen with 'nil'. >