Re: Scrolling down after Shift-TAB ?

[Nick Dokos <nicholas.dokos@hp.com>]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Hi again.
> 
> Very, very often, after a Shift-TAB that collapses all entries, a few
> lines in the vicinity of the cursor are shown at the top of the window,
> which is mainly empty for its reminder; we contemplate the vacuum
> *after* the file.  As my Org files are such that all the top level lines
> usually fit in one window, I then invariably scroll down so see it all.
> 
> I wonder if this could be automated, yet it is a bit uneasy to exactly
> define what would be the ideal.  Let me try an initial suggestion:
> 
> - If the whole Org file could be displayed at once, scrolling should
>   automatically occur so the first line of the window displays the
>   beginning of the Org file.
> 
> - Otherwise, if the last line of the window would be *outside* the Org
>   file, scrolling should automatically occur so the last line of the
>   window displays the end of the Org file.
> 
> - If neither of the above holds, do not automatically scroll.
> 
> Maybe others could improve on this with better ideas or algorithms ?
> 

You'd need to code it somewhat carefully sp that you wouldn't lose the
property that after a couple of S-TABs, the buffer looks the same as
when you started and point has not moved: that's useful in order to zoom
out and orient yourself in the larger context and then zoom in again to
continue working.

Have you tried C-l after the collapse? S-TAB C-l doesn't do quite what
you specified, but perhaps it's enough: it shrinks the vacuum after the
file, maybe to nothing, and it does not shift point. If you like
the behavior, you can always advise org-cycle so that it always calls
recenter afterwards:

--8<---------------cut here---------------start------------->8---
(defadvice  org-cycle (after org-cycle-recenter)
  "Recenter after org-cycle)"
  (recenter))

(ad-activate 'org-cycle)
--8<---------------cut here---------------end--------------->8---

Nick