Hi Bastien, please find enclosed a patch which is my proposal for rounding off this feature.
It introduces a variable, applies the check to org-delete-char and org-delete-backward-char, and removes the (sit-for 1), and it never moves the cursor. I have been unsing it for a day or two, and I like the `smart' setting of the variable. Even though, I do agree with your earlier post that the default should be nil. - Carsten
checking-for-invisible-edits.patch
Description: Binary data
On 30.10.2011, at 10:04, Bastien wrote: > Hi Carsten, > > Carsten Dominik <carsten.domi...@gmail.com> writes: > >> - This patch covers only one of many ways to make unwanted changes >> in an invisible area. Others would be delete, backspace, >> kill-region, yank, kill-line, and an arbitrarily long list of >> less obvious other commands. Full protection could only be >> done with pre-change-hooks or so, but would then prevent >> also programmed changes - something that would not be useful. > > Yes, I don't want programmed changes to be affected by this feature. > > But having such a warning for `org-delete' would also be useful IMHO. > >> `org-self-insert-command' is probably only ever used in an >> interactive way, so the patch as you have written it may very >> well function correctly. >> >> - All the code in org-self-insert-command is executed for each >> keypress, so one needs to be careful to have this function >> carry as little overhead as possible. > > I actually think there should be a user option > `org-edit-invisible-send-warning' defaulting to nil. > > The request "don't let me shoot in my foot" is a common > one, and this option would let people set this to `t'. > >> - Currently this chokes at the beginning of the buffer because >> the invisibility test is also run at (1- (point)). > > Fixed, thanks. > >> - I am not sure if I understand the positioning code: >>> (if (or (eq invisible-before-point 'outline) >>> (eq invisible-before-point 'org-hide-block)) >>> (goto-char (previous-overlay-change (point)))) >>> (org-cycle) >>> (if (or (eq invisible-before-point 'outline) >>> (eq invisible-before-point 'org-hide-block)) >>> (forward-char 1)) >> >> So when I happen to be somewhere in the middle of invisible >> text and press a character, it seems to me that the character >> will be inserted at the beginning of the invisible text, and >> not where the cursor was. >> >> Maybe a better solution would be to save point, unfold, >> go back to point, throw and error and not insert the pressed >> character. I am not sure, though. > > Throwing an error and not inserting the text was what my first > patch did. I thought it was too restrictive, though. > > With an option `org-edit-invisible-send-warning', we could have both: > `t' would just throw a warning, 'prevent would throw an error. > >> Maybe you can explain your reasoning? > > My reasoning is that, when in the "middle" of an invisible region, > the user does not know where the point is, hence he doesn't really > know where he wants to insert characters. In this case, I assume > insert at the beginning of the invisible region is a reasonable > default. > > Thanks for the feedback -- let's continue brainstorming, I think > this feature is important. > > Best, > > -- > Bastien
