-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: selectively enable/disable pagination #2926
Comments
Just to be sure - especially since you say that you want |
This explains so much and removes the friction I've been experiencing with the pager setup based upon the last few minutes of experimenting. I would recommend this to everyone who uses |
Interesting - I didn't realize my Edit: Oh, it's just a nixos default 🙃 Still, better configuration seems valuable even with |
Just setting FYI, @benbrittain said on Discord that he's going to look into setting |
#2928 Nothing complicated, but should be a small UX win |
That doesn't seem to be happening. I've got I do have some random other less environment variables though:
|
Oh, silly me, it worked for me because I had |
I also just ran into this setting up jj for the first time and following the tutorial. Every command I ran would open the pager, which makes it challenging to follow the tutorial since you need to remember the change ids to rebase. Setting |
Our current default for `ui.pager` is this: ```toml ui.pager = { command = ["less", "-FRX"], env = { LESSCHARSET = "utf-8" } } ``` If the user has `$PAGER` set, we take that value and replace the above table by a scalar set to the value from the environment variable. That means that anyone who has set `$PAGER` to just `less` will lose both the `-FRX` and the charset, making e.g. colored output from `jj` result in escaped ANSI codes rendered by `less`. The lack of those options might not matter for other tools they use so they might not have realized that they wanted those options. This patch attempts to improve the situation by changing the default `ui.pager` to pass `-FRX` via `$LESS`, and by setting the value from `$PAGER` in `ui.pager.command`, so the rest of the config is left alone. The default config will still be ignored if you set the scalar `ui.pager` to e.g. `less`, since that overrides the table. Closes #2926
Our current default for `ui.pager` is this: ```toml ui.pager = { command = ["less"], env_default = { LESS = "-FRX", LESSCHARSET = "utf-8" } } ``` If the user has `$PAGER` set, we take that value and replace the above table by a scalar set to the value from the environment variable. That means that anyone who has set `$PAGER` to just `less` will lose both the `-FRX` and the charset, making e.g. colored output from `jj` result in escaped ANSI codes rendered by `less`. The lack of those options might not matter for other tools they use so they might not have realized that they wanted those options. This patch attempts to improve the situation by setting the value from `$PAGER` in `ui.pager.command` so the rest of the config is left alone. The default config will still be ignored if you set the scalar `ui.pager` to e.g. `less`, since that overrides the table. Closes #2926
Our current default for `ui.pager` is this: ```toml ui.pager = { command = ["less"], env_default = { LESS = "-FRX", LESSCHARSET = "utf-8" } } ``` If the user has `$PAGER` set, we take that value and replace the above table by a scalar set to the value from the environment variable. That means that anyone who has set `$PAGER` to just `less` will lose both the `-FRX` and the charset, making e.g. colored output from `jj` result in escaped ANSI codes rendered by `less`. The lack of those options might not matter for other tools they use so they might not have realized that they wanted those options. This patch attempts to improve the situation by setting the value from `$PAGER` in `ui.pager.command` so the rest of the config is left alone. The default config will still be ignored if you set the scalar `ui.pager` to e.g. `less`, since that overrides the table. Closes #2926
The |
Is your feature request related to a problem? Please describe.
The existing pagination config feels insufficient. One can leave
ui.paginate
onauto
, but then you have to pass--no-pager
to every command that you don't want paged every time. Or, you can set it tonever
, which then requires you to invoke every command that you do want paged with--color=always | less -FRX
, since there's no way to turn the pager back on.Even if there was a
--pager
argument to re-enable it when it's globally set tonever
, it would get tedious to have to pass it to every command that you always want paged every time, or awkward to have to use aliases for all of them.The extra-frustrating bit is that all help messages are paginated, which I never want. Even if you pass
--no-pager
, they still get paged unless you haveui.paginate = "never"
. Seems like you have to pipe them tocat
to get the auto-pager to turn off, which seems backwards.My personal preferences:
--pager
argument when I decide it's needed.status
,st
: never paged. This one is so short, or at least should be, that paging doesn't seem worth it. I'm also just used to being able to see previous statuses in my scrollback buffer.log
: Depends on what I'm trying to do. If I'm hunting through history for something, I'll want it paged. If I know what I'm looking for, I probably don't want it paged so that I don't have to do the back-and-forth dance between pager and CLI to copy change IDs.cat
: Why is this paged in the first place? That's not whatcat
does. Never paged.Describe the solution you'd like
A clear and concise description of what you want to happen.
--pager
flag for invertingui.paginate = "never"
. "never" is strictly worse than "auto" without a way to override it the same way that--no-pager
works in "auto" mode.ui.paginate
is set to "auto".ui.paginate = "always"
, mostly for completeness. This is effectively what "auto" means today.Describe alternatives you've considered
Mostly described in the description of the problem.
#2621 and #1509 touch on this issue (#2621 explicitly), but the why-not reasoning in #1509 doesn't really hold for the pagination case. Since it's nonsensical to enable pagination when piping to another command, there's no chance of someone's default pagination settings breaking a script that calls jj to get some command output. The only thing that it could make a little weird is if a script is running jj specifically to present something to the user and expects a specific pagination setting. But in that case, the script should really be calling it with
--(no-)-pager
anyway.The text was updated successfully, but these errors were encountered: