Re: Unhiding edited areas

From: Carsten Dominik <carsten.dominik@gmail.com>
To: Martin Pohlack <mp26@os.inf.tu-dresden.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Unhiding edited areas
Date: Mon, 3 Aug 2009 15:53:56 +0200	[thread overview]
Message-ID: <E5D9ECAF-ACD9-4CDD-94AF-4C0B5417E560@gmail.com> (raw)
In-Reply-To: <4A71EB7A.8060608@os.inf.tu-dresden.de>

On Jul 30, 2009, at 8:50 PM, Martin Pohlack wrote:

> Hi Samuel,
>
> Samuel Wales wrote:
>> Hi Martin,
>>
>> This is a huge issue.[1]
>>
>> Here is what I do to try to work around it.
>>
>> I use git, to limit the damage from confusion.
>
> Yes, this or a versioning filesystem is probably advisable.
>
>> I expand the entire buffer if I think I am about to be confused.
>>
>> ;;i like the idea of clustering undo but find it disconcerting
>> (setf org-self-insert-cluster-for-undo nil)
>> ;;somebody, I think Carsten, suggested this, and it might work for
>> you, but for some reason I commented it out.  I don't remember what
>> the reason was.  Maybe speed.
>> '(defadvice undo (after org-undo-reveal activate)
>> "Make point and context visible after an undo command in Org-mode."
>> (and (org-mode-p) (org-reveal)))
>> ;;(ad-unadvise 'undo)

Hi Samuel, Martin,

this could be a good FAQ entry, I think.

If speed was the reason to discard this, maybe try again, because
I believe that recent changes will have solved many of the speed issues
that might plague org-reveal in lists with many siblings.

- Carsten

>
> Awesome, this is exactly what I was looking for!
>
>> [1]  It is even more important when combined with what is IMO Emacs's
>> greatest need for improvement, which is that you can undo, and undo  
>> an
>> undo, and this is considered to be sufficient since you can get
>> anywhere in the timeline in principle -- but many users, myself
>> included, prefer a true redo command, both because undoing an undo
>> does not let you do commands (such as copying) in the middle of an
>> undo sequence without going the other direction, and because it feels
>> more intuitive to tell emacs where in the timeline we want to go, and
>> go forward or backward if we overshoot, thus making it possible to
>> view the timeline the same way as we go backward and forward in any
>> linear sequence.  (redo.el provides the functionality, but it  
>> corrupts
>> the buffer.)  Of course, many are comfortable with the traditional
>> undo-the-undo mechanism, so that should stay possible, but there are
>> many who are not, and a redo mechanism would satisfy them.  It is
>> possible to get more fancy with a tree.
>
> The current undo system is very powerful as it doesn't lose history
> (unless you hit a quota limit).  With undo-redo systems you usually  
> can
> lose history if you edit things in an old state.  Suddenly redo is not
> available anymore.  You can only access the most recent branch in the
> history tree.
>
> In emacs this will not happen as you can reach all nodes in the buffer
> history, but these states are not easily accessible, especially, if  
> you
> went back and forth some times.  I cannot track the list of states  
> in my
> mind or imagine the current structure of the undo tree, I can only go
> step by step and look at the situation in the buffer and decide  
> whether
> this is what I wanted or not.
>
> I recently stumbled upon an article which, I think, quiet nicely
> summarized what one wants:
>
>  http://e-texteditor.com/blog/2006/making-undo-usable
>
> But it's not available for emacs ...
>
> Cheers,
> Martin
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode