Preventing org-cycle from scrolling the buffer

Preventing org-cycle from scrolling the buffer

[Dmitrii Korobeinikov]

HI all,

When calling org-cycle on a collapsed section which contains a lot of
text, the headline is adjusted to the top of the page. Collapsing it
doesn't revert the scroll, which makes it hard to quickly peek at
what's in the section without getting disoriented. Is there a flag or
some other way of turning off this autoscroll?

Scroll revert wouldn't be so bad to have either, by the way (in
addition to, not instead of, though). Since org knows when the cursor
moves away from the headline after tabbing, it seems this feature can
be implemented without too much hassle. I would even go as far as to
suggest making it a default if it gets done.

What do you think?

Best,
DK

Re: Preventing org-cycle from scrolling the buffer

[Marco Wahl]

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
> When calling org-cycle on a collapsed section which contains a lot of
> text, the headline is adjusted to the top of the page. Collapsing it
> doesn't revert the scroll, which makes it hard to quickly peek at
> what's in the section without getting disoriented. Is there a flag or
> some other way of turning off this autoscroll?

AFAICS this behavior can be controlled via customizable variable
org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
removing entry org-optimize-window-after-visibility-change.

> Scroll revert wouldn't be so bad to have either, by the way (in
> addition to, not instead of, though). Since org knows when the cursor
> moves away from the headline after tabbing, it seems this feature can
> be implemented without too much hassle. I would even go as far as to
> suggest making it a default if it gets done.
>
> What do you think?

IDK.  AFAICS you are right with your argumentation.  I don't see the
need of that feature, though, yet.  But that's just me.  I think you are
the best candidate to try an implementation of the feature.


Best regards,
-- Marco

Re: Preventing org-cycle from scrolling the buffer

[Dmitrii Korobeinikov]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

> AFAICS this behavior can be controlled via customizable variable
> org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
> removing entry org-optimize-window-after-visibility-change.

Nice, I see!

> IDK.  AFAICS you are right with your argumentation.  I don't see the
> need of that feature, though, yet.  But that's just me.  I think you are
> the best candidate to try an implementation of the feature.

I have attached a small patch, seems to be working! Of course, if this
is to be merged, that defvar will have to turn into a defcustom.

Best,
DK

вт, 31 мар. 2020 г. в 21:29, Marco Wahl <marcowahlsoft@gmail.com>:
>
> Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
> > When calling org-cycle on a collapsed section which contains a lot of
> > text, the headline is adjusted to the top of the page. Collapsing it
> > doesn't revert the scroll, which makes it hard to quickly peek at
> > what's in the section without getting disoriented. Is there a flag or
> > some other way of turning off this autoscroll?
>
> AFAICS this behavior can be controlled via customizable variable
> org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
> removing entry org-optimize-window-after-visibility-change.
>
> > Scroll revert wouldn't be so bad to have either, by the way (in
> > addition to, not instead of, though). Since org knows when the cursor
> > moves away from the headline after tabbing, it seems this feature can
> > be implemented without too much hassle. I would even go as far as to
> > suggest making it a default if it gets done.
> >
> > What do you think?
>
> IDK.  AFAICS you are right with your argumentation.  I don't see the
> need of that feature, though, yet.  But that's just me.  I think you are
> the best candidate to try an implementation of the feature.
>
>
> Best regards,
> -- Marco

