POSTDISPLAY: parameter not set

[mjsteinbaugh]

Describe the bug

I'm a long time zsh-autosuggestions user, but I'm seeing this error pop up in my shell interactively now:

_zsh_autosuggest_highlight_apply:3: POSTDISPLAY: parameter not set

To Reproduce

Steps to reproduce the behavior:

I'm using my koopa bootloader:

• https://koopa.acidgenomics.com/
• https://github.com/acidgenomics/koopa

Any advice on how to debug this? I'm working through my scripts using the recommended zsh -df approach, sourcing the plugin manually, then adding back my scripts on top.

% zsh -df
% source "${ZSH_PLUGINS_DIR}/zsh-autosuggestions/zsh-autosuggestions.zsh"

[mjsteinbaugh]

Relevant source files:

• https://github.com/acidgenomics/koopa/blob/master/system/activate/shell/zsh/plugins.zsh
• https://github.com/acidgenomics/koopa/blob/master/activate

[ericfreese]

The only thing I can think of off the top of my head that would cause POSTDISPLAY to be not set would be if _zsh_autosuggest_highlight_apply is somehow called outside of a widget context. Do you have any code calling any _zsh_autosuggest_* functions directly?

[mjsteinbaugh]

Not currently calling any _zsh_autosuggest_* functions directly. Also to clarify, I'm not using a manager such as oh-my-zsh or prezto in my current config. I'll plug away turning off the scripts that get called before this step one-by-one and see if I can traceback the source of the error. Just figured I'd ask here first in case people have run into this previously. Thanks!

[mjsteinbaugh]

Sourcing the plugin inside a shell called via zsh -df works, so it's definitely something in my shell config. I'll post an update here when I figure it out, in case it's generally useful to the community.

[mjsteinbaugh]

OK I think I figured it out. I had a stray set +u in my config, so I think the error is due to ZSH expecting POSTDISPLAY to be set, and it is unbound during a step in the plugin call.

[JamesWidman]

Can we re-open this? I recently learned about the UNSET option, and the helpful diagnostics that are issued when UNSET is disabled (either with set -u or setopt NO_UNSET).

Julia Evans gives a great example that shows why you might want to keep UNSET disabled (i.e. why you'd want to use NO_UNSET a.k.a set -u):

rm -rf $HOME/$SOMEPTH

This spells disaster if UNSET is enabled and SOMEPTH is not set. But if UNSET is disabled, then the rm command is not executed, and we see this helpful error message:

zsh: SOMEPTH: parameter not set

@mjsteinbaugh mentions a use of set +u, but that should have produced the default behavior—i.e., silent expansion either to zero or to an empty string; his config file probably contained an instance of set -u instead. With set -u, I see the error message "POSTDISPLAY: parameter not set" once for each key-press at an interactive prompt.

It would be helpful if we could prevent this error while UNSET is disabled! (And likewise for the other error-halting options, -e and -o pipefail)

Scripts/functions that intentionally depend on UNSET could be modified to use one of the other forms of parameter expansion that explicitly account for the case where the parameter is unset. For example, regardless of whether UNSET is enabled, ${#POSTDISPLAY:-} produces the same result as $#POSTDISPLAY-with-UNSET (i.e. it expands to 0 without error).

Alternatively, you can check whether it's set with if [[ -v POSTDISPLAY ]].

[update: i see that this has already been addressed in #713]

[mjsteinbaugh]

Correct, typo on my end! I meant set -u above