search

gwsw / less

Less - text pager
http://greenwoodsoftware.com/less
Other
561 stars 88 forks source link

Enhancement request: option for suppressing prompts #513

Open telychko opened 5 months ago

telychko commented 5 months ago

Sometimes prompts are unwanted or annoying.

If the less configured as following LESSOPEN="| source-highlight --out-format=esc --input=%s 2> /dev/null" less filename.c

So, every time I try to edit a file via visual command, I get this prompt.

In general, it's a good idea to keep the screen after a command execution to give user an opportunity to read the command output. But, it's annoying when shell command is a interactive command like another instance of less. Of course, it's actual only if lesskey configured to execute such commands.

Suggestions

Thank you for making one of the greatest pager.

gwsw commented 5 months ago

In the second case, the ^P flag already exists to suppress the !done prompt. See #462. I will look into doing something about the first case.

avih commented 5 months ago

In the second case, the ^P flag already exists to suppress the !done

Maybe the default could be to suppress the message only if the exit code is 0? (and one could change it to always suppress or always show).

As for the LESSOPEN one, maybe the default could be to warn only if the file would be considered binary if less itself would have opened it? so for instance it wouldn't (typically) warn for a C file, but would warn with a gzip file?

Though I'd think such default change should wait till after the release.

gwsw commented 5 months ago

Maybe the default could be to suppress the message only if the exit code is 0?

Maybe I'm misunderstanding, but I don't think that would be feasible. If the user types

!ls

by default they would want to see the output of ls even if the exit code is zero.

avih commented 5 months ago

I don't think that would be feasible.

I'm guessing you mean it won't be useful?

And yes, that's what I meant, but indeed for this use case where the user is interested in observing the output of the command, then indeed it would not be useful to suppress the pause on success.

Apologies for not thinking it through enough (I don't use this feature).