setopt interactivecomments

setopt interactivecomments

[shawn wilson]

Why is this feature disabled by default - it seems like enabling and
allowing it to be disabled (since the behavior works in other shells)
would be the correct way to do things?

Re: setopt interactivecomments

[Bart Schaefer]

On Apr 16, 10:35am, shawn wilson wrote:
}
} Why is this feature disabled by default - it seems like enabling and
} allowing it to be disabled (since the behavior works in other shells)
} would be the correct way to do things?

It's disabled because it always has been, and therefore enabling it might
break longstanding usage.

It has always been disabled because zsh originated as a way to bring
Bourne shell syntax to students who had been introduced to BSD Unix
via [t]csh, and csh does not have interactive comments.  A lot of the
default behaviors and interactive design of zsh derive from Paul Falstad
(the original author) making subjective judgements about what were the
best features of csh and sh, rather than about what features were the
most common in other sh clones.

Re: setopt interactivecomments

[shawn wilson]

On Wed, Apr 16, 2014 at 1:27 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Apr 16, 10:35am, shawn wilson wrote:
> }
> } Why is this feature disabled by default - it seems like enabling and
> } allowing it to be disabled (since the behavior works in other shells)
> } would be the correct way to do things?
>
> It's disabled because it always has been, and therefore enabling it might
> break longstanding usage.
>
> It has always been disabled because zsh originated as a way to bring
> Bourne shell syntax to students who had been introduced to BSD Unix
> via [t]csh, and csh does not have interactive comments.  A lot of the
> default behaviors and interactive design of zsh derive from Paul Falstad
> (the original author) making subjective judgements about what were the
> best features of csh and sh, rather than about what features were the
> most common in other sh clones.

So if I want to know what ideas are based on, I should refer to how
FBSD tcsh and sh behave and not how Bash on Linux functions? Or as far
as this type of thing is concerned, it would stay either way because
it was an original implementation decision? (obviously, because of the
former, the later becomes moot, but I'm curious what the current
mindset of development is)

Re: setopt interactivecomments

[Ray Andrews]

On 04/16/2014 10:37 AM, shawn wilson wrote:
>
> It's disabled because it always has been, and therefore enabling it might
> break longstanding usage.
> ...
>
My adoption of Linux was set back about ten years by this sort of 
thinking.  The first time I ever succeeded in get a Linux to boot 
(Slackware I think it was in the mid 90's) I'm at a command line with no 
command recall, no nuthin' really, and even the bleeding backspace key 
does not work.  I'm expected to work with that.  "This is Linux?" I asks 
myself after a few hours of suffering, and run back to DOS, where I had 
become accustomed to the sweet, sublime perfection of the 4DOS shell.  
When I tried Linux again, I had benefit of some friends who explained to 
me that it was 'nix tradition that things be made as difficult as 
possible for the beginner, and that the shells especially, as they come 
out of the box, are particularly sadistically crippled, and 
*deliberately* so.

It was shown to me how to get the backspace key working and how to get 
the shell at least functioning up to half the level of command.com in 
DOS. Of course after some of the obligatory purgatory of getting to know 
a few things I now know that the shells (particularly zsh) have an 
almost unbelievable power if you get the incantations right.  (Tho  I 
think 4DOS spoiled me forever with it's combination of power, 
simplicity, consistency, transparency and intuitiveness. Learning new 
things in 4DOS was so easy that you could almost do it in your sleep, 
that's why I'm always bitchin' now ;-)

It was longstanding usage that we write with goose quill on parchment.  
Let's forget about longstanding usage, break with all tradition, and 
have zsh, as she comes out of the box, show folks what she can do.  
Let's enable all the stuff that almost everyone is almost sure to want 
anyway.  Let's even be so bold as to have the backspace key working by 
default!  Of course there should always be a 'longstanding usage' 
version for folks who still use a VT100 and teletype connected to a 
steam powered mainframe, but for the rest of us, I'd say the backspace 
key is here to stay.

Re: setopt interactivecomments

[Bart Schaefer]

On Apr 16,  1:37pm, shawn wilson wrote:
}
} So if I want to know what ideas are based on, I should refer to how
} FBSD tcsh and sh behave and not how Bash on Linux functions?

Zsh's been around for 20-ish years now, so the answer may depend upon
how long ago the feature was implemented.  In general, though, if you
find something that appears to be fundamentally different from the
way bash/ksh work, you should look to see if it instead mimics some
similar feature in tcsh.  Otherwise the reason is probably that zsh
invented it either first or in parallel and different choices were made
by the different developer teams.

} Or as far as this type of thing is concerned, it would stay either way
} because it was an original implementation decision?

That's not quite accurate.  Zsh has a number of "emulation modes" and
(to use the specific example in this thread) you'll find that if you
use "sh" emulation then interactivecomments is the default behavior.
If an emulation mode is found to diverge from its model, we'll make
reasonable efforts to bring it in line.  Sometimes (e.g. ksh namerefs)
that's difficult because of fundamental differences in the way certain
underlying functionality is implemented, but we'll do what we can.

Too bad Peter says he's gone quiet for a week, as I'd like his take on
this, but from my perspective:

