From: "Daniel Shahaf" <email@example.com> To: firstname.lastname@example.org Subject: Re: Disabling null elision (was: Re: Most Recent File) Date: Mon, 25 Oct 2021 20:41:07 +0000 [thread overview] Message-ID: <email@example.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. Cheers, Daniel
next prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Disabling null elision (was: Re: Most Recent File)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.vuxu.org/mirror/zsh/ 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).