Caret invisible after toggling all folds twice

[Ashwin Hirschi]

Often when I use the "Toggle all folds" command (from the View menu) I find that the caret is not visible anymore after unfolding. I need to press something like the down key to have Scite adjust the view and continue working...

Is this the intended behaviour? I find it a bit unfriendly...

I'm not sure if others are experiencing this too, but it looks quite easy to replicate: just open a largish file, move the caret somewhere near the end, perform the Toggle all folds command twice, and the caret is nowhere to be seen.

Perhaps something like a scroll caret action at the end of the FoldAll function could improve things?

Ashwin.

[John Yeung]

What system are you doing this on? I haven't been able to reproduce
on Windows 7 with SciTE 3.3.1.

I do find it annoying that when I "unfold all" I am taken back up near
the beginning of the file, even though both the caret and the visible
portion of the buffer were near the bottom of the file before that
step.

John

[Ashwin Hirschi]

> I do find it annoying that when I "unfold all" I am taken back up near 

> the beginning of the file, even though both the caret and the visible 

> portion of the buffer were near the bottom of the file before that 

> step. 

That is what I was trying to describe [unsuccessfully, it now seems... ;-)].

Note that after the unfold-all the caret/text insertion point is still where it originally was. You just cannot see it. And pressing e.g. a cursor key will trigger Scite to snap the view back to what it should be.

As Scite's current behaviour is odd [where does new text go?], I was wondering if the FoldAll function might be extended with something like a call to the scroll-caret primitive (that's already available in Scite).

Ashwin.

[John Yeung]

On Wed, May 8, 2013 at 6:37 PM, Ashwin Hirschi <ashwin....@gmail.com> wrote:
> Note that after the unfold-all the caret/text insertion point is still where
> it originally was. You just cannot see it. And pressing e.g. a cursor key
> will trigger Scite to snap the view back to what it should be.

I am not sure everyone will agree what the view *should* be.
Personally, I think the view should change state as little as possible
with a fold or unfold. For example, if I have a very long file that
has a lot of foldable sections, and I put the caret near the bottom,
and then fold all, my view stays near the bottom, which is what seems
natural to me. But it's natural because that is what I was viewing
before I did the fold, not because the caret is there.

If I leave the caret near the bottom of this long file which is
maximally folded, and I explicitly change the view without changing
the caret (maybe I use the scroll bar), so I'm now looking at the top
of the buffer, but the caret is still near the bottom; then when I
unfold all, what is most intuitive to me is for the view to remain
near the top, because that is where I have deliberately placed the
view.

So having the view jump back down to the bottom, just because the
caret is there, would probably be equally annoying to me. (I don't
really know; I practically never use folding.) If I had to guess on
an algorithm for positioning after unfold, I would say that whatever
line is the topmost visible line before the unfold should remain the
topmost visible line after the unfold.

John

[Ashwin Hirschi]

There are several possible rules to stick to for an editor. I agree that keeping the view "as stable as possible" is one of them. Never baffling the user is another.

The way I see it, the command to toggle the *current* fold works fine. It seems to adhere to both the above rules. But... the toggle *all* folds command *breaks* them both! Which is why I feel changing its behaviour would improve things (a lot).

In fact, I now realise I could have left off the "twice"-bit in the post subject:

Starting out with a large enough file (with all folds opened) you generally end up looking at something ("random") near the bottom of the file after the first toggle-all. A subsequent toggle-all to open all folds then moves the view near the top...

In both cases (i.e. after closing and after opening all folds) the user basically ends up staring at something that's completely unrelated to the initial view. Don't take my word for it. Please try it out (using a sufficiently large file, with enough top-level folds).

There's another way to look at the toggle-all-folds command. When exactly are people using it? And how can this best be accommodated?

Personally, I use it on 2 occasions. The first is to get my bearings within a large file. Here I am basically asking myself: what's around here? So, I use the toggle-all-folds commands twice, and then I'd like to be done (i.e. back where I was).

My second use-case is to move to something that's related/nearby. I use the toggle command once, then move the caret to where I want to be, and finally trigger the toggle-all command a second time to continue working.

Others may have different uses for the toggle-all command. But the 2 scenario's above should explain why I think a call to scroll-caret (at the end of FoldAll) does make sense.

Leaving things as they are, seems undesirable. What's the advantage of looking at a "random" view on your file after a toggle-all-folds?

Ashwin.