In native mode, things that are obviously buggy will be changed, but
otherwise the criteria applied is along the lines of "what fraction
of existing real-world zsh init files / scripts / user idioms are
likely to break if we change this default?" compared with "how badly
does this inconvenience a newbie who's expecting something else?"  If
the (admittedly somewhat subjective) old-pain/new-pain ratio is too
high, the default will stay the way it is.

Re: setopt interactivecomments

[Bart Schaefer]

On Apr 17,  7:37am, Ray Andrews wrote:
} Subject: Re: setopt interactivecomments
}
} On 04/16/2014 10:37 AM, shawn wilson wrote:
} >
} > It's disabled because it always has been, and therefore enabling it
} > might break longstanding usage.
} > ...
}
} My adoption of Linux was set back about ten years by this sort of 
} thinking.

Well, *my* adoption of Linux is continually frustrated by exactly the
opposite thinking, to wit, that every new release of something has to
be based on the bloodiest edge and can disregard whatever came before.
Oh, look, a new version of jellymaker is out -- but the API is entirely
different, so I'll have to try to find new versions of everything that
uses it, and it requires the latest libsnozzberry which also has a new
API, so I'll also have to try to replace everything else that depends
on *that*, etc. etc. etc.

Thanks, but no.

} It was longstanding usage that we write with goose quill on parchment.  
} Let's forget about longstanding usage, break with all tradition, and 
} have zsh, as she comes out of the box, show folks what she can do.  

We [*] did try that back in around, oh, 1996 IIRC.  It was a mess.  It
turns out that if turn on ALL the cool features by default, the result
is even more confusing than having your backspace key not work.

What did eventually happen after the mess was cleaned up is that the
zsh-newuser-install system got created.  It could use an update, but
is intended to walk you through enabling the stuff that you're most
likely to want.

[*] I use the term "we" loosely because I personally quit working on zsh
for a couple of years until sanity had been restored.

Re: setopt interactivecomments

[Ray Andrews]

On 04/17/2014 12:37 PM, Bart Schaefer wrote:

Bart:
> Well, *my* adoption of Linux is continually frustrated by exactly the
> opposite thinking, to wit, that every new release of something has to
> be based on the bloodiest edge and can disregard whatever came before.
Yup. There's that problem too.  This is by no means a simple issue and 
all perils considered, I quite
understand that things default to your way of thinking.
> Oh, look, a new version of jellymaker is out -- but the API is entirely
> different, so I'll have to try to find new versions of everything that
> uses it, and it requires the latest libsnozzberry which also has a new
> API, so I'll also have to try to replace everything else that depends
> on *that*, etc. etc. etc.
>
> Thanks, but no.
I hate that sort of thing too.  It's a question of separating the wheat 
from the chafe tho,
is it not?  On the one hand we have the kiddies with their half cooked 
'new' versions of
Jellymaker changing things willy-nilly, OTOH we have, in my opinion, a 
slightly too
conservative view with the shells. Excesses in one direction are not a 
good reason to
avoid sober changes in the other direction.
>
> } It was longstanding usage that we write with goose quill on parchment.
> } Let's forget about longstanding usage, break with all tradition, and
> } have zsh, as she comes out of the box, show folks what she can do.
>
> We [*] did try that back in around, oh, 1996 IIRC.  It was a mess.  It
> turns out that if turn on ALL the cool features by default, the result
> is even more confusing than having your backspace key not work.
Sure, efforts in this direction are dangerous, and I'd not suggest (even 
with my lack of
experience) that ALL of *anything* be turned on by default, but sheesh, 
can't we have
the backspace key by default? I'm sure there must be dozens of 'no risk' 
options that
virtually everyone wants and that come with no gottchas.  Me, I'm still 
so overwhelmed
by all the options that I don't even know what 90% of them do, and I'm 
probably missing
out on good stuff that I don't even know exists. If there was an option 
of having a
more souped up install, it might be educational to play with.
>
> What did eventually happen after the mess was cleaned up is that the
> zsh-newuser-install system got created.  It could use an update, but
> is intended to walk you through enabling the stuff that you're most
> likely to want.
Sounds exactly right. I seem to have missed it.
>
> [*] I use the term "we" loosely because I personally quit working on zsh
> for a couple of years until sanity had been restored.
Well, sanity matters. I take a rather conservative view  on most things 
myself, but at the
same time, I think a few things are now so bedrock standard that we can 
safely part with
the traditions of 20 years ago on some issues. What, really, would break 
if the backspace
was enabled by default? What would break if interactive comments was on 
by default? Who
would complain? Does anyone on Earth really not want command recall?

Re: setopt interactivecomments

[shawn wilson]

On Thu, Apr 17, 2014 at 5:36 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 04/17/2014 12:37 PM, Bart Schaefer wrote:
>

>>
>> What did eventually happen after the mess was cleaned up is that the
>> zsh-newuser-install system got created.  It could use an update, but
>> is intended to walk you through enabling the stuff that you're most
>> likely to want.
>
> Sounds exactly right. I seem to have missed it.
>

I think that's reasonable - it's been a while since I've generated a new config.

