Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Extra lines are selected when dragging with the mouse causes the messages view to scroll #409

Closed
Arnavion opened this Issue Feb 14, 2013 · 6 comments

Comments

Projects
None yet
3 participants
Owner

Arnavion commented Feb 14, 2013

  1. Select a sufficient large number of lines with the mouse such that the viewport scrolls down a bit.
  2. Scroll back up to see the start of the selection.

A few more lines at the beginning will have been selected.

Happens in both Windows and Linux, 2.9.4 as well as ToT.

Related: You can't scroll all the way to the most recent line if this happens. The viewport will stop scrolling a few lines above the most recent one. All the lines upto the most recent one will still get magically selected, though.

Repro: http://privatepaste.com/ee9c8c886a

@ghost ghost assigned RichardHitt Sep 27, 2013

Owner

TingPing commented Oct 7, 2013

a6cc734 is the cause, I mentioned it to @RichardHitt and hopefully he can work out something better, worst case we revert the scroll timeout functions.

Contributor

RichardHitt commented Oct 28, 2013

Transcribed from freenode:#hexchat-devel:

re #409, Arnavion, that issue is in two parts. I have no trouble at all reproducing the second part, but I can't reproduce the first part in multiple tries.

Can you help with a file (of say 100 lines) I can paste on a new channel that will help me reproduce it? Or a ../scrollback/FreeNode*/#whateverchannelname.txt file I could put up with /join #whateverchannelname ?

Also does your symptom include or require lines that wrap? Also what is your the width (and height too, I guess) in characters of your text window in which you're able to reproduce the first part of #409?

@ghost ghost assigned Arnavion Nov 9, 2013

Contributor

RichardHitt commented Nov 9, 2013

Hi, Arnavion. thanks for your comments on pull request #831. I am reassigning #409 (this issue) to you, because I don't seem to be solving it to your satisfaction. Let me know please if I can help out at all.

The problem you mention at #813 is one I believe existed in xchat a decade ago. I may try to continue getting a handle on it still, and I probably will try to continue understanding xtext.c. But it's not the problem stated here in issue #409. Additionally, the acceleration change I tried to add in RichardHitt/select is not material to the fix to #409 I implemented, but it seems still to me to be a good idea.

Speaking of acceleration of select-scrollng, though, what program do you think does a good job of accelerating selection scrolling? I still think this time-based scheme is best. I note that bash (probably really gtk?) doesn't accelerate its selection scrolling at all. Let me know what you like and I'll go try it and see if I can reverse-engineer it or something. But this present incident is yours now to do with as you like.

@ghost ghost assigned RichardHitt Nov 9, 2013

Contributor

RichardHitt commented Nov 11, 2013

Issue #836 supersedes the first part of this issue.

Contributor

RichardHitt commented Nov 12, 2013

Closing this issue. It's broken into two issues, #836 and #837, as noted above.

Contributor

RichardHitt commented Nov 12, 2013

Closing, moved to #836 and #837

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment