Re: Feature request: navigate history of folding views

["William Henney" <whenney@gmail.com>]

Hi Carsten

On 9/4/07, Carsten Dominik <dominik@science.uva.nl> wrote:
>
> On Sep 3, 2007, at 19:23, William Henney wrote:
> > On 7/11/07, Eddward DeVilla <eddward@gmail.com> wrote:
> >> For my uses, what I would love is a way to have org-mode remember how
> >> a subtree was folded so I could hide a subtree and then reopen it
> >> later with all of it children exposed or hidden as they were before.
> >> I like to use hiding for context in a project, but I get by without
> >> it.
> >
> > This is similar to something that I have often wished for: some sort
> > of history mechanism for the expose/hide states of a buffer. The ideal
> > interface would simply be for "C-_" (undo) to work on the folding
> > views. Is this at all feasible?
>
> Not easily.  outline-mode uses overlays to hide parts of the buffer,
> and overlay changes don't make it into the undo list.  Text property
> changes would be undoable.
>

OK, I understand this isn't going to happen any time soon.

> I guess storing the hiding state in some way is in principle
> possible but a lot of work.  More-over, it would be hard to write
> it in a way that it would this smoothly integrate into the normal
> work flow.
>

Yes. On further reflection, my suggestion of just adding folding
changes to the undo list wasn't a good one. We would really want a
separate navigable list, similar to "C-c &" for buffer positions.

Perhaps there are other ways to achieve what I want. Here is a common
scenario where I have felt that a history of folding states would be
useful:

Say I am working on two or three small parts of a large org file. The
rest of the file is folded. At some point I need information from
elsewhere in the file, so I use "C-c /" to look for it. This creates a
sparse tree that wipes out the particular folding state that I had
originally created, so I now have to go back and search for the
contexts that I was working in. Not good!

One way that this could be improved (without implementing a history
mechanism) would be if sparse trees were always created in indirect
buffers, so the original view could be recovered. Would this be an
easier solution to implement? It seems that "C-c C-j" (org-goto)
already works in this sort of way (I only discovered org-goto a few
days ago and I am rapidly falling in love with it).

Cheers

Will


-- 

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia