Console mousewheel scrolling behavior seems weird

[dicene]

When the main console is only showing stuff live(you are NOT scrolled up looking at old lines in the scrollback) and you use the mouse wheel to scroll up, the first tick of the wheel will split the window and the top portion(the scrollback portion) starts out scrolled all the way down, showing the very newest lines at the bottom. Every further tick of the mousewheel up just scrolls that portion of the window(for me it's 3 lines at a time).

Based on that behavior, it seems to me like the proper way for the console to handle scrolling down with the mouse wheel is to let you scroll to the very bottom, 3 lines at a time, and if you tick the wheel downward ones more time after it's already live, you would close the scrollback and just show live lines again.

That's not how scrolling down works though. The mouse wheel will scroll you down a few lines at a time, but when you get to the point where you approach the bottom of the scrollback, there is a portion of scrollback at the bottom you can't see before the mouse wheel clicks close the scrollback. It's related to the positioning of the separator between the live lines and the scrollback lines when scrolling through old lines. If the separator has been dragged to where there are 50 lines of the old scrollback showing at once, when you attempt to scroll past about 50 lines from the bottom, the console unsplits and goes completely live again.

This can be annoying when you're looking through something like a chart or help file, or when looking back through a combat log. It can be easy to lose your place since instead of being able to scroll from the top of the chart to the bottom at a steady pace, once you get down to the bottom portion of it the scrollback will unsplit suddenly. This happens to me enough for me to want to modify it to work the way I outlined at the top, which really seems to me like the most intuitive way for it to work, considering its behavior when scrolling up.

Is there a reason it behaves so seemingly counter-intuitively, or would my suggested functionality be a welcomed modification?

[SlySven]

Improve away! That scrolling behaviour irks me as well but I've not got around to looking into it, theoretically, also the scroll bar should only start to show when there is enough to scroll (but given that it might affect GUI layouts I guess it is simplest to always show it) and (I can't recall) I think the linkage between the scroll bar slider is not as tightly coupled to what is contained in the widget(s) as one might like (adjust the slider size to sort of reflect what portion of the buffer is being shown?)

[dicene]

"Not as tightly coupled"
I'm pretty sure it stays at the bottom permanently for me. =P

[Vadi]

So are you saying there should be an extra "scroll" before it actually closes, to prevent accidental closing?

[dicene]

I'm saying that it would be more intuitive if when you scroll down, it allows you to scroll all the way to the bottom before it closes the second console and moves back to displaying lines "live". Instead, there is no way to scroll with the mouse to any of the lines at the bottom of the console because the second console is hidden as soon as you scroll down to the bottom screen worth of lines.

As an example of where this behavior is annoying: Imagine you're reading something long that takes up more than a single screen, like a long HELP file. You send HELP <whatever>||MORE||MORE to get the whole thing to display. You're reading through this document from top to bottom, but when you get to the bottom screen of text, instead of letting you scroll continuously down to the bottom, it goes back to live mode.

The way I currently get around this is by spamming LOOK or something to get it off the screen so I can continue to read it. I don't think I should have to do this. I would just like to be able to scroll continuously until the scrollback is showing the very latest line, then the next scroll will close the scrollback, instead of it closing automatically when I'm getting within <x> lines of being live.

[Vadi]

I think that would be a good improvement, yes. It should allow you to see those lines before closing. As long as you don't end up with the same stuff you already see in the bottom, live half of the screen.

[dicene]

I disagree with that last sentence. I think it is useful to be able to move the scrollback to whatever line you want, since it allows you to continue reading something, uninterrupted, by effectively "locking" part of the screen there. Looks like modifying a single conditional was all it took to get the behavior how I wanted. I'll test it a little bit more to test exactly what lines it will allow you to see, but it makes sense to me to allow it to scroll basically to the bottom of the console.

[Vadi]

I'll have to see how your implementation works, but from what I've seen elsewhere, it then makes it a pain to get rid of the scrolled console and it ends up being annoying then.