Version 2.39.2 of git for Windows introduces annoying "Waiting for data..." bar at bottom of screen

[kaiyoma]

I initially filed this bug at git-for-windows/git#4289 but the authors there said that this is a less issue, so filing a copy here.

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.39.1.windows.1
cpu: x86_64
built from commit: b03dafd9c26b06c92d509a07ab01b01e6d0d85ee
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 11 64-bit

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.22621.1265]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ 

Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash via Windows Terminal

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git grep

• What did you expect to occur after running these commands?

No weird message

• What actually happened instead?

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

N/A

[gwsw]

A couple of questions: does this message go away eventually or does it remain on screen permanently? It is expected that this line will appear while git is producing output, but it should go away when git is finished. What did you see in the previous version of less in this situation -- was there a colon prompt or just a blank line?

[kaiyoma]

Yes, the message goes away when the command finishes, but in the 7+ years I've been using git for Windows, I have never seen this, until upgrading to the latest version. Previously, this message never appeared and the git grep output was pretty normal.

[gwsw]

This message is a new feature, to inform the user that less is not responsive to commands because it is reading from the input file/pipe, but that it can be interrupted with ctrl-X. In earlier versions, there was no message displayed and less was silently unresponsive while reading data, so this feature is intended to improve that experience. This feature is not yet in any released version, so it sounds like someone has released it early inappropriately, but in any case it will become standard when the next release is done.

[lazka]

Could the displaying of the status message be delayed a bit?

In most cases the user expects the operations to take a bit, and only after some time wonders if the program is still working/responsive. And showing a message in all cases forces them to put their attention to this message, in 95% of the case for no good reason, if they can even read it until it disappears again.

[gwsw]

The message is currently delayed, but only by 10 ms. I can see an argument that it should be longer, maybe 250-500 ms? I will experiment with this. Of course there's no way to avoid the issue that the message may appear only briefly, if data happens to become available very soon after whenever the message is displayed.

[gwsw]

I have increased the delay to 500ms in 690a957 (less-629).

[gwsw]

I've done some usability testing and now believe that the 500ms delay was indeed too short. In 64ab9cc I have increased it to 4000 ms. I also believe that in certain environments the user may wish to tweak this; for example a use case where the user is merely monitoring a file without interacting with it much might want a longer delay than a case where the user is more actively interacting with the file, so I added a new environment variable LESS_DATA_DELAY to let the user set the delay.

[vvatikiotis]

This feature doesn't play well, when using less as an fzf previewer.

Is it possible to disable it?

[gwsw]

I haven't used fzf, but since less assumes it has full control of the screen, it appears that fzf attempts to emulate a screen when it runs less as a previewer. If something works when less runs standalone but doesn't work when fzf runs less inside its emulated screen, it would seem that the problem must be in fzf's screen emulation. However I have not looked into this in any detail.

You can effectively disable the "waiting for data" message by setting LESS_DATA_DELAY to a large number of milliseconds.