NHDaly / tmux-better-mouse-mode

A tmux plugin to better manage and configure the mouse.
MIT License
916 stars 27 forks source link

emulate-scroll-for-no-mouse-alternate-buffer not working for `git log` #27

Open jsborjesson opened 7 years ago

jsborjesson commented 7 years ago

Really nice project! I'm trying to get the emulate-scroll-for-no-mouse-alternate-buffer option to work, and it does for less but not for git log. I tried to understand how it works but I didn't get very far - could you maybe explain how it detects which programs it should send arrow keys to to scroll?

Thanks!

NHDaly commented 7 years ago

Note: This is a dupe of #25.

EDIT: oops, a "dupe", not a "diff." Too much git talk.

NHDaly commented 7 years ago

I'm not sure why it doesn't work for git commands for some users. It works correctly on my computer.

could you maybe explain how it detects which programs it should send arrow keys to to scroll?

That logic can be found here, in this part of the binding: scroll_copy_mode.tmux#L66 (at 4c686e5a1f)

If you enable the flag, it adds a check for "#{alternate_on}". The check on line 66 says "if alternate_on, send_keys_to_tmux_cmd up, else send the mouse scroll like normal."

From man tmux, the variable alternate_on is replaced with true If pane is in alternate screen, and is empty otherwise. In this case, the "alternate screen" it is referring to is how shell programs signal themselves as full-screen programs.

Here's a bit more info about the alternative screen: http://stackoverflow.com/questions/11023929/using-the-alternate-screen-in-a-bash-script

In theory, git log should be an alternate screen program too. So my thoughts are either that A) for some reason your terminal isn't realizing it's in an alternate screen, or B) it is correctly detected, but then the up/down arrow keys aren't the right way to navigate your fullscreen git log?

jsborjesson commented 7 years ago

Thanks for the detailed response! Arrow keys do definitely work to scroll in my git log, I'm running git 2.11.0 and tmux 2.3.

jsborjesson commented 7 years ago

It does indeed seem like alternate_on does not detect git log.

NHDaly commented 7 years ago

Ah, yeah, that makes sense. Thanks for looking into that!

This looks promising!: https://git-scm.com/docs/git-config#git-config-corepager

Can you try echoing those values?:

$ echo $GIT_PAGER
$ git config --get-all core.pager  # I think this is how you check this? For me it's empty...
$ echo $PAGER
$ echo $LESS

For me, the first two are empty, $PAGER is less, and $LESS is -R.

For experimentation purposes, when I set export LESS="", my git log stopped showing colors, and instead showed the literal escape sequence, ESC[33mcommit 875d8.... When I set export PAGER="", too, it just echo's the whole git log instead of opening it interactively.

So I'm thinking maybe there's some combination of your settings that are causing it to not enter the alternate pane?

NHDaly commented 7 years ago

You might also check git config --get pager.log, also empty for me.

jsborjesson commented 7 years ago

Adding this solves the issue

export LESS='-R'

It also has some other side effects unfortunately, now git log always goes into interactive mode even if it's not longer than one screen, I'd prefer it to only invoke less when it's needed. I'll poke around more with these settings and see if I can fix that. Thanks!

gmvi commented 7 years ago

Yeah that works for me too, and I'm seeing those same side-effects. I want to add -F to get back the old behavior, but that doesn't play well with -R...

NHDaly commented 7 years ago

Oh awesome, I'm glad to hear it! :)

Yeah I'm not sure what the right settings are either, but I'm glad we found the root of your problem! Please do post back here if you find some combination that works for you! :)

Yeah that works for me too, and I'm seeing those same side-effects. I want to add -F to get back the old behavior, but that doesn't play well with -R...

How do you mean? I tried setting export LESS="-R -F" and it seems to be working correctly for me. Although I'm surprised -R was enough to change the behavior for both of you, since for me at least -R only seems to control how it displays colors. I get the "alternate screen" paging effect whether I set LESS to -R, "-R -F", -F, or "".