[-- Attachment #2: 0001-org.el-Add-an-option-to-restore-scroll-position-when.patch --]
[-- Type: text/x-patch, Size: 2472 bytes --]

From ee9826f62698b2e5d200fdf90a963ddd751ad679 Mon Sep 17 00:00:00 2001
From: Dmitrii Korobeinikov <dim1212k@gmail.com>
Date: Fri, 3 Apr 2020 16:19:33 +0600
Subject: [PATCH] org.el: Add an option to restore scroll position when
 collapsing a tree

* lisp/org.el (org-optimize-window-after-visibility-change): Restore the
scroll position after folding a tree (if no commands other than
`org-cycle' get executed in the meantime, so has to be right after
its expansion).
(org-restore-scroll-position-on-collapse): Non-nil for the new behavior.

`org-cycle' scrolls the buffer when expanding a large tree to show as
much of the tree as possible, but doesn't restore the initial view when
folding back, which is disorienting.

TINYCHANGE
---
 lisp/org.el | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 06891b8bd..1b2dfdb8c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6071,6 +6071,9 @@ region as a drawer without further ado."
 (put 'org-cycle-global-status 'org-state t)
 (defvar-local org-cycle-subtree-status nil)
 (put 'org-cycle-subtree-status 'org-state t)
+(defvar-local org-scroll-position-to-restore-after-cycling nil)
+(defvar org-restore-scroll-position-on-collapse t
+  "Non-nil if should restore display position after org-cycle folds the tree.")
 
 (defun org-show-all (&optional types)
   "Show all contents in the visible part of the buffer.
@@ -6501,9 +6504,17 @@ This function is the default value of the hook `org-cycle-hook'."
     (cond
      ((eq state 'content)  nil)
      ((eq state 'all)      nil)
-     ((eq state 'folded)   nil)
-     ((eq state 'children) (or (org-subtree-end-visible-p) (recenter 1)))
-     ((eq state 'subtree)  (or (org-subtree-end-visible-p) (recenter 1))))))
+     ((eq state 'folded)
+      (if (and org-restore-scroll-position-on-collapse
+               (eq last-command this-command))
+          (set-window-start nil org-scroll-position-to-restore-after-cycling)))
+     ((eq state 'children)
+      (setq org-scroll-position-to-restore-after-cycling (window-start))
+      (or (org-subtree-end-visible-p) (recenter 1)))
+     ((eq state 'subtree)
+      (if (not (eq last-command this-command))
+          (setq org-scroll-position-to-restore-after-cycling (window-start)))
+      (or (org-subtree-end-visible-p) (recenter 1))))))
 
 (defun org-clean-visibility-after-subtree-move ()
   "Fix visibility issues after moving a subtree."
-- 
2.25.1

Re: Preventing org-cycle from scrolling the buffer

[Bastien]

Hi Dmitrii,

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> Nice, I see!
>
>> IDK.  AFAICS you are right with your argumentation.  I don't see the
>> need of that feature, though, yet.  But that's just me.  I think you are
>> the best candidate to try an implementation of the feature.
>
> I have attached a small patch, seems to be working! Of course, if this
> is to be merged, that defvar will have to turn into a defcustom.

thanks for the patch, I applied a small variant of it as 056fc532b.

I don't think we need an option (defcustom) for this, the current
behavior seems correct -- but I'm convinced some people would prefer
the previous behavior.  If there are a lot of such people with strong
argument, perhaps we will have to revert the change.

Thanks,

-- 
 Bastien

Re: Preventing org-cycle from scrolling the buffer

[Dmitrii Korobeinikov]

Hi Bastien,

Thank you, both for accepting this and for the fix with the blank line folding!

Best,
DK

сб, 5 сент. 2020 г. в 11:26, Bastien <bzg@gnu.org>:

>
> Hi Dmitrii,
>
> Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
>
> > Nice, I see!
> >
> >> IDK.  AFAICS you are right with your argumentation.  I don't see the
> >> need of that feature, though, yet.  But that's just me.  I think you are
> >> the best candidate to try an implementation of the feature.
> >
> > I have attached a small patch, seems to be working! Of course, if this
> > is to be merged, that defvar will have to turn into a defcustom.
>
> thanks for the patch, I applied a small variant of it as 056fc532b.
>
> I don't think we need an option (defcustom) for this, the current
> behavior seems correct -- but I'm convinced some people would prefer
> the previous behavior.  If there are a lot of such people with strong
> argument, perhaps we will have to revert the change.
>
> Thanks,
>
> --
>  Bastien