[John Yeung]

On Mon, May 13, 2013 at 2:24 PM, Ashwin Hirschi
<ashwin....@gmail.com> wrote:
> Personally, I use it on 2 occasions. The first is to get my bearings within
> a large file. Here I am basically asking myself: what's around here? So, I
> use the toggle-all-folds commands twice, and then I'd like to be done (i.e.
> back where I was).
>
> My second use-case is to move to something that's related/nearby. I use the
> toggle command once, then move the caret to where I want to be, and finally
> trigger the toggle-all command a second time to continue working.
>
> Others may have different uses for the toggle-all command. But the 2
> scenario's above should explain why I think a call to scroll-caret (at the
> end of FoldAll) does make sense.

It seems you didn't read my examples at all.

The important thing is not to put the view where the caret is; it's to
keep the view unchanged, whether it happens to be on the caret or not.

Your proposal potentially violates both of your "rules" (by not
preserving the state of the view and by bewildering the user).

John

[Ashwin Hirschi]

> It seems you didn't read my examples at all.

I read them just fine. What gives you the idea I did not?

> The important thing is not to put the view where the caret is; it's to
> keep the view unchanged, whether it happens to be on the caret or not.

Right. And like I wrote, using the Toggle all folds command *does* change the view at the moment.

Are you suggesting it is not? If so, please try it out for yourself. With any file that holds substantially more top-level folds than lines that can be displayed at once, you often end up looking at something completely unrelated to what you were viewing before the toggle-all.

I think that fact alone shows there's room for improvement here.

> Your proposal potentially violates both of your "rules" (by not
> preserving the state of the view and by bewildering the user).

I'm not baffled by an editor showing me where new text will go.

Ashwin.

[John Yeung]

On Mon, May 13, 2013 at 6:44 PM, Ashwin Hirschi
<ashwin....@gmail.com> wrote:
>> It seems you didn't read my examples at all.
>
> I read them just fine. What gives you the idea I did not?

The fact that you think positioning by caret is going to work for my
examples. I specifically laid out scenarios in which that would be
quite jarring.

>> The important thing is not to put the view where the caret is; it's to
>> keep the view unchanged, whether it happens to be on the caret or not.
>
> Right. And like I wrote, using the Toggle all folds command *does* change
> the view at the moment.

Your proposal to "fix" this is to automatically move the view to the
caret. What I am saying is that I don't want the view to
automatically move to the caret. I want the view to stay the hell
where it is.

John

[Ashwin Hirschi]

> What I am saying is that I don't want the view to automatically
> move to the caret. I want the view to stay the hell where it is.

Well, at the moment the view after a toggle-all-folds often has *no lines whatsoever* in common with the view before. Do you (or anyone else, for that matter) find Scite's current behaviour helpful? Or do we agree there's room for improvement?

Having said that, I think it may be quite tricky to come up with a mechanism that satisfactorily keeps the view as-is when the range of visible document lines changes so drastically (by either opening or closing all folds)...

Should the top line remain visible? The bottom one? What if the user was really looking at the section in the middle?

If the user just opened all folds, depending on the answer above, you're quite likely looking at completely different sections of the file they are editting. So, what's the right choice?

In other words, what does it even mean to keep the view "where it is" after opening all folds?

Ashwin.

[Neil Hodgson]

Ashwin Hirschi:

> Well, at the moment the view after a toggle-all-folds often has *no lines whatsoever* in common with the view before. Do you (or anyone else, for that matter) find Scite's current behaviour helpful? Or do we agree there's room for improvement?

I think it could be improved but moving to the caret is jarring and is not consistent with opening a single fold.

> Should the top line remain visible?

That would be my preference.

Another would be, when performing this through Ctrl+Shift+Click in fold margin to use the cursor location where the command was performed as that line should be the focus.

Neil

[Ashwin Hirschi]

>> Well, at the moment the view after a toggle-all-folds often has *no lines whatsoever* in common with the view before. Do you (or anyone else, for that matter) find Scite's current behaviour helpful? Or do we agree there's room for improvement?

> I think it could be improved but moving to the caret is jarring and is not consistent with opening a single fold.

Fair enough.

>> Should the top line remain visible?

> That would be my preference.
>
> Another would be, when performing this through Ctrl+Shift+Click in fold margin to use the cursor location where the command was performed as that line should be the focus.

I think these two changes would improve things a lot.

Ashwin.