Re: Is there a save-outline-visibility excursion or so?

[Jambunathan K <kjambunathan@gmail.com>]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> C-h f save-restriction
>>
>> You will find plenty of examples in Orgmode codebase.
>
> Well, I tried it out, and in this case it does not really reset the
> buffer to its original (partly folded) visibility state, but rather
> leaves it in show-all state. So I guess narrowing/widening and
> outline-visibility changes are, at least at this level, not the same.

Mmmm. Restriction apparently applies to (virtual) bounds of the buffer -
beg and end positions and has nothing to do with invisibility.

----------------------------------------------------------------

You may find it easier to work with `make-indirect-buffer' and
`clone-indirect-buffer' (See Elisp manual).

(I think) In the first case, the indirect buffer starts with no
overlays.  In the second case, the indirect buffer starts with same
*overlay values* as the first one.

You can see that any visibility operation on the indirect buffer doesn't
affect the visibility of the original buffer.

----------------------------------------------------------------

If you lookup the `org-export--generate-copy-script', towards the end of
that defun you will see a snippet like this.

    ,----
    | ;; Overlays with invisible property.
    | ,@(let (ov-set)
    |     (mapc
    |      (lambda (ov)
    |        (let ((invis-prop (overlay-get ov 'invisible)))
    |          (when invis-prop
    |            (push `(overlay-put
    |        	    (make-overlay ,(overlay-start ov)
    |        			  ,(overlay-end ov))
    |        	    'invisible (quote ,invis-prop))
    |        	  ov-set))))
    |      (overlays-in (point-min) (point-max)))
    |     ov-set)
    `----

Visibility is controlled by `buffer-invisibility-spec'.

This should be a good starting point.