zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [PATCH] Clarify documentation of parameter-assignment behaviour
Date: Wed, 17 Oct 2018 15:26:38 -0700	[thread overview]
Message-ID: <CAH+w=7bMSu3_G0gtjQoXrMc_HMFQgrJc79Ms7gadd-MsPzvHrg@mail.gmail.com> (raw)
In-Reply-To: <CB42153D-E0FA-4EA4-BB41-85E83EB5CF89@dana.is>

We need to come to some sort of decision on what we're accomplishing
in the zsh doc.

Historical context:  Zsh was originally conceived as a way to migrate
csh (later tcsh) users to a shell with a more well-defined syntax
based on Bourne shell syntax.  So originally the documentation assumed
you knew how to use csh and the doc was mostly concerned with how zsh
differed from that, not how shells work in general.  Then it began to
pick up features derived from reading the ksh documentation (because
ksh itself was still closed-source and not freely available) so those
had to be explained, too.  Then as people began to migrate to zsh from
bash and ksh, the doc had to explain how zsh differed from those
(which revealed a whole lot of mis-interpretation of the ksh doc when
trying to copy ksh functionality).  Through all of this the underlying
assumption was the reader had some shell background, and the zsh doc
only had to explain how zsh was special.

Now we're getting people who complain that the zsh doc doesn't cover
all that previously-assumed background.  As Peter said, "One of our
big problems is people finding the existing documentation too thick to
get through.  We can go on making it wordier and harder to get through
till the cows come home and it still won't make it a basic shell
primer."

Splitting doesn't happen on scalar assignment in any shell.  It would
break the prefix-assignment syntax (var=$value command args...) among
other things.  So this isn't a way in which zsh differs.

There's little point in not applying this patch now that it's written,
but it's philosophically similar to Sebastian's code patch that
optimizes something the compiler ought to be able to optimize, and
we're going to be up to our rafters in cows if we don't start leaving
some of them out in the pasture.

  reply	other threads:[~2018-10-17 22:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17 20:37 dana
2018-10-17 22:26 ` Bart Schaefer [this message]
2018-10-17 22:56   ` dana
2018-10-17 23:29     ` Bart Schaefer

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 \
    --in-reply-to='CAH+w=7bMSu3_G0gtjQoXrMc_HMFQgrJc79Ms7gadd-MsPzvHrg@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /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
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

	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).