>>
>> [*] I use the term "we" loosely because I personally quit working on zsh
>> for a couple of years until sanity had been restored.
>
> Well, sanity matters. I take a rather conservative view  on most things
> myself, but at the
> same time, I think a few things are now so bedrock standard that we can
> safely part with
> the traditions of 20 years ago on some issues. What, really, would break if
> the backspace
> was enabled by default? What would break if interactive comments was on by
> default? Who
> would complain? Does anyone on Earth really not want command recall?
>

I kinda like nothing being enabled except in config - package sane
configs to be /etc/zsh/* (or /usr/local/etc/zsh/ on BSD I suppose) and
the new-user script sounds like the right way. This is only the second
time something has seemed weird (or from what I wouldn't expect) in
zsh (the other being how arrays are expanded - as arrays are broken or
near enough to broken in bash, I have no complaints about any
improvements zsh makes with them).

As for this (and other 'features') I suppose I'd expect package
maintainers in Linux to make it as close to what you'd get in bash as
possible and the core package to come with configs to get as close to
what sh does by default.

Re: setopt interactivecomments

[Bart Schaefer]

On Apr 17,  2:36pm, Ray Andrews wrote:
}
} > zsh-newuser-install system got created.  It could use an update, but
} > is intended to walk you through enabling the stuff that you're most
} > likely to want.
} Sounds exactly right. I seem to have missed it.

It has to be in place as part of the new user home directoy skeleton to
to happen automatically, so it often isn't present, but it can be found
in Functions/Newuser/zsh-newuser-install in the zsh distribution.


} I think a few things are now so bedrock standard that we can safely
} part with the traditions of 20 years ago on some issues. What, really,
} would break if the backspace was enabled by default?

I'm a bit confused by why you keep bringing this up.  Zsh defaults to
binding both ctrl+h (backspace) and ctrl+? (del) to backward-delete-char
and has forever.  The only odd one out is when the DEL key sends some
multi-character escape sequence.

In fact more often than not for me backspace works just fine in zsh but
is messed up in other programs like vim.  That's not a shell problem,
it's a tty-driver problem.

Unless you're using zsh in vi-mode, that is, in which case ctrl+? is
not bound, but that's your own problem because vi-mode isn't the zsh
default in the first place.

} What would break if interactive comments was on by default?

I don't know how prevalent this still is, but a number of programs used
file names with # in them for backups.  It becomes one more thing you
have to quote.

Note that I'm not particularly arguing against this specific option;
this whole thread started by asking "Why" and comparing to "other
shells" -- I'm merely answering the why and pointing out that there
*IS* another shell that does not have interactive comments.

} Does anyone on Earth really not want command recall?

Not sure where that's coming from either, because basic history motions
are on by default as well.  If you're going to make straw men, at least
make them vaguely humanoid ...

Re: setopt interactivecomments

[Bart Schaefer]

On Apr 17,  6:07pm, shawn wilson wrote:
}
} As for this (and other 'features') I suppose I'd expect package
} maintainers in Linux to make it as close to what you'd get in bash as
} possible and the core package to come with configs to get as close to
} what sh does by default.

How does that make sense?  If you want "as close to what sh does by
default" just *use bash*, don't reconfigure things that aren't bash.

Unless for some reason you can't install bash, which is why zsh behaves
differently if you name it "sh" instead, so you don't have to worry
about otherwise mucking its configuration to make it bash-like.

Re: setopt interactivecomments

[shawn wilson]

On Thu, Apr 17, 2014 at 6:48 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Apr 17,  6:07pm, shawn wilson wrote:
> }
> } As for this (and other 'features') I suppose I'd expect package
> } maintainers in Linux to make it as close to what you'd get in bash as
> } possible and the core package to come with configs to get as close to
> } what sh does by default.
>
> How does that make sense?  If you want "as close to what sh does by
> default" just *use bash*, don't reconfigure things that aren't bash.
>
> Unless for some reason you can't install bash, which is why zsh behaves
> differently if you name it "sh" instead, so you don't have to worry
> about otherwise mucking its configuration to make it bash-like.

I use zsh because of the zle stuff and (much better) completion and
OMZ and other stuff. I still expect it to behave a certain way.

Basically, I like it for my main shell because I can twist it in ways
that would be much harder (or impossible) in bash (and because BashIt
has a way to go before they're near OMZ).

Re: setopt interactivecomments

[Ray Andrews]

On 04/17/2014 03:41 PM, Bart Schaefer wrote:
> In fact more often than not for me backspace works just fine in zsh but
> is messed up in other programs like vim.  That's not a shell problem,
> it's a tty-driver problem.
All I can say is that the first time I got Linux working, it didn't work 
(mind,g that would have been bash) and I'm almost positive that the 
first time I tried zsh it didn't work either.  I could be wrong about 
the latter of course, and it's just a for-instance anyway. I do know 
that when I've been forced to run zsh without any .zshrc, it's pretty 
raw.  I don't stand on details, just the principle of the thing.  
Anyway, since it seems there is some sort of config helper for newbies, 
that's good enough for me, I'm just sad I missed it. Dunno, maybe it 
could be more visible.  I found the nucleus of my current .zshrc on the 
web somewhere.
> Not sure where that's coming from either, because basic history motions
> are on by default as well.  If you're going to make straw men, at least
> make them vaguely humanoid ...
I still have nightmares about that first experience with the shell, and 
what I've said was certainly true back then. Maybe I'm just having 
flashbacks.  If we're more user friendly out of the box than I'm 
remembering, then I withdraw all my comments.  All I can say is that, on 
principle, good stuff should be 'on' by default, and if tcsh didn't have 
it 20 years ago that shouldn't be a big concern IMHO.  I certainly don't 
mean to be contentious.  Perhaps, just to air the laundry, there could 
be some sort of poll of the list as to who might like something or other 
made a default?

Re: setopt interactivecomments

[Roman Neuhauser]

# schaefer@brasslantern.com / 2014-04-17 15:41:17 -0700:
> } What would break if interactive comments was on by default?
> 
> I don't know how prevalent this still is, but a number of programs used
> file names with # in them for backups.  It becomes one more thing you
> have to quote.

i'm *very* happy with zsh's conservatism: with one or two exceptions,
my 14yr old .zshrc has worked the same for me the whole time.

that said, i rely on filename completion to quote metacharacters for me.
it's possible to screw it up when i *do* input crazy filenames w/o
autocompletion (most probably copy/paste), so far i had no horrible
things happen in result (knock on wood).  IOW i have a slight preference
for interactive comments to be enabled by default, if completion
compensates for it.

-- 
roman

zsh-newuser-install

[Peter Stephenson]

On Thu, 17 Apr 2014 12:37:22 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> What did eventually happen after the mess was cleaned up is that the
> zsh-newuser-install system got created.  It could use an update, but
> is intended to walk you through enabling the stuff that you're most
> likely to want.

Yes, I was going to mention this when I got back, which I eventually
did.

There's certainly plenty that could be added here --- enough that
nothing's likely  to happen unless we get some solid feedback...

- Make it more modular so stuff can be plugged into it and more of the
low-level framework is available as separate functions.

- Make it interact better with scripts installed by distributions?  I'm
not sure how useful this actually is, given distributions tend to hook
into to global /etc files, but then that doesn't give the user much
control, which is the point of newuser.  Maybe the previous point already
covers this well enough.

- Make it easier to run again.  Maybe this is actually OK, however
currently you have to force it with a special option: this makes me
think I was worried I hadn't properly debugged interaction with stuff
set by the user.  (Of course, that's impossible to get completely right
if the user does arbitrary other things in their start-up scripts, but
it should be fail safe --- and we're really aiming at people who don't
have heavily customized shells already so I don't think it's a real
issue as long as we can update what newuser did before.)

- Information from manual pages is probably better coming from the new
pre-formatted help files.

- Add more syntactic options with recommendations: this would cover
interactivecomments, for example, and possible other things that might
save you later on without getting in your way, such as warncreateglobal.

- Configure the nomatch / nullglob / cshnullglob behaviour.  (This is
the sort of thing I always intended to do, I'm a bit surprised it's not
there.)

- Add a wizard mode, i.e. guide you step by step ("Next, would you like
to configure what happens when the shell fails to match a pattern on the
command line?  Note zsh's normal behaviour is different from other
shells, so if you're switching from bash or tcsh you might want to look
at this [y/n]?").  You then get the chance either to pick a
recommendation ("standard zsh behaviour: safe, with errors if a pattern
doesn't match -- you can then edit the line again using the history"
vs. "standard behaviour of many other shells including bash" etc.) or go
down to low-level menu selection.  I think modularisation will have to a
be a prerequisite for this.

- Add a mechanism covering all shell options in a suitable hierarchy;
the groups in the manual page are a starting point.  This could be down
in an "advanced" section.

- Better screen handling with zcurses.  (I don't expect I'd have
time to get to grips with this myself but it shouldn't be rocket science,
at least not big shiny rockets with lots of nozzles.)

These are all merely ideas, they are not things I would intend to do
just because I felt like it.

By the way, this is all standard zsh function stuff --- so if anyone
is looking for a project this is a good place to help.  If they were,
modularizing the current set up would be the place to start so it
becomes much simpler to maintain and upgrade.

pws

Re: zsh-newuser-install

[Yuri D'Elia]

On 04/23/2014 05:50 PM, Peter Stephenson wrote:
> There's certainly plenty that could be added here --- enough that
> nothing's likely  to happen unless we get some solid feedback...
> 
> - Make it more modular so stuff can be plugged into it and more of the
> low-level framework is available as separate functions.
> 
> - Make it interact better with scripts installed by distributions?  I'm
> not sure how useful this actually is, given distributions tend to hook
> into to global /etc files, but then that doesn't give the user much
> control, which is the point of newuser.  Maybe the previous point already
> covers this well enough.

I'd like to plug myself right in here, to mention that I find the
newuser module to be frustrating once you _already_ know zsh.

It'd like it to be just a function being called in /etc/zsh/zshrc with a
simple test:

[ ! -f "~/.zshrc" ] && zmodload ... && zsh-newuser-install

So that:

- you can re-run it manually whenever you want (just zmodload&call)
- you can disable the check by editing the systemwide zshrc

... and since configuration files in /etc/ are preserved, the change
would _persist_ when zsh is updated.

Right now I'm using a post-install hook to remove the newuser module
after zsh is updated, because there are a few cases when I don't want a
zshrc around, and I really (really) know what I'm doing.

> These are all merely ideas, they are not things I would intend to do
> just because I felt like it.

I think many people nowdays wouldn't need the newuser mechanism, to be
honest. With oh-my-zsh (and friends), people just look for a
pre-configured solution which has a gazillion of options turned on.

I personally always did the opposite, by starting reading the manual
from an empty rc.

Either way, I think that the newuser mechanism is not actually "selling"
zsh to both experienced or novel users. The only thing that I see, is
that it signals to the user that "look! this is *NOT* bash", and I think
it's actually good to have for places where zsh is unexpected (note: I
*never* saw zsh being the default shell anywhere).

But that's just my 2c.

Re: zsh-newuser-install

[Mikael Magnusson]

On 23 April 2014 22:31, Yuri D'Elia <wavexx@thregr.org> wrote:
> On 04/23/2014 05:50 PM, Peter Stephenson wrote:
>> There's certainly plenty that could be added here --- enough that
>> nothing's likely  to happen unless we get some solid feedback...
>>
>> - Make it more modular so stuff can be plugged into it and more of the
>> low-level framework is available as separate functions.
>>
>> - Make it interact better with scripts installed by distributions?  I'm
>> not sure how useful this actually is, given distributions tend to hook
>> into to global /etc files, but then that doesn't give the user much
>> control, which is the point of newuser.  Maybe the previous point already
>> covers this well enough.
[...]
> I think many people nowdays wouldn't need the newuser mechanism, to be
> honest. With oh-my-zsh (and friends), people just look for a
> pre-configured solution which has a gazillion of options turned on.

If nobody used oh-my-zsh, the world would be a better place. Or at
least #zsh would be.

-- 
Mikael Magnusson

Re: zsh-newuser-install

[Ray Andrews]

On 04/23/2014 08:50 AM, Peter Stephenson wrote:
> There's certainly plenty that could be added here --- enough that
> nothing's likely  to happen unless we get some solid feedback...
Glad to see that there's openness to change with this.  I think most 
shell users are veterans,
so have long since gotten past the agonies of being a newbie. Mind, 
that's true with most of the
CLI stuff--most of it is hoary with age and horribly unfriendly. That's 
all the more  reason to
re-think stuff tho.  A more welcoming command line would help pull folks 
away from the GUI/slave
mentality and turn them into 'real' Linux users.  Anyway, other folks 
may have had an easier time
of it, but, as I said, my own first experiences with bash/zsh were 
sadistic.  What would have made
a huge difference is knowing what were/are the 'correct' sources of 
information--the 'official' manual,
the official web site, recommended reading, etc.

Re: zsh-newuser-install

[Yuri D'Elia]

On 04/24/2014 01:53 AM, Mikael Magnusson wrote:
>>> - Make it interact better with scripts installed by distributions?  I'm
>>> not sure how useful this actually is, given distributions tend to hook
>>> into to global /etc files, but then that doesn't give the user much
>>> control, which is the point of newuser.  Maybe the previous point already
>>> covers this well enough.
> [...]
>> I think many people nowdays wouldn't need the newuser mechanism, to be
>> honest. With oh-my-zsh (and friends), people just look for a
>> pre-configured solution which has a gazillion of options turned on.
> 
> If nobody used oh-my-zsh, the world would be a better place. Or at
> least #zsh would be.

I had to smile at this :)
But, sadly, many of the people that I know use it.

I have the same sentiment for similar projects for vim, emacs, and even
bash.

Re: zsh-newuser-install

[Ray Andrews]

On 04/23/2014 11:23 PM, Yuri D'Elia wrote:
>
> If nobody used oh-my-zsh, the world would be a better place. Or at
> least #zsh would be.
> I had to smile at this :)
> But, sadly, many of the people that I know use it.

Indeed? What's wrong with it? When I was looking for reliable 
help/information about zsh
I remember seeing it, tho all I remember is that it seemed very advanced 
and complicated,
but what is 'sad' about people using it?  Too bad there isn't some sort 
of overview of all zsh
resources, so that one knows where to look for information, and what to 
expect here and there.

Speaking of approved resources, I notice that there is a Sourceforge 
page for zsh, but  understood
that  the official place for that is at Github.

Re: zsh-newuser-install

[Yuri D'Elia]

On 04/24/2014 04:34 PM, Ray Andrews wrote:
>> If nobody used oh-my-zsh, the world would be a better place. Or at
>> least #zsh would be.
>> I had to smile at this :)
>> But, sadly, many of the people that I know use it.
> 
> Indeed? What's wrong with it? When I was looking for reliable 
> help/information about zsh
> I remember seeing it, tho all I remember is that it seemed very advanced 
> and complicated,
> but what is 'sad' about people using it?  Too bad there isn't some sort 
> of overview of all zsh
> resources, so that one knows where to look for information, and what to 
> expect here and there.

The problem is that it is, indeed, quite complicated. It's not exactly
what I would recommend to somebody that is starting from zero with zsh.

Debugging slow completion or any issue you have with it will immediately
be too hard for somebody who never tweaked zsh before, because there's
no single "item" you can search for in the manual page.

For instance, I severely dislike when completion tries to outsmart me,
or behaves in non-predictive ways. I care much more that completion
takes 0 time (as in: no perceptible time) to complete. You'll need some
RTFM to tweak the completer in the way you want, but tweaking oh-my-zsh
will just be harder.

I see no difference between bash/zsh if I really wanted to use just some
pre-packaged config. You can roughly get the same behavior anyway.

Re: zsh-newuser-install

[Axel Beckert]

Hi,

On Thu, Apr 24, 2014 at 07:34:13AM -0700, Ray Andrews wrote:
> >If nobody used oh-my-zsh, the world would be a better place. Or at
> >least #zsh would be.
> >I had to smile at this :)
> >But, sadly, many of the people that I know use it.
> 
> Indeed? What's wrong with it?

Oh, for example upon installation it sets your login shell to zsh and upon
uninstallation it tries to set your login shell to bash even if it was
already zsh before the installation, just to name one thing.

> Speaking of approved resources, I notice that there is a Sourceforge
> page for zsh, but understood that the official place for that is at
> Github.

AFAIK it's vice versa. I don't know of any official Zsh page at
Github. zsh.sf.net is as official as zsh.org IIRC.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: zsh-newuser-install

[Ray Andrews]

On 04/24/2014 09:02 AM, Yuri D'Elia wrote:
> On 04/24/2014 04:34 PM, Ray Andrews wrote:
> The problem is that it is, indeed, quite complicated. It's not exactly 
> what I would recommend to somebody that is starting from zero with zsh. 

Well, then I agree. At least myself, I stayed away from it when I saw 
how fancy it tried to be.

> Debugging slow completion or any issue you have with it will 
> immediately be too hard for somebody who never tweaked zsh before, 
> because there's no single "item" you can search for in the manual 
> page. For instance, I severely dislike when completion tries to 
> outsmart me, or behaves in non-predictive ways. 
Right. The first thing software of any kind should be is predictable.

Re: zsh-newuser-install

[Martin Vaeth]

Mikael Magnusson <mikachu@gmail.com> wrote:
>
> If nobody used oh-my-zsh, the world would be a better place. Or at
> least #zsh would be.

I agree with you that oh-my-zsh is horrible in many aspects.

But it has a major advantage which is why people use it:
It enables a lot of features which are off in zsh by default
and which many people are not aware of.

No, newusers does not solve this problem, because most
users simply ignore this, and most users will never read the
full manpage unless they have a particular problem.

I understand that most features are off by default to keep
compatibility.  However, in interactive shells compatbility
is not really an issue.  Perhaps one could enable much more
*interactive* features by default which are actually the
biggest selling point of zsh.
At least, some zshrc could be shipped which enables lots
of these features so that e.g. on a live cd where you "must"
live with the defaults you get more luxury (distribution
maintainers are not always experts in zsh, especially
e.g. those who produce live cds, so it is better
to give them good examples).

Some examples not mentioned yet by others:

Most people are not even aware that zsh can show
them what type of word they are currently completing
and even to describe them the purpose of options.
In fact, I suppose that most work done in the description
of options is done in vain for most people if something
unless something like the following becomes a default:

zstyle ':completion:*' format '%B(%d)%b'
zstyle ':completion:*' verbose true

Also, I realized that many zsh users did not know about
the goodies they can get from e.g.:

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}

zstyle ':completion:*' menu select=1
zmodload zsh/complist
setopt no_list_ambiguous bash_auto_list
# (the latter to catch bash users)

REPORTTIME=5
TIMEFMT='%J  %M kB %*E (user: %*U, kernel: %*S)'

setopt cdable_vars
setopt auto_name_dirs
setopt extended_glob
setopt notify

# and with lesser importance

setopt numeric_globsort
setopt long_list_jobs
... many more options

Sure, for any option there are certainly some people who
prefer it differently or simpler, but for people who just
quickly check out whether zsh might be something for them,
they might get hooked to zsh when these features are on
in their testing environment.  They would probably not spend
the time to read the manual just to find out that such
features are avaible if they are not even aware that zsh
is able to do things like this almost "out-of-the-box":

This is exactly why people are impressed by oh-my-zsh.

Re: zsh-newuser-install

[Peter Stephenson]

On Fri, 25 Apr 2014 15:43:21 +0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:
> At least, some zshrc could be shipped which enables lots
> of these features so that e.g. on a live cd where you "must"
> live with the defaults you get more luxury (distribution
> maintainers are not always experts in zsh, especially
> e.g. those who produce live cds, so it is better
> to give them good examples).

There are, in fact, startup files in the distribution, but they
don't get much attention.  Currently they're intended more as examples
of sorts of things you might want to do than to be installed directly.

Obviously, it would be perfectly possible to distribute ones that are
intended for direct use, with suitably copious comments, and flag up in
the release notes that we recommend distributions to make these
available.  This will need a volunteer to take control (they can
have git access or I'm happy to commit changes myself).

We could easily customise zsh-newuser-install to the extent of looking
for templates in files installed centrally with zsh and asking whether
the user wants them copied --- that doesn't require any co-operation
from outside.

pws

Re: zsh-newuser-install

[Bart Schaefer]

On Apr 25,  3:43pm, Martin Vaeth wrote:
}
} I understand that most features are off by default to keep
} compatibility.  However, in interactive shells compatbility
} is not really an issue.  Perhaps one could enable much more
} *interactive* features by default which are actually the
} biggest selling point of zsh.

Unfortunately you're wrong about this.  Changing what is on by default
means that anyone who does NOT use/want a particular feature now has
to update their configuration to explicitly disable it.  Avoiding this
kind of surprise has always been one of our goals.

} At least, some zshrc could be shipped which enables lots
} of these features

Cf. PWS reply to this.

} Some examples not mentioned yet by others:
} 
} zstyle ':completion:*' format '%B(%d)%b'
} zstyle ':completion:*' verbose true

Styles are something that would have to be enabled by sourcing a file,
I don't think we want to pack loads of these strings into a module
(especially since the ":completion:..." naming scheme is a convention
entirely created by the shell functions in the Completion/ tree).

We could probably add some zstlye commands to compinit, using the usual
paradigm of testing for the existence of the style before setting it:

    zstyle -m ':completion:*' format '*' ||
      zstyle ':completion:*' format '%B(%d)%b'

Etc.

Re: zsh-newuser-install

[Martin Vaeth]

Peter Stephenson <p.stephenson@samsung.com> wrote:
> This will need a volunteer to take control (they can
> have git access or I'm happy to commit changes myself).

In the moment I do not have time and sufficiently secure future
to volunteer.

A while ago, I had reorganized parts of my personal setup files
so that they might serve also others (the original intention was
some replacement for oh-my-zsh), but I did not finish this,
and in its current form this is far from being appropriate
for being shipped with zsh:
It is currently mainly useful only if combined with other projects
and also does not distinguish between personal preferences
(e.g. fixed choice of colors, preferring 256 colors etc)
and enabling global features.

However, if somebody volunteers and wants to check out what
*potentially* might be of interest for enabling, feel free
to pick any code you want from
https://github.com/vaeth/zshrc-mv/

BTW: "emulate -L bash" would be useful to read some distribution's
or user's bash setup files. Main difference to emulate -L sh would be
  setopt ksh_glob no_sh_glob brace_expand
and that [[ $var ]] is treated equivalent to [[ -n $var ]]:
I experienced that the latter is the main issue with bash compatibility
(besides shopt and PS1, of course, which are not reasonable to emulate).

Re: zsh-newuser-install

[Yuri D'Elia]

On 04/25/2014 05:43 PM, Martin Vaeth wrote:
> But it has a major advantage which is why people use it:
> It enables a lot of features which are off in zsh by default
> and which many people are not aware of.
> 
> No, newusers does not solve this problem, because most
> users simply ignore this, and most users will never read the
> full manpage unless they have a particular problem.

Yes, you make a good point here.

> Some examples not mentioned yet by others:
<list snipped>

You gave a quite nice list of features here, and with very concise
configuration settings that do not depend on each other.

I would actually *love* to have a zshcheatsheet manual page with this
sort of thing.

Small, concise examples of single features that you might want or you
are completely unaware of (which happens very often).

I remember finding several of these lists online.

A list like this would be incredibly useful not only to newcomers, but
to existing users also.

This would be, in my mind, incredibly more useful than the newusers
mechanism.

Re: zsh-newuser-install

[Peter Stephenson]

On Sat, 26 Apr 2014 10:07:47 +0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:
> BTW: "emulate -L bash" would be useful to read some distribution's
> or user's bash setup files. Main difference to emulate -L sh would be
>   setopt ksh_glob no_sh_glob brace_expand
> and that [[ $var ]] is treated equivalent to [[ -n $var ]]:
> I experienced that the latter is the main issue with bash compatibility
> (besides shopt and PS1, of course, which are not reasonable to emulate).

This is easy to fix; the syntax wasn't valid up till now so there's no
conflict in enabling it.

diff --git a/Doc/Zsh/cond.yo b/Doc/Zsh/cond.yo
index 9f8a7d8..a796834 100644
--- a/Doc/Zsh/cond.yo
+++ b/Doc/Zsh/cond.yo
@@ -186,6 +186,13 @@ true if either var(exp1) or var(exp2) is true.
 )
 enditem()
 
+For compatibility, if there is a single argument that is not
+syntactically significant, typically a variable, the condition is
+treated as a test for whether the expression expands as a string of
+non-zero length.  In other words, tt([[ $var ]]) is the same as tt([[ -n
+$var ]]).  It is recommended that the second, explicit, form be used
+where possible.
+
 Normal shell expansion is performed on the var(file), var(string) and
 var(pattern) arguments, but the result of each expansion is constrained to
 be a single word, similar to the effect of double quotes.
diff --git a/Src/parse.c b/Src/parse.c
index 530a070..7957448 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -2127,6 +2127,11 @@ par_cond_2(void)
 	dble = (*s1 == '-' && strspn(s1+1, "abcdefghknoprstuwxzLONGS") == 1
 		  && !s1[2]);
     condlex();
+    if (tok == DOUTBRACK)
+    {
+	/* allow [[ $testsize ]] for compatibility */
+	return par_cond_double(dupstring("-n"), s1);
+    }
     if (tok == INANG || tok == OUTANG) {
 	enum lextok xtok = tok;
 	condlex();
diff --git a/Test/C02cond.ztst b/Test/C02cond.ztst
index 94fca8b..6900147 100644
--- a/Test/C02cond.ztst
+++ b/Test/C02cond.ztst
@@ -349,6 +349,14 @@ F:Failures in these cases do not indicate a problem in the shell.
 >0
 >1
 
+  foo=''
+  [[ $foo ]] || print foo is empty
+  foo=full
+  [[ $foo ]] && print foo is full
+0:bash compatibility with single [[ ... ]] argument
+>foo is empty
+>foo is full
+
 %clean
   # This works around a bug in rm -f in some versions of Cygwin
   chmod 644 unmodish

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: zsh-newuser-install

[Bart Schaefer]

On Apr 26, 10:07am, Martin Vaeth wrote:
} Subject: Re: zsh-newuser-install
}
} BTW: "emulate -L bash" would be useful to read some distribution's
} or user's bash setup files. Main difference to emulate -L sh would be
}   setopt ksh_glob no_sh_glob brace_expand
} and that [[ $var ]] is treated equivalent to [[ -n $var ]]:

