Bug 201899 - konsole mouse wheel scrolling: git
Summary: konsole mouse wheel scrolling: git
Status: RESOLVED NOT A BUG
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-29 16:17 UTC by Diggory Hardy
Modified: 2009-07-31 14:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diggory Hardy 2009-07-29 16:17:07 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Ubuntu Packages

I really like the new mouse-scrolling mode konsole 4.x has with less, pager, etc.

Git commands (e.g. "git log"), when their output is longer than one screen, automatically pipe the output through a pager ("git" and "pager" processes are running when it's open). It'd be nice to be able to scroll this with the mouse wheel in the same way as with less.

I'm guessing konsole has some kind of whitelist of interactive commands to provide this behaviour for, but I couldn't find it. Probably just providing git this behaviour when it stays open in interactive mode would do it, although I'm not sure what would happen with other interactive git commands (e.g. "git add -p").
Comment 1 Matthew Woehlke 2009-07-29 16:52:30 UTC
It doesn't; mouse wheel sends arrows iff there is no scrollback. Depending on your setting of $TERM, 'less' may use the "alternate buffer" in a way that there is no scrollback while 'less' is active, in which case the mouse wheel will scroll.

That said, I am surprised git isn't using less. You can probably tweak things so that git will use less as its pager in a way that less is using the alternate buffer, which should give you what you are looking for.
Comment 2 Diggory Hardy 2009-07-29 17:12:35 UTC
Well, I think git is using less. /usr/bin/pager indirectly links to /usr/bin/less. Does this mean git is preventing less from using the alternate buffer via environment variable or command-line option?

Any hints on where to find out about this "alternate buffer", and less's use of it, please?

Thanks
Comment 3 Matthew Woehlke 2009-07-29 17:27:00 UTC
It's possible, don't know what else would be the problem. When you use 'less' normally, the output disappears after less exits, yes? Does the same happen when using less via git? (What about scrollback? Again, in alternate-screen-buffer mode you should notice the scrollback disappears; does the same happen using git?)

Information... other than GIYF, I don't know (didn't spot anything in less' manpage). I tried "terminal alternate screen buffer" and got a bunch of results that might be interesting, though they are mostly other bug reports and the like.
Comment 4 Diggory Hardy 2009-07-29 17:51:41 UTC
less's output disappears, git's doesn't. The scrollback history similarly disappears for less but not git.

I guess I'll have to start digging when I find time then, if I really want to get to the bottom of this. Could be useful for programming to know how alternate buffers work in any case.

So is this purely the screen buffer, but konsole detects when it's used and alters mousewheel input, scrollback display, and possibly more?

In any case this bug/request is irrelevent to konsole then, but much thanks for the help!
Comment 5 Diggory Hardy 2009-07-29 18:02:08 UTC
Found a few possibly relevent links to get me started:
http://linuxreviews.org/man/xterm/ (man xterm)
http://lists.kde.org/?l=konsole-devel&m=114238290213494&w=2
less -X disables alternate buffer:
http://lists.kde.org/?l=konsole-devel&m=106491436409351&w=2
Comment 6 Matthew Woehlke 2009-07-29 18:25:53 UTC
> So is this purely the screen buffer, but konsole detects when it's used and
> alters mousewheel input, scrollback display, and possibly more?

Not "purely". As I said in comment #1, the behavior is dependent on if there is /scrollback/. Alternate screen buffer mode generally (maybe always, but since I use TERM=linux I don't have ASB) does not have scrollback, but you can also have no scrollback for other reasons (because you cleared it, or in a fresh tab).

My guess would be as you say, git invoking less in a way that it doesn't use the ASB. Sounds like you're already looking into that.

Some things that might help:
- setting PAGER
- setting LESS
- 'git <something that makes lots of output> | less'

(The last isn't necessarily a permanent solution, but to help track down if git is indeed the culprit... though, my 'git' is actually a script that calls the real git piped through 'less -FR', so it /is/ actually possible to adopt this as a permanent solution if necessary, without the overhead of having to type '| less' every time.)
Comment 7 Robert Knight 2009-07-30 08:39:47 UTC
git sets the LESS environment variable to FRSX by default - which is equivalent to "less -FRSX".

In git 1.6.4 this appears to be a hard-coded setting.  You could patch git to run less with different arguments - see pager.c
Comment 8 Diggory Hardy 2009-07-30 08:48:40 UTC
Thanks Robert. You appear to have found an answer at roughly the same time as me.

(I found this page: http://rha7dotcom.blogspot.com/2008/07/git-and-less-colors.html
However the git commands are unnecessary and most of the LESS options are either enabled by default anyway on my system (or have no effect) or undesirable.)

Removing the X option (seting LESS="FRS") gives the behaviour I want.
Comment 9 Diggory Hardy 2009-07-31 14:29:01 UTC
Actually it doesn't work very well since output shorter than one screen is immediately hidden.
See: http://article.gmane.org/gmane.comp.version-control.git/124551