From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: zsh function breaks after error
Date: Fri, 11 Feb 2022 07:59:52 -0800 [thread overview]
Message-ID: <aa008389-b294-ff33-05e6-7e174a157f4b@eastlink.ca> (raw)
In-Reply-To: <chtc0htcb245f0s1hvm0lrst8rc63rhcfq@tlc.com>
On 2022-02-11 06:58, Thomas Lauer wrote:
>
> But I agree that the density of the documentation can be a problem,
> especially for people who are no developers and are perhaps not used to
> dense docs :-)
You can say that again. It gets easier with exposure of course, but
even now I'd
say that zsh/unix/linux docs -- especially the old 'man pages' are often
spectacularly badly written. 'Dense' might be a charitable way of
putting it.
> I'm a Windows refugee as well but over there I've used a command
> processor called Take Command (the former 4NT)
4DOS and Take Command ruined me. I got to just taking for granted that
level of
polished perfection and when I moved over here, the culture shock
nearly killed me.
> but with judicious use
> of Google, Stackexchange, Reddit etc etc and a lot of trial and error
>
Yeah, resources are out there if you just beat the bushes long enough.
Like Daniel's
link above. But how about if it were all collated and condensed and
brought in-house?
> This would certainly help but many things zsh are interconnected in a
way that means that you have to understand something in order to
understand something else... but to understand the first thing you have
to understand the second
Heck yes, which is why layering is a good idea. The newbie's
'introduction to zsh config' won't even attempt to tell you everything,
it will merely get you to 90% of what might be your eventual, expert
configuration, but hold you by the hand and get you there painlessly.
90% of what you want in 10% of the time it would otherwise have taken.
Advanced wizards can devote years of study to mastering the remaining
10%.
A sample line might have this sort of feel:
HISTSIZE=SAVEHIST=20000 #Trust us, you want a big history recall
buffer. If your machine is pathetically short of resources make it
smaller.
next prev parent reply other threads:[~2022-02-11 16:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 17:16 Thomas Lauer
2022-02-09 15:18 ` Bart Schaefer
2022-02-09 18:45 ` Thomas Lauer
2022-02-09 20:16 ` Bart Schaefer
2022-02-10 13:55 ` Thomas Lauer
2022-02-10 13:59 ` Roman Perepelitsa
2022-02-10 16:20 ` Thomas Lauer
2022-02-10 16:48 ` Roman Perepelitsa
2022-02-10 17:20 ` Thomas Lauer
2022-02-10 21:26 ` Ray Andrews
2022-02-10 21:45 ` Thomas Paulsen
2022-02-10 23:37 ` Daniel Shahaf
2022-02-11 15:07 ` Thomas Lauer
2022-02-11 14:58 ` Thomas Lauer
2022-02-11 15:59 ` Ray Andrews [this message]
2022-02-11 23:31 ` Bart Schaefer
2022-02-12 3:39 ` Ray Andrews
2022-02-22 3:58 ` Matthew Martin
2022-02-12 16:45 ` Thomas Lauer
2022-02-12 17:48 ` Ray Andrews
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=aa008389-b294-ff33-05e6-7e174a157f4b@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=zsh-users@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).