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: Sun, 30 Oct 2011 16:37:04 +0100 Message-ID: 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]:51132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKXRj-0004b5-Hr for emacs-orgmode@gnu.org; Sun, 30 Oct 2011 11:37:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKXRi-00057L-1k for emacs-orgmode@gnu.org; Sun, 30 Oct 2011 11:37:15 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:45736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKXRh-00057G-HP for emacs-orgmode@gnu.org; Sun, 30 Oct 2011 11:37:13 -0400 Received: by eye4 with SMTP id 4so5234118eye.0 for ; Sun, 30 Oct 2011 08:37:12 -0700 (PDT) In-Reply-To: <87ehxuzw80.fsf@gnu.org> 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: Bastien Cc: emacs-orgmode@gnu.org, Kelly Dean 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