Re: Disabling null elision (was: Re: Most Recent File)

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Roman Perepelitsa wrote on Mon, 25 Oct 2021 20:02 +00:00:
> I would be 99% satisfied with step 1. I would be less satisfied if
> step 2 was implemented because I hate when my scripts break. Granted,
> even step 1 will break "plugins" that attempt to work with any options
> but at least it won't break executable scripts.

In addition to these two categories, there's also plugins that set
non-default options explicitly for their own use, and users who do
that in their zshrc's and then post usage questions that don't start
with a «zsh -f».

> It's also nice that this option would affect parsing, only evaluation,
> so it won't be necessary to care about it when defining functions.

How so?  If a function f is written under the assumption null elision is
disabled, but is run with null elision enabled, then it would silently
do the wrong thing, rather than, say, error out.

I don't see why a function's caller should decide whether the callee
should or shouldn't elide nulls.  I think the function's author should
make that decision.

> I do get your point about the difficulty of reading plugins when you
> have to keep in mind all possible options that the code can be
> evaluated with (how many plugins work with no_glob? mine don't).

Writing plugins that are meant to be sourced by others is a pain, not
only because of options but also because of aliases.  Having some
way to provide packaged code to others in a way that the code will
run under predictable syntax would be nice… but that's yet another
thread.  (E.g., perhaps the new behaviour should be triggered by magic
bytes at the top of the sourced file.  Or perhaps we should start
adding some directory under ~ to the default fpath, e.g., ~/.local/share/zsh
[plus or minus XDG base dirs support])

> I still think it's worth it to have *this* option. Dropping all those
> quotes would remove noise from code and make comprehension easier. I
> realise that few users would benefit from this. Not many write zsh
> scripts to begin with and a small number of those would enable a new
> option.

Yeah.  I assume that if we make this change, then once the
incompatibility wave is past us (i.e., once everyone has made their code
Y2k compliant, so to speak), the resulting language would be more
intuitive — just like it's more intuitive with NO_SH_WORD_SPLIT than
with sh's word splitting behaviour.

Well, why not push an implementation to a branch?  If you've got the
tuits, of course.

Cheers,

Daniel