Size of scrollbar slider doesn't reflect the ratio of visible buf / total buf

[koro]

Hi,

For most applications I use, the vertical scrollbar slider is usually dynamically sized to reflect the ratio of visible buffer to the total length of the buffer.   For example, if you can page down three times to get from the beginning of the buffer to the end of the buffer then the vertical scrollbar slider would be approximately 1/3 the height of the editor window.    It is only when the buffer contained in the editor window grows extremely large in relation to the height of the window that the slider is capped at the smallest convenient size that is still practical to use.

I personally find this convention very useful. 

I have noticed that with the Slickedit editor windows, this convention is not followed and the slider is always very tiny.  In addition, the slider does not seem to always be positioned accurately to reflect your current position in the buffer when you are near the buttom of the buffer.   For example, if you page all the way to the end of a buffer, the slider is not pegged against the buttom.  This can give the impression there may still be code underneath your current position and the only way to find out is to try and scroll down further.

Is there an option or slick c change that would enable this feature or would it be possible to consider this for an upcoming release?

Thanks.

[Tim Kemp]

Which operating system are you using and what version of SlickEdit?  I'm on Windows XP running 12.0.1.0 and the size of the slider button works the same way as in other applications (which is the way you say you want it to work.)

- Tim

[koro]

I'm on windows XP SP2 and running SE 12.0.1.0.     It's good to know that SE already has this built in - now I just need to figure out why its not working on my computer...

Thanks
-Keith

[Ryan]

Are you using Vim, Emacs, or Epsilon (yes, it exists) emulation?

- Ryan

[koro]

I'm using the default CUA emulation and I run with the "Multiple Files per Window" option unselected. 

Strangely enough, any editor window works correctly while it is displaying the process buffer but has the problem when displaying any C files.

If I use the tabs to toggle one window between displaying a C file and the process buffer, the scroll bar works correctly while displaying the process buffer but not when displaying the C file.

-Keith

[koro]

After some experimentation, it appears that this behavior is linked to the "Soft Wrap" option.

If I uncheck View->Soft Wrap then the scrollbar sliders for the windows return to their proper sizes.

If I select View->Soft Wrap then the scrollbar sliders go back into the funny state.

Hopefully this helps pin-point the issue.

-Keith

[Ryan]

Awesome...that's what I thought.  That's why I asked about those emulations because I think we force that option on for Vim etc.  I'll see if we can get to the bottom of why this happens...

- Ryan

[Clark]

When SoftWrap is on, SlickEdit uses a seek position algorithm instead of a display line algorithm.  That way, no extra processing of the file is necessary.  A better approach which does not kill performance requires some background threading.

[deep.bodapati]

First off, a big thanks to Keith for (a) doing a great job explaining the issue.

And thank you to Clark for explaining the details behind the issue.

However, I have to say that after reading the explanation, I was a bit sad to learn that I'd have to give up one of the two features - SoftWrap or accurate sizing of the scroll bar. They are both great features and I wish there were a way to have the cake and eat it too.

Is there any way that this choice (of losing some processing power at the expense of a correct ratio scroll bar) be left up to the user? This is a first round solution, until you guys come up with the 'background threading' approach.