I've started a separate thread on zsh-workers about [[ $var ]].

Regarding bash emulation, as of recent zsh you can do this kind of thing:

    emulate sh -o ksh_glob +o sh_glob -o brace_expand -c '. ~/.bashrc'

Functions loaded from .bashrc will retain the options set on the emulate
command line.

Re: zsh-newuser-install

[Bart Schaefer]

On Apr 26,  3:49pm, Yuri D'Elia wrote:
}
} You gave a quite nice list of features here, and with very concise
} configuration settings that do not depend on each other.
} 
} I would actually *love* to have a zshcheatsheet manual page with this
} sort of thing.

Here's an idea:  Let's collect some default completion zstyles and put
them in a file in $fpath, named so that compinit arranges for it to be
autoloaded the same way it picks up completers etc.  Then, if that
function is defined, execute it from compinit.  This would make it easy
to change locally (just put a file of that name earlier in $fpath) and
it also allows us to create the defaults by consensus.

Per my previous remark about testing for prior existence, all the styles
in this defaults file would need to be defined using this function or
something like it:

emulate zsh -c 'default_zstyle() {
  local -a patstyle defn
  if [[ $1 = (-e|-|--) ]]
  then patstyle=( $2 $3 )
  else patstyle=( $1 $2 )
  fi
  zstyle -g defn $patstyle || zstyle $*
}'

