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

[ntninja]

No description provided.

[ShayanAhmad]

looks good to me.

[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 romkatv/powerlevel10k#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?

[JamesWidman]

+1 to @LucasLarson; no_unset is useful in interactive mode, and not just because it catches errors in functions: a parameter name can be typo'd (or erroneously unset) on the command prompt just the same as a parameter name in a script, and no_unset will prevent such an erroneous command on the prompt from being run. That's a very good thing if the erroneous command would produce irreversible effects or just consume a lot of time!

and for people who use unset in interactive mode, this PR does no harm.

there's now at least 4 different users who want this. Is there any reason not to merge?