help / color / mirror / code / Atom feed
From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: zsh-users@zsh.org
Subject: Re: Disabling null elision (was: Re: Most Recent File)
Date: Mon, 25 Oct 2021 20:41:07 +0000	[thread overview]
Message-ID: <048e0b3d-6da9-4905-b1ad-253647cea0d3@www.fastmail.com> (raw)
In-Reply-To: <CAN=4vMpZbLxe4navMTjRaKxogemJqnqcre6NuK3v8V6xVgCzRg@mail.gmail.com>

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.



  reply	other threads:[~2021-10-25 20:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-23 16:15 Most Recent File Vin Shelton
2021-10-23 16:43 ` Dominik Vogt
2021-10-23 16:58   ` Peter Stephenson
2021-10-23 17:24     ` Dominik Vogt
2021-10-23 17:32       ` Peter Stephenson
2021-10-23 18:39         ` Bart Schaefer
2021-10-23 19:07         ` Vin Shelton
2021-10-23 19:26           ` Bart Schaefer
2021-10-23 20:43             ` Vin Shelton
2021-10-23 20:56               ` Pier Paolo Grassi
2021-10-23 22:42                 ` Bart Schaefer
2021-10-24  0:24                   ` Pier Paolo Grassi
2021-10-24  0:32                     ` Paul
2021-10-24  1:45                       ` Dominik Vogt
2021-10-24  7:22                         ` Roman Perepelitsa
2021-10-25 19:45                           ` Disabling null elision (was: Re: Most Recent File) Daniel Shahaf
2021-10-25 20:02                             ` Roman Perepelitsa
2021-10-25 20:41                               ` Daniel Shahaf [this message]
2021-10-25 21:00                                 ` Ray Andrews
2021-10-25 21:09                                   ` Bart Schaefer
2021-10-25 21:05                                 ` Bart Schaefer
2021-10-25 21:20                                 ` Roman Perepelitsa
2021-10-25 20:05                             ` Bart Schaefer
2021-10-24  1:37                     ` Most Recent File Dominik Vogt
2021-10-23 16:47 ` david rayner
2021-10-23 16:54   ` Vin Shelton
2021-10-23 16:51 ` david rayner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=048e0b3d-6da9-4905-b1ad-253647cea0d3@www.fastmail.com \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-users@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).