Examples:

----
default_zstyle ':completion:*' group-name ''
default_zstyle ':completion:*' verbose true
default_zstyle ':completion:*' ignore-parents parent pwd ..
default_zstyle ':completion:*' format '%SCompleting %U%d%u%s'
default_zstyle ':completion:*:messages' format %S%d%s
default_zstyle ':completion:*:warnings' format 'No matches for %U%d%u'

# Double colon here to avoid overriding the value set by "zed"
default_zstyle ':completion::*' insert-tab 'pending=1'
----

Thoughts?  Name for this file?

Re: zsh-newuser-install

[Bart Schaefer]

On Apr 26,  2:10pm, Bart Schaefer wrote:
}
} Here's an idea:  Let's collect some default completion zstyles and put
} them in a file in $fpath, named so that compinit arranges for it to be
} autoloaded the same way it picks up completers etc.

Silly me, I forgot about "compinstall":

------
If the system was installed completely, it should be enough to call the
shell function compinit from your initialization file; see the next
section.  However, the function compinstall can be run by a user to
configure various aspects of the completion system.

Usually, compinstall will insert code into .zshrc, although if that is
not writable it will save it in another file and tell you that file's
location.  Note that it is up to you to make sure that the lines added
to .zshrc are actually run; you may, for example, need to move them to
an earlier place in the file if .zshrc usually returns early.  So long
as you keep them all together (including the comment lines at the start
and finish), you can rerun compinstall and it will correctly locate and
modify these lines.  Note, however, that any code you add to this
section by hand is likely to be lost if you rerun compinstall, although
lines using the command `zstyle' should be gracefully handled.

The new code will take effect next time you start the shell, or run
.zshrc by hand; there is also an option to make them take effect
immediately.  However, if compinstall has removed definitions, you will
need to restart the shell to see the changes.

To run compinstall you will need to make sure it is in a directory
mentioned in your fpath parameter, which should already be the case if
zsh was properly configured as long as your startup files do not remove
the appropriate directories from fpath.  Then it must be autoloaded
(`autoload -U compinstall' is recommended).  You can abort the
installation any time you are being prompted for information, and your
.zshrc will not be altered at all; changes only take place right at the
end, where you are specifically asked for confirmation.
------

compinit arranges to autoload compinstall, so you can always run it if
you have the completion system loaded.

However, that doesn't mean it's a bad idea to have an additional file
of defaults that are easily overridden by the user or local admin.
I suggest calling it "compdefaults" and autoloading it at the same
point in compinit where compinstall et al. are autoloaded.

Then the question is when to run it.