Fix plugin for shells with `no_unset` (aka `set -u`) and `ksh_arrays` shell options set

[REALERvolker1]

Just going to comment on this: set -u is useful in interactive contexts, and it would be nice to have it in autosuggestions.

[z0rc]

set -u isn't useful in any way in interactive shell, see discussion at https://github.com/romkatv/powerlevel10k/issues/2652.

[LucasLarson]

set -u isn't useful in any way in interactive shell

is incorrect and the latest message in romkatv/powerlevel10k #2652 is incorrect. When you source a function like this:

$ cat ./foo && . ./foo
break_nounset() {
  printf 'foo%s\n' "${this_variable_does_not_exist}"
}

it returns different results based on user settings

$ set -u && break_nounset
break_nounset:1: this_variable_does_not_exist: parameter not set
$ set +u && break_nounset
foo

Having set -u in an interactive shell is invaluable while dogfooding works in progress.

[z0rc]

That's the whole point. nounset is useful in script and isn't useful in interactive session. If you decided that that nounset must be enabled during interactive session for some deliberate reason, it's on you to deal with consequences.

I must emphasize, zsh-autosuggestions is designed to run in interactive session, it's expected to have sane defaults in interactive session, set -u isn't part of said defaults.

[LucasLarson]

I must emphasize, zsh-autosuggestions is designed to run in interactive session, it's expected to have sane defaults

It appears that much of the codebase does allow for a user to work with it interactively, even if set -o nounset/set -u/setopt nounset is activated. In 2019, for example, the codebase was modified so that users with set -o sh_word_split/set -y/setopt sh_word_split in their interactive shell can keep easy access (4cd210b70d).

I see plenty of benefit in publishing changes that would allow this plugin to degrade gracefully and work for users coming with various options set.

What’s the benefit of preventing this merge?