From my man page (less 458 (POSIX regular expressions), macOS 10.11.6):

       -r or --raw-control-chars
              Causes  "raw"  control  characters  to be displayed.  The default is to display control characters using the caret notation; for
              example, a control-A (octal 001) is displayed as "^A".  Warning: when the -r option is used,  less  cannot  keep  track  of  the
              actual  appearance of the screen (since this depends on how the screen responds to each type of control character).  Thus, vari-
              ous display problems may result, such as long lines being split in the wrong place.

       -R or --RAW-CONTROL-CHARS
              Like -r, but only ANSI "color" escape sequences are output in "raw" form.  Unlike -r, the screen appearance is  maintained  cor-
              rectly in most cases.  ANSI "color" escape sequences are sequences of the form:

                   ESC [ ... m

              where the "..." is zero or more color specification characters For the purpose of keeping track of screen appearance, ANSI color
              escape sequences are assumed to not move the cursor.  You can make less think that characters other than "m" can end ANSI  color
              escape  sequences  by  setting  the environment variable LESSANSIENDCHARS to the list of characters which can end a color escape
              sequence.  And you can make less think that characters other than the standard ones may appear between the ESC and the m by set-
              ting the environment variable LESSANSIMIDCHARS to the list of characters which can appear.

So I wonder why it is sufficient to make your less start paging with the alternate buffer! Weird..

IngoMeyer441 commented 7 years ago

Hey, I had the same problems and it seems that git invokes -X on less which skips some initializiation steps (man page):

       -X or --no-init
              Disables sending the termcap initialization and deinitialization strings to the terminal.  This is sometimes  desirable  if  the
              deinitialization string does something unnecessary, like clearing the screen.

-X can be used in combination with -F to avoid entering alternate screen mode if the whole file can be printed without scrolling the terminal but it of course prevents alternate screen detection. So, call less without -X and everything works as expected. :)

jsborjesson commented 7 years ago

@IngoHeimbach how do you do that? I already have a core.pager set that uses less without the -X flag actually, but maybe you are referring to something different?

IngoMeyer441 commented 7 years ago

@alcesleo Git sets the LESS environment variable if it is unset to pass additional options; one of these options is the -X flag (see https://git-scm.com/docs/git-config#git-config-corepager). What you can do, is setting LESS to -R for example or set core.pager to less -+X to avoid the -X flag, regardless what is set by the LESS variable. That should do the trick for you.


I did some tests and found out that it is not possible to get the default git paging behavior (short outputs are not paged at all) and working tmux scrolling at the same time:

As a workaround I have created a small python script that detects if the output fits into one terminal page. If it fits, the output is simply written to stdout. Otherwise less -R is called. Just set core.pager or PAGER to lesser.py and it should work as expected. Hope that helps!

sersorrel commented 6 years ago

@IngoHeimbach That script works almost perfectly, thank you! The only problem I have with it is that some colours appear to be different than normal when the output is less than a page long.

core.pager = less:

image

core.pager = lesser.py:

image

As you can see, git commit hashes seem to be less bright after the first line when using lesser.py – any idea why this might be?

IngoMeyer441 commented 6 years ago

@anowlcalledjosh Sorry, at the moment I have no clue why the colors are different when using lesser. I cannot reproduce that issue on my system. :(

dylan-chong commented 6 years ago

Just a note for diff so fancy users, I set my Git pager to this:

git config --global core.pager "diff-so-fancy | less --tabs=4 -+F -+X

Whereas I was using this initially (as per the readme on diff so fancy):

git config --global core.pager "diff-so-fancy | less --tabs=4 -RFX"

the only problem is that if git show, for example, outputs shorter than a page, less will still open. This is not too much of a problem for me, so this problem is worth it for having mouse scrolling

artem-nefedov commented 5 years ago

I'm just wondering, is there any way to allow workability for mouse scroll AND avoid entering alternate screen in less?

goodevilgenius commented 4 years ago

I have this same issue. I checked, and git log is sending its own output to less. I can see it in ps auxf as a child process of git log.

Doing less file works. Also doing command | less works. But if a command, such as git log or bat calls less as a child process, then scrolling no longer works. Is there some environment variable I need to set to get this to work?

IngoMeyer441 commented 4 years ago

You can try to set

export LESS="-R" 
goodevilgenius commented 4 years ago

@IngoHeimbach This works perfect for git log (although -RF was better). It doesn't work for bat, unfortunately. I noticed in ps that bat calls less as less --RAW-CONTROL-CHARS --no-init --quit-if-one-screen.

Sounds like that's an issue with bat, though. It sounds like, from the man page for less, that --no-init disables the alternate screen entirely.


P.S. But, it looks like bat works with a customer pager, by setting BAT_PAGER, which I set to less -RF, and it works now.

Thanks for the help!

NHDaly commented 4 years ago

Hi friends! :)

I just want to say that I haven't been keeping up to date with the latest tmux in a long time. My setup mostly works, and I haven't had the time to maintain this package.

Would any of you active users be interested in joining maintenance of this package? If so, please let me know, either via an email or a comment here: https://github.com/NHDaly/tmux-better-mouse-mode/issues/41 :) Thanks everyone for your collaboration on making tmux more user-friendly! :)