From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Outline and org-mode don't insert text into folded sections logically Date: Mon, 31 Oct 2011 21:58:44 +0100 Message-ID: <3B42E036-D5D5-48F4-AF97-033ECF218FCD@gmail.com> References: <1315077299.1785.YahooMailClassic@web121520.mail.ne1.yahoo.com> <837h5nh1df.fsf@yahoo.it> <877h3xibb0.fsf@gnu.org> <81ehy5uy0t.fsf@gmail.com> <87wrbxdter.fsf@gnu.org> <877h3n7usn.fsf@gnu.org> <87hb2ru7qf.fsf@gnu.org> <87vcr7srij.fsf@gnu.org> <87k47ns2vx.fsf@gnu.org> <6CBBC924-DD81-46F0-B8ED-EC92D9B6A2AE@gmail.com> <87ehxuzw80.fsf@gnu.org> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:35921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKywV-0000Po-P0 for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 16:58:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKywU-0001W5-7k for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 16:58:51 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:50445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKywT-0001W0-Vz for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 16:58:50 -0400 Received: by eye4 with SMTP id 4so6224677eye.0 for ; Mon, 31 Oct 2011 13:58:48 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: Bastien , Kelly Dean , emacs-orgmode@gnu.org 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 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 >