Hi Bastien, more feedback:
I just got bitten by this while editing a file with visible-mode turned on. I was trying to add some text, and the code would continuously jump to some other position. Took me a while to figure out. So I suggest to add a test for (or (not (boundp 'visible-mode)) (not visible-mode)) before doing anything. Also, this made me again think that moving point is not a good idea. - Carsten On 30.10.2011, at 16:37, Carsten Dominik wrote: > > 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. > > I guess you mean, org-delete-char and org-delete-backward-char > >> >>> `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. > > +1 > >> >> 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. > > I like that. > >> >>> 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. > > I have to admit that it does work well at the end of a folded headline, > and delete-backward-char there would also work fine. > > I would think, when the cursor is in the middle of an invisble regions, > the change should always be denied. > > Cheers > > - Carsten > >> >> Thanks for the feedback -- let's continue brainstorming, I think >> this feature is important. >> >> Best, >> >> -- >> Bastien >