emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Outline and org-mode don't insert text into folded sections logi


From: Carsten Dominik
Subject: Re: [O] Outline and org-mode don't insert text into folded sections logically
Date: Mon, 31 Oct 2011 21:58:44 +0100

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 <address@hidden> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]