Hi Carsten,
Carsten Dominik writes:
> OK, I will take a look at it and then push.
Great, thanks!
>> - From the docstring: "[...] or add in the middle or right after an
>> invisible region" -- I agree inserting while in the middle of the
>> invisible region would feel too unpredictable, but I
On Nov 2, 2011, at 11:10 AM, Bastien wrote:
> Hi Carsten,
>
> Carsten Dominik writes:
>
>> please find enclosed a patch which is my proposal for rounding
>> off this feature.
>
> thanks for the clean implementation.
>
> There is a small typo: the second (let ...) should be (let* ...),
> see
Hi Carsten,
Carsten Dominik writes:
> please find enclosed a patch which is my proposal for rounding
> off this feature.
thanks for the clean implementation.
There is a small typo: the second (let ...) should be (let* ...),
see attached updated patch.
> It introduces a variable, applies the c
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 lik
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)) (
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 obv
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
On 30.10.2011, at 08:30, Jambunathan K wrote:
>
>> - 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
> - 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,
On 30.10.2011, at 02:07, Bastien wrote:
> Hi Suvayu,
>
> suvayu ali writes:
>
>> Ah! Okay that seems reasonable, lets see what others think. :)
>
> I've now pushed this commit so that more people can test it.
While I think that this is a potentially useful idea,
I would like to point out a
Hi Suvayu,
suvayu ali writes:
> Ah! Okay that seems reasonable, lets see what others think. :)
I've now pushed this commit so that more people can test it.
--
Bastien
On Sat, Oct 29, 2011 at 18:15, Bastien wrote:
> Hi Suvayu,
>
> suvayu ali writes:
>
>> This works beautifully! I noticed that there is a tiny lag (maybe
>> about half a second) between the revealing and inserting the
>> character. However there is no such issue if there is no need to
>> reveal th
Hi Suvayu,
suvayu ali writes:
> This works beautifully! I noticed that there is a tiny lag (maybe
> about half a second) between the revealing and inserting the
> character. However there is no such issue if there is no need to
> reveal the surrounding text.
The lag is intentional -- just to ma
Hi Bastien,
This works beautifully! I noticed that there is a tiny lag (maybe
about half a second) between the revealing and inserting the
character. However there is no such issue if there is no need to
reveal the surrounding text.
Thanks a lot for implementing this feature. :)
On Sat, Oct 29
Hi Suvayu,
suvayu ali writes:
> Did you by any chance attach the old patch again? ;)
Er, yes :)
Here is the fresh one -- thanks for testing it.
>> As for `org-reveal', please report a bug if it doesn't work
>> as expected in specific parts of the buffer.
>
> I will try to make a more complete
Hi Bastien,
On Sat, Oct 29, 2011 at 16:10, Bastien wrote:
> Hi Suvayu,
>
> suvayu ali writes:
>
>> A few comments. I have also attached a small test file.
>
> thanks for the comments. Can you try the updated patch?
> It will take care of unfold the invisible part of the buffer
> when trying to
Hi Suvayu,
suvayu ali writes:
> A few comments. I have also attached a small test file.
thanks for the comments. Can you try the updated patch?
It will take care of unfold the invisible part of the buffer
when trying to edit _in_ it and _right after it_.
As for `org-reveal', please report a
Hi Bastien,
A few comments. I have also attached a small test file.
On Sat, Oct 22, 2011 at 15:53, Bastien wrote:
>
> Here is a dummy patch that prevents the user from editing invisible
> parts of the buffer. It doesn't prevent query-and-replace commands.
>
> Can people test it and comment it?
Jambunathan K writes:
>> Good idea. There is `post-self-insert-hook' but there is no
>> `pre-self-insert-hook' that would check whether the point is in
>> an invisible area of the buffer, and send a warning about this.
>
> In org-self-insert-command check for visibility at point and take the
>
Bastien writes:
> Hi Suvayu,
>
> suvayu ali writes:
>
>> I think this might be the right time to ask for a feature request,
>> unfold a tree if someone tries to edit it. This will prevent many
>> "mishaps".
>
> Good idea. There is `post-self-insert-hook' but there is no
> `pre-self-insert-hook'
Hi Bastien,
On Sat, Oct 22, 2011 at 12:13 PM, Bastien wrote:
>
> suvayu ali writes:
>
>> I think this might be the right time to ask for a feature request,
>> unfold a tree if someone tries to edit it. This will prevent many
>> "mishaps".
>
> Good idea. There is `post-self-insert-hook' but ther
Hi Suvayu,
suvayu ali writes:
> I think this might be the right time to ask for a feature request,
> unfold a tree if someone tries to edit it. This will prevent many
> "mishaps".
Good idea. There is `post-self-insert-hook' but there is no
`pre-self-insert-hook' that would check whether the po
Hi,
On Mon, Sep 5, 2011 at 9:52 AM, Giovanni Ridolfi
wrote:
> Hi, Kelly,
>
> I can understand that this seems to be illogical from your point of
> view, but folded subtrees are meant for a faster and cleaner
> organization of the text, not for editing.
>
> Once you've decided to edit a subtree y
Kelly Dean writes:
> Using Emacs 23.2.1, make a buffer in outline mode and enter this:
> *1A
> Body of 1A
> **2A
> Body of 2A
> ***3A
> Body of 3A
> Org-mode exhibits the same problem which outline mode does. Put spaces
> after the asterisks as org-mode requires, switch to org-mode, and
> cycle
Using Emacs 23.2.1, make a buffer in outline mode and enter this:
*1A
Body of 1A
**2A
Body of 2A
***3A
Body of 3A
*1B
Body of 1B
Now, collapse all except the first item, so you have:
*1A
Body of 1A...
*1B...
Put the point at the beginning of the line "*1B...", type "test" and press
enter. Now yo
25 matches
Mail list logo
