Enhancement request: option for suppressing prompts

[telychko]

Sometimes prompts are unwanted or annoying.

• Prompt for editing preprocessed file
  WARNING: This file was viewed via LESSOPEN (press RETURN)

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.

• Prompt after shell execution
  !done (press RETURN)

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

• It could be option like in mutt : prompt-after. It suppresses the output of prompts.
• It could be an inline flag e.g. !@cmd' or 'LESSOPEN="|@ suppresses the prompt.

Thank you for making one of the greatest pager.

[gwsw]

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]

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]

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]

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).