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

[jsborjesson]

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]

Note: This is a dupe of #25.

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

[NHDaly]

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]

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]

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

[NHDaly]

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]

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

[jsborjesson]

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]

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]

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]

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]

@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]

@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:

• Git sets -RFX flags by default, so alternate screen mode is not entered and mouse scrolling does not work.
• Setting less flags to -RF does enter alternate screen mode and avoids paging of short outputs but without -X short outputs cannot be read at all since the alternate screen is closed istantly.
• Just setting -R always enters alternate screen; it is usable but poor for few lines.

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!

[keysmashes]

@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:

core.pager = lesser.py:

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?