zsh-workers
 help / color / mirror / Atom feed
* Rewrite of zsh-newuser-install
@ 2021-02-06 20:03 Marlon Richert
       [not found] ` <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com>
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-06 20:03 UTC (permalink / raw)
  To: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

Hi, Zsh devs,

Would you be open to receiving a major overhaul of `zsh-newuser-install`?
And if so, would it be OK if I submit it as a pull request on
https://github.com/zsh-users/zsh?

Regards,
—Marlon

[-- Attachment #2: Type: text/html, Size: 348 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
       [not found] ` <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com>
@ 2021-02-06 20:19   ` Marlon Richert
  2021-02-06 20:33     ` Lawrence Velázquez
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-06 20:19 UTC (permalink / raw)
  To: Patrick Reader; +Cc: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

There are plenty of pull requests on there:
https://github.com/zsh-users/zsh/pulls?q=is%3Apr

Anyway, I thought I would ask upfront, before putting in the work. I think
the experience for new users could be improved considerably, but it would
require quite a bit of changes to zsh-newuser-install.

On Sat, Feb 6, 2021 at 10:05 PM Patrick Reader <_@pxeger.com> wrote:

> AFAIK, that is not an official repository. All development/integration
> is done by good old fashioned diffs via email
>
> On 06/02/2021 20:03, Marlon Richert wrote:
> > Hi, Zsh devs,
> >
> > Would you be open to receiving a major overhaul of
> > `zsh-newuser-install`? And if so, would it be OK if I submit it as a
> > pull request on https://github.com/zsh-users/zsh
> > <https://github.com/zsh-users/zsh>?
> >
> > Regards,
> > —Marlon
> >
>

[-- Attachment #2: Type: text/html, Size: 1428 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-06 20:19   ` Marlon Richert
@ 2021-02-06 20:33     ` Lawrence Velázquez
  2021-02-06 21:54       ` Bart Schaefer
  2021-02-07 13:41       ` Marlon Richert
  0 siblings, 2 replies; 114+ messages in thread
From: Lawrence Velázquez @ 2021-02-06 20:33 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Patrick Reader, zsh-workers

> On Feb 6, 2021, at 3:19 PM, Marlon Richert <marlon.richert@gmail.com> wrote:
> 
> There are plenty of pull requests on there: https://github.com/zsh-users/zsh/pulls?q=is%3Apr

Many (most?) of the primary developers do not frequent GitHub, so
you would be relying on the good graces of a few industrious
individuals who try to bridge the gap to this mailing list, and the
bulk of the ensuing discussion would take place here. It would add
considerable friction, and I think it's safe to say that it would
make it more difficult for you to get your changes accepted.

The preferred method is to post a patch series to this mailing list.

> Anyway, I thought I would ask upfront, before putting in the work. I think the experience for new users could be improved considerably, but it would require quite a bit of changes to zsh-newuser-install.

Perhaps you could make a proposal and have a discussion here first?

vq

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-06 20:33     ` Lawrence Velázquez
@ 2021-02-06 21:54       ` Bart Schaefer
  2021-02-07 13:41       ` Marlon Richert
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-06 21:54 UTC (permalink / raw)
  To: Marlon Richert; +Cc: zsh-workers

On Sat, Feb 6, 2021 at 12:33 PM Lawrence Velázquez <vq@larryv.me> wrote:
>
> Perhaps you could make a proposal and have a discussion here first?

I second that.  What would you change?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-06 20:33     ` Lawrence Velázquez
  2021-02-06 21:54       ` Bart Schaefer
@ 2021-02-07 13:41       ` Marlon Richert
  2021-02-07 13:51         ` Roman Perepelitsa
  2021-02-07 20:22         ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-07 13:41 UTC (permalink / raw)
  To: vq, Bart Schaefer; +Cc: Patrick Reader, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

On Sat, Feb 6, 2021 at 10:33 PM Lawrence Velázquez <vq@larryv.me> wrote:

> The preferred method is to post a patch series to this mailing list.
>

Sure, then I will do that.


Perhaps you could make a proposal and have a discussion here first?
>

Of course. Here's what I would change:

* Fewer questions: Over the past year, I've read many posts by new Zsh
users on Github (in the form of issues and questions on several plugins I
develop), Stack Exchange sites (by reading & answering Zsh-related
questions) and Reddit. The feeling I get from what I've read is that the
amount of questions asked by zsh-newuser-install and compinstall
(especially the latter) is overwhelming new users and they are not sure
what to pick or even what exactly they are picking. Since they have no
prior experience with Zsh, they have a difficult time understanding what is
being asked of them.
* Better defaults: I understand that we cannot change the actual defaults,
since this would disrupt existing Zsh users' configs. However, new users by
definition don't have any Zsh config yet. By using a good set of default
values in zsh-newuser-install and compinstall, we can both reduce the
number of questions we need to ask and greatly improve the out-of-the-box
experience for new users. Since these "defaults" will all be set in the
.zshrc file we generate for them, if they later on don't like them anymore,
they can easily change them.

Additionally, let me emphasize that what I would _not_ do is put lots of
custom logic in the .zshrc. The generated .zshrc file should not contain
anything more complex than the example code snippets in the Zsh manual. The
less moving parts, the better. KISS. What is in there should be easy for
the user to modify without breaking.

[-- Attachment #2: Type: text/html, Size: 2331 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 13:41       ` Marlon Richert
@ 2021-02-07 13:51         ` Roman Perepelitsa
  2021-02-07 17:10           ` Marlon Richert
  2021-02-07 20:22         ` Bart Schaefer
  1 sibling, 1 reply; 114+ messages in thread
From: Roman Perepelitsa @ 2021-02-07 13:51 UTC (permalink / raw)
  To: Marlon Richert
  Cc: Lawrence Velázquez, Bart Schaefer, Patrick Reader, Zsh hackers list

Previous discussion:
https://www.zsh.org/mla/workers/2020/msg00043.html and follow-ups.

Roman.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 13:51         ` Roman Perepelitsa
@ 2021-02-07 17:10           ` Marlon Richert
  2021-02-07 17:28             ` Marlon Richert
                               ` (3 more replies)
  0 siblings, 4 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-07 17:10 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Lawrence Velázquez, Bart Schaefer, Patrick Reader, Zsh hackers list

On Sun, Feb 7, 2021 at 3:51 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
> Previous discussion:
> https://www.zsh.org/mla/workers/2020/msg00043.html and follow-ups.

Thanks, I took the time to read through all of it (and then some
more). Let me respond here to most of it.

I agree with almost all that Roman said there, with some exceptions or
additions as noted:

> I think zshrc recommended by zsh should be very conservative. It should enable users to get started (basic keys must work, prompt must show current directory, completions must work -- this sort of stuff) *and* it must enable average users to take control over their configuration. The danger of too complex starter zshrc is that users won't be able to understand it, and will have worse setup long term because of this.
> To be more specific:
> - no vcs_info. in some environments it makes prompt noticeably slow; it also adds a lot of complexity

Not only that, but I find it less work to figure out how to get the
info I need from Git directly, than to understand how to configure
vcs_info to do it. Not only that, vcs_info from the "too generic tool"
problem: By trying to cater to all VCS systems, it caters to none of
them well.

> - the config itself must not have any configuration options of its own, be it zstyle or parameters; it's a config, not a meta config; users should be encouraged to edit it rather than create another config with parameters for this config and source one from another
> - no prompt_subst or precmd hooks

I disagree with that particular point. Making use of promptsubst and
precmd (or other) hooks is fine by me, as long as we don't go
overboard with it. There is nothing inherently complex about that.

> - no prompt shortening; display directory as %~
> - no syntax highlighting, autosuggestions or any other external plugins; autoloading functions bundled with zsh is OK

While I agree that we shouldn't include external plugins here, I don't
think all Zsh-bundled functions are OK to autoload. While there are
some really good ones, many of them feel like abandonware. In that
respect, I think many of them would be better off being removed from
the Zsh repo and maintained in separate repos as plugins instead.

> - single file (zshrc)
>
> The file should explain through comments what things mean ("%~ is current directory", etc) and should suggest where users should add their aliases and exported variables. Comments should also suggest where more information can be found ("for more information about prompting, see xxx"). Links to web pages here work better than `man` commands, although putting both of them will also work.
> What about the goodies though? Leave that to the market. Anyone can come up with a config template, or even an interactive dialog that creates a config based on your preferences. Let them compete. zsh should be *usable* upon installation but not bloated or opinionated.
> [...]
> - Inline the prompt definition instead of using promptinit. This makes it much easier for users to customize prompt. Abstractions are a serious barrier for beginners.

prompinit is one of those autoloadable functions that in theory feel
like a very good idea, but feels like abandonware in practice. I would
love for it to get the same amount of care as compinit does, but as it
stands, it really doesn't do much at all.


> - Move keybindings (everything, really) from the global zshrc to the user and remove fancy indirection from there as well (don't use terminfo and don't define auxiliary assoc arrays). This will show users how to define bindings. Also get rid of zle-line-begin/end hooks and stop changing terminal mode. Do something like this instead: https://www.reddit.com/r/zsh/comments/eblqvq/d/fb7337q/. This is easier to understand and more robust.

The problem I have with Roman's approach to key bindings is that there
is no central source for rmkx escape codes. You end up hard-coding a
whole lot that might be specific to just the terminals you happen to
use. I don't like that approach. (Not that terminfo is perfect either,
but at least it saves you from reinventing the wheel.)

But the point is kind of moot if Dana's suggestion could just get
implemented, which I think would be preferable:

> Actually, if key bindings don't always work well out of the box, and especially if we can fix that by simply checking terminfo, shouldn't we do that with the default bindings in the shell itself?


Continuing with Roman's comments:

> - More comments explaining what things do and where to find docs. E.g., comments above bindings should say which key is being bound and what the widget does. It should also explain how to figure out escape codes for different keys and where to find the list of builtin widgets.
> - Maybe fewer completion styles. Seems like too much but maybe they are really important, I don't know.

Again, as long as they are low complexity, I don't see a problem
there. I agree with Dana:

> Obviously we shouldn't go crazy with it, but i don't see any reason to specifically limit the use of styles. The style system is an important aspect of configuring zsh. There are very useful settings that can only be changed that way, and it's important for users to know about it if they want to make their own changes.

I like how the zstyle system has namespacing built in and how it makes
the env less polluted with random vars. We should definitely encourage
zstyle to be used more, not less.


Anyway, to finish it off:

> One meta observation based on my experience doing the same with powerlevel10k. 90%+ of users won't ever open the default config file. 90% of those that do, won't read any documentation that isn't included in the file itself.

I have browsed P10k's default config file and it is insanely complex.
Though I agree that most users don't read and we should thus keep the
amount of explanatory text to a minimum, I don't think you can view
your use case as being representative.


Finally, regarding Daniel's pet favorite:

> - a certain syntax highlighting plugin :P

I think it would be great if Zsh would have syntax highlighting out of
the box. It feels silly to have documentation for region_highlight,
but then ship no simple way of using it. However, if syntax
highlighting is going to be included by default, then it should be
maintained in the Zsh repo and not as an external plugin.


Anyway, sorry for the long post. I hope I have at least given you a
good overview of my thoughts and intentions.

Now, if I want to work on this, where should I start? Should I fork
https://gitlab.com/zsh-sensible/zsh-sensible ?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 17:10           ` Marlon Richert
@ 2021-02-07 17:28             ` Marlon Richert
  2021-02-07 20:20               ` Bart Schaefer
  2021-02-07 21:06             ` dana
                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-07 17:28 UTC (permalink / raw)
  To: Roman Perepelitsa
  Cc: Lawrence Velázquez, Bart Schaefer, Patrick Reader, Zsh hackers list

PS: Regarding terminal escape codes, I found the following post a
rather interesting read.
https://github.com/fish-shell/fish-shell/issues/2139#issuecomment-388706768


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 17:28             ` Marlon Richert
@ 2021-02-07 20:20               ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-07 20:20 UTC (permalink / raw)
  To: Marlon Richert
  Cc: Roman Perepelitsa, Lawrence Velázquez, Patrick Reader,
	Zsh hackers list

On Sun, Feb 7, 2021 at 9:29 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> PS: Regarding terminal escape codes, I found the following post a
> rather interesting read.
> https://github.com/fish-shell/fish-shell/issues/2139#issuecomment-388706768

It's for most of the reasons listed in that article that zsh has never
made an attempt to fix this, especially not by reference to terminfo.

Among the semi-abandoned functions you mentioned is
Functions/Misc/zkbd, which attempts to let you program your keys but
lacks a naming scheme that works reliably across remote logins.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 13:41       ` Marlon Richert
  2021-02-07 13:51         ` Roman Perepelitsa
@ 2021-02-07 20:22         ` Bart Schaefer
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-07 20:22 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Sun, Feb 7, 2021 at 5:42 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> * Fewer questions:
> * Better defaults:

This is nowhere near specific enough.  Your response to Roman got a
bit better, but what defaults constitute "better" and which questions
to (not) ask is important for the discussion.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 17:10           ` Marlon Richert
  2021-02-07 17:28             ` Marlon Richert
@ 2021-02-07 21:06             ` dana
  2021-02-07 21:15               ` Marlon Richert
  2021-02-08  9:21               ` Peter Stephenson
  2021-02-08  6:35             ` Daniel Shahaf
  2021-02-09 21:44             ` Eric Cook
  3 siblings, 2 replies; 114+ messages in thread
From: dana @ 2021-02-07 21:06 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 7 Feb 2021, at 11:10, Marlon Richert <marlon.richert@gmail.com> wrote:
> Now, if I want to work on this, where should I start? Should I fork
> https://gitlab.com/zsh-sensible/zsh-sensible ?

I haven't been following the list super closely the last several months but
afaik most people seemed to agree in principle that a 'do the right thing'
default config would be nice. Obviously as Bart said everyone is going to want
to discuss exactly what that entails — it seems like just proposing the file
with the settings you want would be a good way to start that process? Whether
you do the work on GitLab or not doesn't matter, but most of the actual
discussion would presumably be on the list

I had started on my own fork of that repo at the time:

  https://gitlab.com/okdana/zsh-sensible/-/blob/dana/sensible/zshrc

But i ran out of steam after getting through the basics Daniel had originally
included, and didn't think i'd have the energy to defend the more
'opinionated' choices i was starting to make. I was also unsure about how much
explanatory text to include; i wanted to avoid an OMZ situation where nobody
who uses it knows what any of it actually does, but re-inventing the manual
was probably too far in the other direction

Maybe an inspiration, anyway

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 21:06             ` dana
@ 2021-02-07 21:15               ` Marlon Richert
  2021-02-08 21:57                 ` Marlon Richert
  2021-02-08  9:21               ` Peter Stephenson
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-07 21:15 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

On Sun, Feb 7, 2021 at 10:22 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is nowhere near specific enough.  Your response to Roman got a
> bit better, but what defaults constitute "better" and which questions
> to (not) ask is important for the discussion.

Well, actually, after reading the whole discussion linked to by Roman,
I actually feel that we can get away with asking exactly zero
questions from new users, as long as we provide them with a good
.zshrc file to start with and a welcome message that tells them where
to find it and to edit it if they want to change their settings.

Something like this:


Welcome to the Z Shell!

We've prepared a friendly set of default settings for you. Please try
out your new shell for a while to see how you like them. Once you've
settled in and want to know a bit better how everything works, you can
change your settings by editing the file `.zshrc` in your home folder.
Any old text editor will do.

More info is available by typing `man zsh` or by going to
http://zsh.sourceforge.net/Doc/Release/

Good luck!


And as to what defaults I think are "better"? To make that more clear,
I think it's probably best I go with Dana's suggestion:

On Sun, Feb 7, 2021 at 11:06 PM dana <dana@dana.is> wrote:
> I haven't been following the list super closely the last several months but
> afaik most people seemed to agree in principle that a 'do the right thing'
> default config would be nice. Obviously as Bart said everyone is going to want
> to discuss exactly what that entails — it seems like just proposing the file
> with the settings you want would be a good way to start that process? Whether
> you do the work on GitLab or not doesn't matter, but most of the actual
> discussion would presumably be on the list

Yes, I think that's what I'll do: I'll create a draft of what I think
a new user's .zshrc file should look like, and then we can discuss it
here.


> I had started on my own fork of that repo at the time:
>
>   https://gitlab.com/okdana/zsh-sensible/-/blob/dana/sensible/zshrc
>
> But i ran out of steam after getting through the basics Daniel had originally
> included, and didn't think i'd have the energy to defend the more
> 'opinionated' choices i was starting to make. I was also unsure about how much
> explanatory text to include; i wanted to avoid an OMZ situation where nobody
> who uses it knows what any of it actually does, but re-inventing the manual
> was probably too far in the other direction

Yeah, I think that file contains way too much in the way of comments.
As Roman pointed out, most people don't read most text most of the
time.


> Maybe an inspiration, anyway

Thanks, it's much appreciated!


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 17:10           ` Marlon Richert
  2021-02-07 17:28             ` Marlon Richert
  2021-02-07 21:06             ` dana
@ 2021-02-08  6:35             ` Daniel Shahaf
  2021-02-08  8:44               ` Marlon Richert
  2021-02-09 21:44             ` Eric Cook
  3 siblings, 1 reply; 114+ messages in thread
From: Daniel Shahaf @ 2021-02-08  6:35 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Marlon Richert wrote on Sun, Feb 07, 2021 at 19:10:23 +0200:
> Finally, regarding Daniel's pet favorite:
> 

For future reference, speculations as to what my favourites may be belong on
the cutting room floor.

> > - a certain syntax highlighting plugin :P

> I think it would be great if Zsh would have syntax highlighting out of
> the box. It feels silly to have documentation for region_highlight,
> but then ship no simple way of using it. However, if syntax
> highlighting is going to be included by default, then it should be
> maintained in the Zsh repo and not as an external plugin.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08  6:35             ` Daniel Shahaf
@ 2021-02-08  8:44               ` Marlon Richert
  2021-02-08  8:46                 ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-08  8:44 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Mon, Feb 8, 2021 at 8:35 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Marlon Richert wrote on Sun, Feb 07, 2021 at 19:10:23 +0200:
> For future reference, speculations as to what my favourites may be belong on
> the cutting room floor.>
> > > - a certain syntax highlighting plugin :P

I'm sorry if I said something to offend you. That was not my
intention. Judging from the way you pushed for inclusion of "a certain
syntax highlighting plugin :P", I made my comment in an attempt at
being humorous. :)  It was not intended as a personal slight. Again,
my apologies that this did not come across well.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08  8:44               ` Marlon Richert
@ 2021-02-08  8:46                 ` Marlon Richert
  2021-02-08 10:32                   ` Daniel Shahaf
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-08  8:46 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Mon, Feb 8, 2021 at 10:44 AM Marlon Richert <marlon.richert@gmail.com> wrote:
> Judging from the way you pushed for inclusion of "a certain
> syntax highlighting plugin :P", I made my comment in an attempt at
> being humorous. :)

OK, upon second reading, that sentence came out awkwardly. What I
meant to say is, I thought you were trying to be funny, so I tried to
be funny, too. Clearly, that didn't work.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 21:06             ` dana
  2021-02-07 21:15               ` Marlon Richert
@ 2021-02-08  9:21               ` Peter Stephenson
  1 sibling, 0 replies; 114+ messages in thread
From: Peter Stephenson @ 2021-02-08  9:21 UTC (permalink / raw)
  To: zsh workers

> On 07 February 2021 at 21:06 dana <dana@dana.is> wrote:
> On 7 Feb 2021, at 11:10, Marlon Richert <marlon.richert@gmail.com> wrote:
> > Now, if I want to work on this, where should I start? Should I fork
> > https://gitlab.com/zsh-sensible/zsh-sensible ?
> 
> I haven't been following the list super closely the last several months but
> afaik most people seemed to agree in principle that a 'do the right thing'
> default config would be nice. Obviously as Bart said everyone is going to want
> to discuss exactly what that entails — it seems like just proposing the file
> with the settings you want would be a good way to start that process? Whether
> you do the work on GitLab or not doesn't matter, but most of the actual
> discussion would presumably be on the list

Yes, this approach takes away all tricky questions.  I think we were simply
waiting for someone to do this, so now would be an excellent opportunity.

One question is how much commenting to add to the defaults.  If there's
enough to say "this does this but you might want to try this instead..."
you get the benefits of configurability, but it's there for when the
user wants it, rather immediately they start the shell when they don't
know what they're doing; disk space is cheap.  But we could also
provide a separate fully commented version to keep the initialisation
file neat.  This isn't a duplicate of the shell doc since it's basically
examples.  That might be the best of all worlds.

pws


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08  8:46                 ` Marlon Richert
@ 2021-02-08 10:32                   ` Daniel Shahaf
  2021-02-08 17:44                     ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Daniel Shahaf @ 2021-02-08 10:32 UTC (permalink / raw)
  To: Marlon Richert; +Cc: zsh-workers

Marlon Richert wrote on Mon, 08 Feb 2021 08:46 +00:00:
> On Mon, Feb 8, 2021 at 10:44 AM Marlon Richert <marlon.richert@gmail.com> wrote:
> > Judging from the way you pushed for inclusion of "a certain
> > syntax highlighting plugin :P", I made my comment in an attempt at
> > being humorous. :)
> 
> OK, upon second reading, that sentence came out awkwardly. What I
> meant to say is, I thought you were trying to be funny, so I tried to
> be funny, too. Clearly, that didn't work.

The emoticon wasn't there to convey humour but to acknowledge my
conflict of interest: I co-maintain a syntax highlighting plugin.  I see
this context might not have been clear.

Similarly, I didn't "push" to include that plugin.  I merely floated the
idea for -workers@' consideration.

Anyway, no harm done.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08 10:32                   ` Daniel Shahaf
@ 2021-02-08 17:44                     ` Marlon Richert
  2021-02-08 20:47                       ` Bart Schaefer
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-08 17:44 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Mon, Feb 8, 2021 at 12:33 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:w
> The emoticon wasn't there to convey humour but to acknowledge my
> conflict of interest: I co-maintain a syntax highlighting plugin.  I see
> this context might not have been clear.
> Similarly, I didn't "push" to include that plugin.  I merely floated the
> idea for -workers@' consideration.

Well, like I said, I think it would make a lot of sense for command
line syntax highlighting to be included by default. It feels odd to
have a feature like region_highlight that is basically impossible to
use for anyone without using a plugin. But I think it also feels odd
to include a plugin that is not being maintained within the core Zsh
repo. Moving zsh-syntax-highlighting into the Zsh distribution as an
autoloadable function would make a lot of sense to me.


> Anyway, no harm done.

Glad to hear that. :)


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08 17:44                     ` Marlon Richert
@ 2021-02-08 20:47                       ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-08 20:47 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Mon, Feb 8, 2021 at 9:45 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> Well, like I said, I think it would make a lot of sense for command
> line syntax highlighting to be included by default. It feels odd to
> have a feature like region_highlight that is basically impossible to
> use for anyone without using a plugin.

Just pointing out:
1) Syntax highlighting is an application of region_highlight that was
invented after region_highlight was added, it was not the reason for
region_highlight
2) Syntax analysis is a complicated process that would be a mysterious
black box to new users and might make zsh appear slow in some
circumstances (compare discussion of vcs_info)
3) There are at least two "competing" implementations that I know of:
the one Daniel co-maintains, and one created (forked?) by Sebastian
Gniazdowski which he heavily optimized


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 21:15               ` Marlon Richert
@ 2021-02-08 21:57                 ` Marlon Richert
  2021-02-08 23:33                   ` Lawrence Velázquez
                                     ` (2 more replies)
  0 siblings, 3 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-08 21:57 UTC (permalink / raw)
  To: Zsh hackers list

All right, here is my first draft:
https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

Looking forward to your comments.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08 21:57                 ` Marlon Richert
@ 2021-02-08 23:33                   ` Lawrence Velázquez
  2021-02-09  1:42                   ` Bart Schaefer
  2021-02-09  4:51                   ` dana
  2 siblings, 0 replies; 114+ messages in thread
From: Lawrence Velázquez @ 2021-02-08 23:33 UTC (permalink / raw)
  To: Marlon Richert; +Cc: zsh-workers

> On Feb 8, 2021, at 4:57 PM, Marlon Richert <marlon.richert@gmail.com> wrote:
> 
> All right, here is my first draft:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

> setopt HIST_IGNORE_ALL_DUPS # Ensure all history items are unique.
> setopt HIST_REDUCE_BLANKS   # Remove insignificant whitespace.

I know that a lot of people like modifying their history automatically
(including me!), but doing so by default is essentially silent data
corruption. I think this is the kind of thing users need to actively
opt into.

> setopt SHARE_HISTORY        # All simultaneous sessions use the same history.

Similarly, while it's neat if you're into it, in my opinion constant
importing of other sessions' histories is too much action-at-a-distance
to enable without an explicit opt-in.

I haven't really thought about the rest.

vq

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08 21:57                 ` Marlon Richert
  2021-02-08 23:33                   ` Lawrence Velázquez
@ 2021-02-09  1:42                   ` Bart Schaefer
  2021-02-09  2:00                     ` Bart Schaefer
  2021-02-09  8:17                     ` Marlon Richert
  2021-02-09  4:51                   ` dana
  2 siblings, 2 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09  1:42 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Generally speaking not bad.  Thanks for the sample.  More detailed commentary:

> HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history # File in which to save history

I've seen/used this as ".zhistory" for decades, but that's not
actually coded anywhere except in the "c2z" example, I guess.  I find
the underscore annoying since none of the other startup files have
one, though I understand the objection to doubling the "h".

> setopt HIST_IGNORE_ALL_DUPS # Ensure all history items are unique.

I'd go with just HIST_IGNORE_DUPS rather than ALL, and as for these:

> setopt HIST_REDUCE_BLANKS   # Remove insignificant whitespace.
> setopt SHARE_HISTORY        # All simultaneous sessions use the same history.

I agree with Lawrence, these are too intrusive.  SHARE_HISTORY makes
me crazy unless some sort of directory-local-history is also in use,
especially if the home directory is NFS mounted or the like.

A bunch of stuff about prompts:

Prompt colors are going to be a matter of taste; if you're going to
apply them then you have to pick a color scheme that's visible on
either a light or a dark background, since zsh doesn't control that
terminal state.  I have a white background and the yellow text in RPS2
is almost unreadable.

%F{8} and %F{12} do nothing on my terminal (ssh in Terminal.app from
Mac to Ubuntu, in this case), they just emit the same as %F{default},
so I don't know what you're after with those.  Don't use numerics.

I don't like the leading blank line in the prompt, either, but it's
not a showstopper.  Isn't coloring the prompt sufficient visual
differentiation?

I don't have a strong opinion about the PS4 prompt, but here's mine:
PS4=": %1N:%i%1(_.:%_.); "
This makes the prompt string into a ":" command ending at ";" so most
of the time you can copy-paste the PS4 output directly back to the PS1
input and hit enter to run it.  Same trick used in $HISTFILE for
extended history.  Putting extra newlines and characters like ">" in
PS4 make that impossible.

RE completion styles:

Again with the %F{8}, just to call it out.  Mostly good otherwise,
just some random grumbling:

In the completer style, _history with 12000 lines of context does not
give me warm fuzzies.

In matcher-list, I waver back and forth on using [:punct:] instead of
something more specific like [-_,.] (which is what I've used for
years).

I'm not a fan of the case-insensitive sorting attempt.

> unsetopt AUTO_PARAM_SLASH # Don't add trailing slashes to dir completions.

Why?   The comment isn't very clear either, since it's not "dir
completions" it's $foo where the expansion of $foo gives the name of a
directory.  It seems weird to do this when later on you have

> setopt AUTO_NAME_DIRS

which I would recommend against (although not strongly).

RE key bindings/line-init:

Wasn't there a sidebar into why terminfo isn't trustworthy?  In any
case, application mode is exactly the opposite of how I want my shell
behaving, unless I'm misinterpreting your code.

Don't mess with Ctrl-U.

I'm not sure I like your choices for Enter / Alt-Enter in menuselect,
because it seems to presume that the most common case is to do
menu-selection on the last word being entered for a command ... but my
experience is that I'm more often using menu-selection on the set of
command-line options, which typically have to be followed by
additional arguments.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  1:42                   ` Bart Schaefer
@ 2021-02-09  2:00                     ` Bart Schaefer
  2021-02-09  8:18                       ` Marlon Richert
  2021-02-09  8:17                     ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09  2:00 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Mon, Feb 8, 2021 at 5:42 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> In the completer style, _history with 12000 lines of context does not
> give me warm fuzzies.

Possibly if combined with the remove-all-dups and range styles this
would be better.

For the peanut gallery, the range style isn't mentioned in the
description of _history.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-08 21:57                 ` Marlon Richert
  2021-02-08 23:33                   ` Lawrence Velázquez
  2021-02-09  1:42                   ` Bart Schaefer
@ 2021-02-09  4:51                   ` dana
  2021-02-09  6:00                     ` Bart Schaefer
  2021-02-09  9:44                     ` Marlon Richert
  2 siblings, 2 replies; 114+ messages in thread
From: dana @ 2021-02-09  4:51 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 8 Feb 2021, at 15:57, Marlon Richert <marlon.richert@gmail.com> wrote:
> All right, here is my first draft:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

I want to see more of others' thoughts, but here are some initial comments.
Sorry in advance for how inherently bike-sheddy this whole process will be. :/

(Note: Any time i mention Debian below, you should probably read it as
Debian/Ubuntu/Mint/..., since they're usually all the same.)

> HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
> zstyle ':completion:*' cache-path "${XDG_CACHE_HOME:-$HOME/.cache}/zcompcache"
> compinit -d ${XDG_CACHE_HOME:-$HOME/.cache}/zcompdump

In Daniel's original zshrc, he had made HISTFILE prefer XDGBDS, but i had put
it back to the more typical ${ZDOTDIR:-$HOME}, because there's a lot of
documentation/history behind it, and storing it in different places on
different OSes could create another support head ache on top of that.

I actually don't feel strongly about whether we respect XDGBDS or not. I'm
sure a lot of Linux users would appreciate it. But in addition to the
documentation/support concerns, there are some things to consider if we do:

* I can't see any reason to respect it in some cases but not others. If we use
  it for completion data, shouldn't we use it for history and anything else?

* How should we handle systems that don't normally use XDGBDS? Should we just
  force the issue and use it everywhere? Or should we have platform-specific
  logic to fall back to ${ZDOTDIR:-$HOME}?

* I think the spec says applications should create the directories if they
  don't exist, right? So shouldn't we `mkdir -pm 0700` them (or the defaults)
  if necessary? This relates to the previous point, since you certainly can't
  assume that e.g. ~/.cache and ~/.local will exist on macOS.

* Daniel had HISTFILE using $XDG_CACHE_HOME, but it should actually be
  $XDG_DATA_HOME, shouldn't it? I think CACHE is meant for unimportant
  'implementation' data, often stuff that'll be regenerated if you delete it,
  stuff that may even be stored in tmpfs — whereas i think of my shell history
  as persistent personal data.

> HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history

I also don't have a strong opinion on .zsh_history vs .zhistory. The former is
the Debian/OMZ default, and i assume it gained popularity originally because
it's consistent with .bash_history, so i lean that way. Bart is right that the
latter is consistent with most of the other zsh files, though.

> setopt HIST_IGNORE_ALL_DUPS

This is a Debian default, which i give strong weight to, but idk, i like
HIST_IGNORE_DUPS instead. It's much less intrusive, it's the default OMZ
behaviour, and it's also the default Debian *bash* behaviour. (Both of those
also use the HIST_IGNORE_SPACE behaviour, which is why i had that in mine and
recommend it.)

> setopt HIST_REDUCE_BLANKS

I don't feel as strongly about this one, but it does feel a little like a
'pet' thing, not sure why it really needs to be there.

> setopt SHARE_HISTORY

This is a Debian/OMZ default, but it can cause issues in some configurations,
like Bart said. Don't feel super strongly, but i do lean against it.

I also think EXTENDED_HISTORY should be considered — i can't really think of
any down sides to it (?), and again it's an OMZ default.

> PS1='
> ...'

I see the appeal of multi-line prompts, but i really don't like one for a
default config. Nobody else does it afaik, and it seems likely to aggravate a
lot of people who are used to the traditional style. Putting the full $PWD in
the prompt makes it more justifiable, but i think we should just not do that.

I personally would suggest either just %1~ ($PWD base name, which is the OMZ
default) or something like %(3~|.../|)%2~ (which is similar to the Debian
default, and also about as close as we can get to the fish default without
adding a bunch of fancy logic).

> RPS1='%F{8}%D %*%f'

A time stamp in the prompt doesn't seem like something most users need, and i
personally find it confusing and unhelpful, since usually what you want to
know is when you ran the command associated with that prompt, not (as this
actually shows) when the command associated with the last prompt finished.

On prompts in general:

* Like Bart says, colours are very subjective. I'm not sure how to pick ones
  that will satisfy everyone. I can only suggest, again, taking inspiration
  from the defaults of Debian (both bash and zsh), OMZ, and fish.

* I like the right-hand prompt and use it myself, but one disadvantage it has
  is that it makes it annoying to copy and paste from your terminal. Not sure
  if it's a huge issue, but i foresee a possible future where heaps of novice
  users are including these long irritating strings of white space in their
  support requests.

* I do like the idea of encoding the return status in the prompt. I don't feel
  strongly about whether it's indicated by a colour, a symbol, and/or a
  number. I'm pretty sure red/green is the most common type of
  colour-blindness, though, so maybe a colour-only approach is not ideal.

* Whatever we pick for our prompt, should we maybe implement it using the
  prompt-theme system? I don't use it myself, so i'm not sure if it has any
  big down sides, but Debian use it in their defaults, and i guess it would
  make it a little easier for people to adopt if they don't want to use the
  rest of the file.

> zstyle ':completion:*:(functions|parameters|users)' ignored-patterns '[[:punct:]]*[[:alnum:]]*'

Not sure about this. I like hiding completion functions (which i did in mine),
because their naming format is pseudo-reserved for zsh by convention, and i've
seen many people confused by their appearance in completion possibilities. But
anything beyond that seems heavy-handed for a default.

> # Don't complete options or files if we have better things to offer.
> # Sort files case-insensitively.
> # Complete executables in command position, but not normal files.

A lot of this stuff seems over-elaborate and i worry that it could have
confusing side-effects in some cases, though i can't think of anything
specifically. One thing i definitely don't like is the _lowercase function,
since as i mentioned that naming convention is pseudo-reserved.

> export -T LS_COLORS ls_colors
> export -T ZLS_COLORS zls_colors=(

Nit-picking, but using export for this initially confused me. You're not
exporting them (and don't want to). I think you should just use typeset.

> unsetopt AUTO_PARAM_SLASH
> setopt AUTO_NAME_DIRS

Again, these seem like kind of 'pet' things, not sure why the average user
would need them.

On completion and key bindings in general, these settings require a lot of
mental energy for me to even process, so i haven't looked too closely at them
aside from what i've mentioned here. Behaviour related to menu completion,
auto-listing, &c., definitely needs some thorough consideration, though, since
i know people have strong feelings about that.

I had some other ideas when i was working on this before, but i can't recall
them at the moment. The only other thing i want to add is that `bindkey -e` is
a Debian/OMZ default, and i've seen a lot of people who had EDITOR=vi(m) but
didn't want vi mode in the shell, so i think it makes sense for a default.
People who use vi mode will know how to get it back.

Thanks for resurrecting this idea btw

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  4:51                   ` dana
@ 2021-02-09  6:00                     ` Bart Schaefer
  2021-02-09  7:30                       ` dana
  2021-02-09  9:55                       ` Marlon Richert
  2021-02-09  9:44                     ` Marlon Richert
  1 sibling, 2 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09  6:00 UTC (permalink / raw)
  To: dana; +Cc: Marlon Richert, Zsh hackers list

On Mon, Feb 8, 2021 at 8:51 PM dana <dana@dana.is> wrote:
>
> > zstyle ':completion:*' cache-path "${XDG_CACHE_HOME:-$HOME/.cache}/zcompcache"
> > compinit -d ${XDG_CACHE_HOME:-$HOME/.cache}/zcompdump
>
> I actually don't feel strongly about whether we respect XDGBDS or not.

I feel about it a lot like I feel about POSIX compatibility.  Read
into that as you will.

> * How should we handle systems that don't normally use XDGBDS? Should we just
>   force the issue and use it everywhere? Or should we have platform-specific
>   logic to fall back to ${ZDOTDIR:-$HOME}?

I would recommend ${XDG_CACHE_HOME:-${ZDOTDIR:-$HOME/.cache}} or
similar, now that you mention it.

> * I think the spec says applications should create the directories if they
>   don't exist, right? So shouldn't we `mkdir -pm 0700` them (or the defaults)
>   if necessary?

Thanks for catching that, yes.

> * I like the right-hand prompt and use it myself, but one disadvantage it has
>   is that it makes it annoying to copy and paste from your terminal.

I meant to mention

setopt TRANSIENT_RPROMPT

>   [...] i foresee a possible future where heaps of novice
>   users are including these long irritating strings of white space in their
>   support requests.

That's already a problem for some terminal types, especially when
copy-pasting a completion menu or the like.

> * I do like the idea of encoding the return status in the prompt. I don't feel
>   strongly about whether it's indicated by a colour, a symbol, and/or a
>   number. I'm pretty sure red/green is the most common type of
>   colour-blindness, though, so maybe a colour-only approach is not ideal.

I use reverse-video for this.

> * Whatever we pick for our prompt, should we maybe implement it using the
>   prompt-theme system?

That would make it less "abandonware" as it was previously accused of
being (tho if Debian uses it, it can't be considered completely
abandoned).

> > zstyle ':completion:*:(functions|parameters|users)' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
>
> Not sure about this.

I was a little puzzled by "user names beginning with punctuation" but
let it go at the time.

> > export -T LS_COLORS ls_colors
> > export -T ZLS_COLORS zls_colors=(
>
> Nit-picking, but using export for this initially confused me. You're not
> exporting them (and don't want to). I think you should just use typeset.

Good catch.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  6:00                     ` Bart Schaefer
@ 2021-02-09  7:30                       ` dana
  2021-02-09  7:34                         ` dana
  2021-02-09  9:55                       ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: dana @ 2021-02-09  7:30 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Marlon Richert, Zsh hackers list

On 9 Feb 2021, at 00:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
> I feel about it a lot like I feel about POSIX compatibility.  Read
> into that as you will.

🤔

On 9 Feb 2021, at 00:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> * I think the spec says applications should create the directories if they
>>   don't exist, right? So shouldn't we `mkdir -pm 0700` them (or the defaults)
>>   if necessary?
>
> Thanks for catching that, yes.

Actually i think the standard is referring to creating application
*sub-directories* under the base ones (e.g., $XDG_CACHE_HOME/zsh). I guess
that's the usual way to do it. But yeah, either way we'd probably need to
handle directory creation if we weren't going to just use ${ZDOTDIR:-$HOME}.

On 9 Feb 2021, at 00:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
> setopt TRANSIENT_RPROMPT

I wonder if that makes the proposed RPROMPT more or less useful though. The
thinking behind it seemed like you'd have the time there as an historical
record, and if you made it transient you'd only have the time the last command
finished executing / the current prompt appeared. And if you're in screen/tmux
or a graphical terminal, you probably already have a clock, so....

On 9 Feb 2021, at 00:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
> I was a little puzzled by "user names beginning with punctuation" but
> let it go at the time.

I actually do hide them myself, because macOS has a huge amount of
irrelevant-to-me system users with names like _timed and _hidd. I'm just not
sure if it's a good idea for every user on every platform.

btw: An improvement to the (Z)LS_COLORS stuff would be to source from
dircolors where available. Debian just do `eval "$(dircolors -b)"`, but that
overrides/exports LS_COLORS, and i'm not sure we want to be in the business of
screwing with parameters that don't belong to the shell. (Now that i think of
it, even just doing the LS_COLORS tie command could cause later profile
additions to falsely assume that LS_COLORS was set by the user.) Maybe
something like this (untested):

  typeset -T ZLS_COLORS zls_colors=( 'any defaults here' )
  if (( $+LS_COLORS )) || (( ! $+commands[dircolors] )); then
    typeset -T LS_COLORS ls_colors
    zls_colors+=( $ls_colors )
  else
    zls_colors+=( ${(s<:>):-"$(
      eval "$( dircolors -b )"; print -r - $LS_COLORS
    )"} )
  fi

Not sure if it's worth checking for gdircolors (Homebrew name), but that's a
thought too

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  7:30                       ` dana
@ 2021-02-09  7:34                         ` dana
  0 siblings, 0 replies; 114+ messages in thread
From: dana @ 2021-02-09  7:34 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Marlon Richert, Zsh hackers list

On 9 Feb 2021, at 01:30, dana <dana@dana.is> wrote:
> if (( $+LS_COLORS )) || (( ! $+commands[dircolors] )); then
>   typeset -T LS_COLORS ls_colors

Oops, that can still create LS_COLORS when it doesn't exist. You get what i
mean tho

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  1:42                   ` Bart Schaefer
  2021-02-09  2:00                     ` Bart Schaefer
@ 2021-02-09  8:17                     ` Marlon Richert
  2021-02-09  8:29                       ` Roman Perepelitsa
  2021-02-12  0:09                       ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-09  8:17 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Tue, Feb 9, 2021 at 3:42 AM Bart Schaefer <schaefer@brasslantern.com> wrote:

Thanks for your suggestions! I will apply most of them; maybe even all
of them. I just have a couple of questions/remarks about some of them:

> %F{8} and %F{12} do nothing on my terminal (ssh in Terminal.app from
> Mac to Ubuntu, in this case), they just emit the same as %F{default},
> so I don't know what you're after with those.  Don't use numerics.

I can change it, but I want to note that I happen to use macOS's
Terminal.app to ssh to an Ubuntu server, too, and it works fine for me
there.

> I don't have a strong opinion about the PS4 prompt, but here's mine:
> PS4=": %1N:%i%1(_.:%_.); "
> This makes the prompt string into a ":" command ending at ";" so most
> of the time you can copy-paste the PS4 output directly back to the PS1
> input and hit enter to run it.  Same trick used in $HISTFILE for
> extended history.  Putting extra newlines and characters like ">" in
> PS4 make that impossible.

That's a nice trick. :) Here's my own PS4:

local dim=$'%{\e[02m%}'
typeset -gH PS4prv='foo'
typeset -gH PS4cur=$'\n%e %F{g}%N%f '${dim}$'%x\n'
PS4=$'%(?,,\t→ %F{r}%?%f\n)'
PS4+=$'${${${(%)PS4prv}:#${(%)PS4cur}}:+${PS4prv::=${(%)PS4cur}}}'
PS4+=${dim}$'%I%b\t%(1_,%F{y}%_%f ,)'

But I felt that was a bit too complex for new users. ;) The output is
very nice, though. :)

> RE key bindings/line-init:
>
> Wasn't there a sidebar into why terminfo isn't trustworthy?  In any
> case, application mode is exactly the opposite of how I want my shell
> behaving, unless I'm misinterpreting your code.

If we don't put the terminal into application mode, then we cannot use
terminfo. Also, my takeaway from the sidebar was not that terminfo
isn't trustworthy; just that it doesn't account for _everything._ Not
using terminfo is even less trustworthy. If we don't put the terminal
into application mode, then from where are we going to get the key
codes we need? Plus, there doesn't appear to be any viable
alternatives to terminfo.

> Don't mess with Ctrl-U.

Why not? Control-U does backward-kill-line everywhere, except in Zsh.
It's annoying to get the whole line killed by Control-U _and_ not to
have a default key binding for backward-kill-line.

> I'm not sure I like your choices for Enter / Alt-Enter in menuselect,
> because it seems to presume that the most common case is to do
> menu-selection on the last word being entered for a command ... but my
> experience is that I'm more often using menu-selection on the set of
> command-line options, which typically have to be followed by
> additional arguments.

I didn't make any such assumption. I use menu selection quite at
random; mostly when I cannot get what I want at the top of the list by
typing. Can you please explain how you came to that conclusion and how
my choice of menuselect bindings would impact your case?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  2:00                     ` Bart Schaefer
@ 2021-02-09  8:18                       ` Marlon Richert
  2021-02-09 23:09                         ` Bart Schaefer
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-09  8:18 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Tue, Feb 9, 2021 at 4:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> For the peanut gallery, the range style isn't mentioned in the
> description of _history.

Sorry, but what does that mean?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  8:17                     ` Marlon Richert
@ 2021-02-09  8:29                       ` Roman Perepelitsa
  2021-02-09 23:16                         ` Bart Schaefer
  2021-02-12  0:09                       ` Bart Schaefer
  1 sibling, 1 reply; 114+ messages in thread
From: Roman Perepelitsa @ 2021-02-09  8:29 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Bart Schaefer, Zsh hackers list

On Tue, Feb 9, 2021 at 9:18 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 3:42 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> > %F{8} and %F{12} do nothing on my terminal (ssh in Terminal.app from
> > Mac to Ubuntu, in this case), they just emit the same as %F{default},
> > so I don't know what you're after with those.  Don't use numerics.
>
> I can change it, but I want to note that I happen to use macOS's
> Terminal.app to ssh to an Ubuntu server, too, and it works fine for me
> there.

It's a matter of TERM. If you set TERM=xterm, you'll see that all
colors with the codes above 7 look like the default.

I agree with Bart that the default zsh config should stick to 8 colors
(red, green, yellow, etc.). People do use terminals with 8 colors: the
non-graphical terminal in Linux, the embedded terminal in Emacs, a
bunch of terminals on Windows, etc.

Roman.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  4:51                   ` dana
  2021-02-09  6:00                     ` Bart Schaefer
@ 2021-02-09  9:44                     ` Marlon Richert
  2021-02-09 18:13                       ` Greg Klanderman
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-09  9:44 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

On Tue, Feb 9, 2021 at 6:51 AM dana <dana@dana.is> wrote:
> Sorry in advance for how inherently bike-sheddy this whole process will be. :/

That's OK. Besides doing software development, I also work as a UX
designer. I'm used to getting critiqued and lots of people having
opinions. :)

I will adapt most or all of your suggestions, but I do have some
comments/questions regarding some of your remarks:

> > zstyle ':completion:*:(functions|parameters|users)' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
>
> Not sure about this. I like hiding completion functions (which i did in mine),
> because their naming format is pseudo-reserved for zsh by convention, and i've
> seen many people confused by their appearance in completion possibilities. But
> anything beyond that seems heavy-handed for a default.

There are various Zsh plugins and plugin managers that mark private
functions and parameters with various punctuation prefixes. It's
annoying to get these randomly inserted into completions and makes the
completion system that much harder to use. Since there is no
consistency between plugins & plugin managers what prefix to use for
private functions and all punctuation symbols appear to be fair game,
I prefer to use a blanket ignore pattern like this. I haven't yet
found a case where it would hide something that I would actually want
to see. Additionally, as someone else pointed out, macOS has a ton of
system users with names that start with underscores. You generally
don't want to see those either.

> One thing i definitely don't like is the _lowercase function,
> since as i mentioned that naming convention is pseudo-reserved.

Well, that function is used for completions, so I felt that it made it
OK to use the _ prefix. However, I will happily remove the lowercase
sorting logic altogether.

> Thanks for resurrecting this idea btw

You're welcome. Thanks for your thoughtful comments. :)


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  6:00                     ` Bart Schaefer
  2021-02-09  7:30                       ` dana
@ 2021-02-09  9:55                       ` Marlon Richert
  2021-02-09 10:01                         ` Roman Perepelitsa
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-09  9:55 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dana, Zsh hackers list

On Tue, Feb 9, 2021 at 8:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > * Whatever we pick for our prompt, should we maybe implement it using the
> >   prompt-theme system?
>
> That would make it less "abandonware" as it was previously accused of
> being (tho if Debian uses it, it can't be considered completely
> abandoned).

I can definitely make it use the prompt theme system. I have nothing
against that and it would be great if it would see some active
development. I want to point out, though, that Debian "uses" it in
exactly _one_ place:
https://salsa.debian.org/debian/zsh/-/blob/debian/debian/newuser.zshrc.recommended#L3

autoload -Uz promptinit
promptinit
prompt adam1

And that's it. They don't add any new prompt themes to it or use it in
any other way. It's just those 3 lines.

> I was a little puzzled by "user names beginning with punctuation" but
> let it go at the time.

As someone else pointed out: macOS. It has quite a few of them:

_amavisd                _eppc                   _netstatistics
_analyticsd             _findmydevice           _networkd
_appinstalld            _fpsd                   _nsurlsessiond
_appleevents            _ftp                    _nsurlstoraged
_applepay               _fud                    _oahd
_appowner               _gamecontrollerd        _ondemand
_appserver              _geod                   _postfix
_appstore               _hidd                   _postgres
_ard                    _iconservices           _qtss
_assetcache             _installassistant       _reportmemoryexception
_astris                 _installcoordinationd   _rmd
_atsserver              _installer              _sandbox
_avbdeviced             _jabber                 _screensaver
_calendar               _kadmin_admin           _scsd
_captiveagent           _kadmin_changepw        _securityagent
_ces                    _knowledgegraphd        _serialnumberd
_clamav                 _krb_anonymous          _softwareupdate
_cmiodalassistants      _krb_changepw           _spotlight
_coreaudiod             _krb_kadmin             _sshd
_coremediaiod           _krb_kerberos           _svn
_coreml                 _krb_krbtgt             _taskgated
_ctkd                   _krbfast                _teamsserver
_cvmsroot               _krbtgt                 _timed
_cvs                    _launchservicesd        _timezone
_cyrus                  _lda                    _tokend
_datadetectors          _locationd              _trustevaluationagent
_demod                  _logd                   _unknown
_devdocs                _lp                     _update_sharing
_devicemgr              _mailman                _usbmuxd
_diskimagesiod          _mbsetupuser            _uucp
_displaypolicyd         _mcxalr                 _warmd
_distnote               _mdnsresponder          _webauthserver
_dovecot                _mobileasset            _windowserver
_dovenull               _mysql                  _www
_dpaudio                _nearbyd                _wwwproxy
_driverkit              _netbios                _xserverdocs


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  9:55                       ` Marlon Richert
@ 2021-02-09 10:01                         ` Roman Perepelitsa
  2021-02-09 10:04                           ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Roman Perepelitsa @ 2021-02-09 10:01 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Bart Schaefer, dana, Zsh hackers list

On Tue, Feb 9, 2021 at 10:56 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 8:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > > * Whatever we pick for our prompt, should we maybe implement it using the
> > >   prompt-theme system?
> >
> > That would make it less "abandonware" as it was previously accused of
> > being (tho if Debian uses it, it can't be considered completely
> > abandoned).
>
> I can definitely make it use the prompt theme system.

Prompt is one of the main things users want to customize in zle. I
think more people are interested in customizing prompt than
customizing key bindings. It's important to make it easy for them to
do things like changing colors or adding emojis (seriously). These are
much easier if PS1 definition is inlined. I'm afraid that promptinit
is too difficult an abstraction to penetrate.

Roman.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 10:01                         ` Roman Perepelitsa
@ 2021-02-09 10:04                           ` Marlon Richert
  2021-02-09 10:56                             ` dana
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-09 10:04 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Bart Schaefer, dana, Zsh hackers list

On Tue, Feb 9, 2021 at 12:01 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 10:56 AM Marlon Richert <marlon.richert@gmail.com> wrote:
> >
> > On Tue, Feb 9, 2021 at 8:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > > > * Whatever we pick for our prompt, should we maybe implement it using the
> > > >   prompt-theme system?
> > >
> > > That would make it less "abandonware" as it was previously accused of
> > > being (tho if Debian uses it, it can't be considered completely
> > > abandoned).
> >
> > I can definitely make it use the prompt theme system.
>
> Prompt is one of the main things users want to customize in zle. I
> think more people are interested in customizing prompt than
> customizing key bindings. It's important to make it easy for them to
> do things like changing colors or adding emojis (seriously). These are
> much easier if PS1 definition is inlined. I'm afraid that promptinit
> is too difficult an abstraction to penetrate.

Bart, Dana: What exactly do you see as the upside of using the prompt
theme system? What does the user gain from taking it into use?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 10:04                           ` Marlon Richert
@ 2021-02-09 10:56                             ` dana
  2021-02-09 11:14                               ` Roman Perepelitsa
  2021-02-09 11:39                               ` Marlon Richert
  0 siblings, 2 replies; 114+ messages in thread
From: dana @ 2021-02-09 10:56 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Roman Perepelitsa, Bart Schaefer, Zsh hackers list

On 9 Feb 2021, at 03:44, Marlon Richert <marlon.richert@gmail.com> wrote:
> There are various Zsh plugins and plugin managers that mark private
> functions and parameters with various punctuation prefixes. It's
> annoying to get these randomly inserted into completions and makes the
> completion system that much harder to use.

You're talking about like the z-asug and z-sy-h stuff? I guess that's true.
The completion system also uses some parameters like _comps that probably
aren't useful to complete in most cases. I don't know, maybe i was being too
conservative after all. What do others think?

What other characters besides _ do you know of that are used as prefixes? If
that's the only one, we could at least err on the side of limiting it to
that...?

On 9 Feb 2021, at 03:44, Marlon Richert <marlon.richert@gmail.com> wrote:
> Additionally, as someone else pointed out, macOS has a ton of
> system users with names that start with underscores. You generally
> don't want to see those either.

On macOS, that's probably true. Like i said, i do hide them myself. I just
don't know about other systems and use cases. Does anyone else have an
opinion? If it seems risky elsewhere, but OK for macOS, we could gate it
behind [[ $OSTYPE == darwin* ]], i guess.

On 9 Feb 2021, at 03:44, Marlon Richert <marlon.richert@gmail.com> wrote:
> Well, that function is used for completions, so I felt that it made it
> OK to use the _ prefix. However, I will happily remove the lowercase
> sorting logic altogether.

At first glance the sorting logic does seem a bit elaborate like i said, but
idk. If you do want to define any functions for the config, i would just make
sure to give them names that aren't likely to conflict with anything else.
_lowercase seems really generic. You could at least make it, like...
_zshrc_lowercase, or something.

On 9 Feb 2021, at 04:04, Marlon Richert <marlon.richert@gmail.com> wrote:
> Bart, Dana: What exactly do you see as the upside of using the prompt
> theme system? What does the user gain from taking it into use?

I just thought it'd be nice to have an easy way for people who are already
invested in prompt themes to switch to whatever this cool new prompt is going
to be (without having to hunt down the template file and copy/paste).

I assume Roman's concern is that prompt themes are too 'magic' for a default
config that's partially meant to show new users how to customise the shell to
their liking, which is fair.

I'm definitely not married to the idea, we can just do it 'raw' in the zshrc.

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 10:56                             ` dana
@ 2021-02-09 11:14                               ` Roman Perepelitsa
  2021-02-09 11:39                               ` Marlon Richert
  1 sibling, 0 replies; 114+ messages in thread
From: Roman Perepelitsa @ 2021-02-09 11:14 UTC (permalink / raw)
  To: dana; +Cc: Marlon Richert, Bart Schaefer, Zsh hackers list

On Tue, Feb 9, 2021 at 11:56 AM dana <dana@dana.is> wrote:
>
> What other characters besides _ do you know of that are used as prefixes? If
> that's the only one, we could at least err on the side of limiting it to
> that...?

In my code I nowadays start internal functions with '-':

  function -z4h-foo-bar() { ... }

Here z4h is a project-specific prefix.

I use '-' because it's consistent with my word delimiter of choice for
function names, and because it's not '_' (I use the latter only for
completion functions).

I think ignoring functions, parameters and users that start with
[:punkt:] is fine. It's not uncommon for completions to draw an
arbitrary line between showing not enough and showing too much.

> At first glance the sorting logic does seem a bit elaborate like i said, but
> idk. If you do want to define any functions for the config, i would just make
> sure to give them names that aren't likely to conflict with anything else.
> _lowercase seems really generic. You could at least make it, like...
> _zshrc_lowercase, or something.

It would be great if the config didn't define any functions. Custom
sorting is something I would give up without second thoughts if it
means the config gets shorter and simpler.

There is a threshold of config length and complexity after which users
will treat it as a magic back box. It's different for different users
but for the vast majority of users it's very low. Every extra line,
and especially every new concept or abstraction, will cause some users
to lose control over their shell configuration. Users who can tolerate
more complexity can easily increase it. Users who cannot comprehend
the config won't be able to simplify it.

> I assume Roman's concern is that prompt themes are too 'magic' for a default
> config that's partially meant to show new users how to customise the shell to
> their liking, which is fair.

Correct, that's what I meant.

Once again, users who prefer to use advanced features will be able to
do that. Many will want to use third party plugins and themes, and
that's fine. Our job here is to provide foundation. It won't
necessarily be the best but it should be very simple and amenable to
customization.

Roman.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 10:56                             ` dana
  2021-02-09 11:14                               ` Roman Perepelitsa
@ 2021-02-09 11:39                               ` Marlon Richert
  2021-02-09 17:21                                 ` dana
  2021-02-09 23:05                                 ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-09 11:39 UTC (permalink / raw)
  To: dana; +Cc: Roman Perepelitsa, Bart Schaefer, Zsh hackers list

On Tue, Feb 9, 2021 at 12:56 PM dana <dana@dana.is> wrote:
> What other characters besides _ do you know of that are used as prefixes? If
> that's the only one, we could at least err on the side of limiting it to
> that...?

I have used . (dot) as a prefix. I have also used and seen : (colon).
But if you really want to see someone go wild with prefixes, check out
the Zinit code: https://github.com/zdharma/zinit/blob/master/zinit.zsh

It uses : (colon), . (dot), @, + and - (dash). And since Zinit is
quite popular and thus influential, this has influenced other plugin
developers, too. Plus, Zinit's author actively advocates using a whole
bunch of different prefixes in this document, which I've seen
references to in several plugins:
https://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html#_the_proposed_function_name_prefixes

The list there includes . (dot), → (arrow right), +, / (slash) and @.
So, yeah, there's plenty of prefixes out there.

> On macOS, that's probably true. Like i said, i do hide them myself. I just
> don't know about other systems and use cases. Does anyone else have an
> opinion? If it seems risky elsewhere, but OK for macOS, we could gate it
> behind [[ $OSTYPE == darwin* ]], i guess.

How is it risky? If you need to find a username that starts with a
certain prefix, then you will still be able to find it by typing said
prefix. We have included the _ignored completer, after all.

> I just thought it'd be nice to have an easy way for people who are already
> invested in prompt themes to switch to whatever this cool new prompt is going
> to be (without having to hunt down the template file and copy/paste).

Ah, you mean, define the prompt in the system, rather than in this
.zshrc file? Yeah, that could make sense.

> I assume Roman's concern is that prompt themes are too 'magic' for a default
> config that's partially meant to show new users how to customise the shell to
> their liking, which is fair.

Actually, I am currently working on a prompt system of my own (not
published anywhere yet). But instead of making this separate plugin, I
could of course consider contributing this back "upstream" in the form
of improvements to promptinit & co. Would that be something that you'd
be interested in? I can of course first publish the code, so you can
actually see what I'm talking about.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 11:39                               ` Marlon Richert
@ 2021-02-09 17:21                                 ` dana
  2021-02-09 21:01                                   ` Marlon Richert
  2021-02-09 23:05                                 ` Bart Schaefer
  1 sibling, 1 reply; 114+ messages in thread
From: dana @ 2021-02-09 17:21 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Roman Perepelitsa, Bart Schaefer, Zsh hackers list

On 9 Feb 2021, at 05:39, Marlon Richert <marlon.richert@gmail.com> wrote:
> But if you really want to see someone go wild with prefixes, check out
> the Zinit code: https://github.com/zdharma/zinit/blob/master/zinit.zsh

Oh yeah, i forgot, lol

On 9 Feb 2021, at 05:39, Marlon Richert <marlon.richert@gmail.com> wrote:
> How is it risky? If you need to find a username that starts with a
> certain prefix, then you will still be able to find it by typing said
> prefix. We have included the _ignored completer, after all.

People often use completion to find possibilities they aren't aware of ahead
of time, or to see what the total set of possibilities is. (At least i
certainly do — it's actually one of the *main* things i use it for.) And since
this is a config for novices, i'm afraid that we might trick them into
believing that certain possibilities don't even exist. If they don't know
they're there in the first place, it will never occur to them to try manually
entering a _ or whatever before completing.

... But i also think you have to balance that fear with what's likely to be
the most convenient for the most people. So i don't know. I am starting to
feel like there's more merit to it than i initially gave it; i just want to
make sure we don't confuse or inconvenience many people.

On 9 Feb 2021, at 05:39, Marlon Richert <marlon.richert@gmail.com> wrote:
> Ah, you mean, define the prompt in the system, rather than in this
> .zshrc file? Yeah, that could make sense.

Yeah, but Roman's point is very good. I guess if we wanted to we could just
maintain it in both places, it's only a few variable assignments. But it's not
a big deal either way, it was just an idle thought.

On 9 Feb 2021, at 05:39, Marlon Richert <marlon.richert@gmail.com> wrote:
> Actually, I am currently working on a prompt system of my own (not
> published anywhere yet). But instead of making this separate plugin, I
> could of course consider contributing this back "upstream" in the form
> of improvements to promptinit & co. Would that be something that you'd
> be interested in? I can of course first publish the code, so you can
> actually see what I'm talking about.

Like i said, i don't personally use prompt themes, and probably never will, so
i may not be the one to ask. But ideas for improvement are welcome in general,
of course

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  9:44                     ` Marlon Richert
@ 2021-02-09 18:13                       ` Greg Klanderman
  0 siblings, 0 replies; 114+ messages in thread
From: Greg Klanderman @ 2021-02-09 18:13 UTC (permalink / raw)
  To: zsh-workers

>>>>> On February 9, 2021 Marlon Richert <marlon.richert@gmail.com> wrote:

>> > zstyle ':completion:*:(functions|parameters|users)' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
>> 
>> Not sure about this. I like hiding completion functions (which i did in mine),
>> because their naming format is pseudo-reserved for zsh by convention, and i've
>> seen many people confused by their appearance in completion possibilities. But
>> anything beyond that seems heavy-handed for a default.

> There are various Zsh plugins and plugin managers that mark private
> functions and parameters with various punctuation prefixes. It's
> annoying to get these randomly inserted into completions and makes the
> completion system that much harder to use. Since there is no
> consistency between plugins & plugin managers what prefix to use for
> private functions and all punctuation symbols appear to be fair game,
> I prefer to use a blanket ignore pattern like this. I haven't yet
> found a case where it would hide something that I would actually want
> to see. Additionally, as someone else pointed out, macOS has a ton of
> system users with names that start with underscores. You generally
> don't want to see those either.

FWIW you can also use the prefix-needed zstyle for this purpose,
for commands, functions, and parameter names:

from Etc/ChangeLog-4.3:
|2011-03-08  Barton E. Schaefer  <schaefer@zsh.org>
|
|        * Greg Klanderman: 28846: Completion/Zsh/Type/_functions,
|        Completion/Zsh/Type/_command_names,
|        Completion/Zsh/Type/_parameters, Doc/Zsh/compsys.yo: adapt
|        prefix-needed zstyle to handle the completion function naming
|        convention of a leading underscore.

Maybe the set of hard-coded prefixes should be expanded from [^_.]
though; I do not use and plugins so it has not been a problem for me.

Greg


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 17:21                                 ` dana
@ 2021-02-09 21:01                                   ` Marlon Richert
  2021-02-09 21:41                                     ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-09 21:01 UTC (permalink / raw)
  To: dana; +Cc: Roman Perepelitsa, Bart Schaefer, Zsh hackers list

On Tue, Feb 9, 2021 at 7:21 PM dana <dana@dana.is> wrote:
> People often use completion to find possibilities they aren't aware of ahead
> of time, or to see what the total set of possibilities is. (At least i
> certainly do — it's actually one of the *main* things i use it for.) And since
> this is a config for novices, i'm afraid that we might trick them into
> believing that certain possibilities don't even exist. If they don't know
> they're there in the first place, it will never occur to them to try manually
> entering a _ or whatever before completing.

I have yet to encounter a function, parameter or username starting
with punctuation that was meant for general end user consumption. In
fact, all of the examples I've encountered in the wild appear to have
been named so exactly to discourage the average user from touching
them.

> ... But i also think you have to balance that fear with what's likely to be
> the most convenient for the most people. So i don't know. I am starting to
> feel like there's more merit to it than i initially gave it; i just want to
> make sure we don't confuse or inconvenience many people.

I run a similar config in my plugin zsh-autocomplete and I have yet to
hear any complaints about this from any of its 500+ users. :)

> On 9 Feb 2021, at 05:39, Marlon Richert <marlon.richert@gmail.com> wrote:
> > Actually, I am currently working on a prompt system of my own (not
> > published anywhere yet). But instead of making this separate plugin, I
> > could of course consider contributing this back "upstream" in the form
> > of improvements to promptinit & co. Would that be something that you'd
> > be interested in? I can of course first publish the code, so you can
> > actually see what I'm talking about.
>
> Like i said, i don't personally use prompt themes, and probably never will, so
> i may not be the one to ask. But ideas for improvement are welcome in general,
> of course

Actually, what I'm making is not a theme or even a set of themes, but
rather a set of tools to make it easier for end users to build their
own custom prompt.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 21:01                                   ` Marlon Richert
@ 2021-02-09 21:41                                     ` Marlon Richert
  2021-02-09 23:15                                       ` dana
  2021-02-10  2:30                                       ` Bart Schaefer
  0 siblings, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-09 21:41 UTC (permalink / raw)
  To: Zsh hackers list
  Cc: dana, Roman Perepelitsa, Bart Schaefer, Daniel Shahaf,
	Lawrence Velázquez

All right, I incorporated all of your feedback as well as I could,
save for the promptinit idea (since that's going to take a bit more
work). Here's the diff:
https://gitlab.com/marlonrichert/zsh-sensible/-/commit/3d867257b7dcdb7826bc07f44756ba30bf539fda?w=1

More feedback welcome. :)


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-07 17:10           ` Marlon Richert
                               ` (2 preceding siblings ...)
  2021-02-08  6:35             ` Daniel Shahaf
@ 2021-02-09 21:44             ` Eric Cook
  2021-02-09 22:34               ` Bart Schaefer
  3 siblings, 1 reply; 114+ messages in thread
From: Eric Cook @ 2021-02-09 21:44 UTC (permalink / raw)
  To: zsh-workers

On 2/7/21 12:10 PM, Marlon Richert wrote:

>> - Inline the prompt definition instead of using promptinit. This makes it much easier for users to customize prompt. Abstractions are a serious barrier for beginners.
>
> prompinit is one of those autoloadable functions that in theory feel
> like a very good idea, but feels like abandonware in practice. I would
> love for it to get the same amount of care as compinit does, but as it
> stands, it really doesn't do much at all.
>
Just to nichepick, the completion system is largely as static as the prompt system.
The part of the completion system that is usually worked on, is the definitions for commands,
which the equivalent for the prompt system would be prompts. how either of them work in general,
rarely changes.

it may /feel/ like abandonware since users don't create prompts using it often, whether they
know it exists at all, are just used to setting PS1 like in other shells or something else.

ironically enough, stuff like powerlevel10k pretty much create their own prompt system just to
configure their sole prompts.



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 21:44             ` Eric Cook
@ 2021-02-09 22:34               ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09 22:34 UTC (permalink / raw)
  To: Eric Cook; +Cc: zsh-workers

On Tue, Feb 9, 2021 at 1:45 PM Eric Cook <llua@gmx.com> wrote:
>
> Just to nichepick, the completion system is largely as static as the prompt system.

Just to nitpick, it's from "pick nits", as in, remove lice eggs from
your hair.  No criticism implied; I thought you might want to know ...
and if "niche" was an intentional pun, it's a good one.

> it may /feel/ like abandonware since users don't create prompts using it often, whether they
> know it exists at all, are just used to setting PS1 like in other shells or something else.

The theme system was created with the intention of giving users a way
to turn complicated prompts on and off, so that they could try out
different appearances without having to repeatedly edit their config
files and restart their shell.

Some of the themes are simple enough that they really could just be
copied into the user's init file.  Others (like, well, "prompt bart")
install a bunch of helpers, allow you to plug in your own color
scheme, etc.  Unsurprisingly, I use "prompt bart" and give it a
different set of colors on hosts with different purposes or
identities.  I find things like using different border or background
colors to be too distracting/jarring; coloring the prompt is
sufficient.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 11:39                               ` Marlon Richert
  2021-02-09 17:21                                 ` dana
@ 2021-02-09 23:05                                 ` Bart Schaefer
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09 23:05 UTC (permalink / raw)
  To: Marlon Richert; +Cc: dana, Roman Perepelitsa, Zsh hackers list

Trying to selectively reply here since gmail makes it nearly
impossible to reply to a whole thread ...

On Tue, Feb 9, 2021 at 3:39 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> https://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html#_the_proposed_function_name_prefixes
>
> The list there includes . (dot), → (arrow right), +, / (slash) and @.

Oh golly, Sebastian.  Arrow right?  Really?

> How is it risky? If you need to find a username that starts with a
> certain prefix, then you will still be able to find it by typing said
> prefix. We have included the _ignored completer, after all.

I'm fine with this.  I've used MacOS for several years now and never
noticed all those user names starting with an underscore (probably
because I'm the only real user and never have to use tilde as a prefix
to anything but a slash).  Am I hallucinating that UNIX user names
were at one time required to start with an alphabetic?

> Actually, I am currently working on a prompt system of my own (not
> published anywhere yet). But instead of making this separate plugin, I
> could of course consider contributing this back "upstream" in the form
> of improvements to promptinit & co. Would that be something that you'd
> be interested in?

Sure.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  8:18                       ` Marlon Richert
@ 2021-02-09 23:09                         ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09 23:09 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Tue, Feb 9, 2021 at 12:19 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 4:00 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > For the peanut gallery, the range style isn't mentioned in the
> > description of _history.
>
> Sorry, but what does that mean?

Apologies for the idiom: "peanut gallery" refers to those watching but
not participating, like the crowd at an old-time circus eating
peanuts.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 21:41                                     ` Marlon Richert
@ 2021-02-09 23:15                                       ` dana
  2021-02-10  0:02                                         ` Bart Schaefer
  2021-02-10  6:57                                         ` Marlon Richert
  2021-02-10  2:30                                       ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: dana @ 2021-02-09 23:15 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 9 Feb 2021, at 15:41, Marlon Richert <marlon.richert@gmail.com> wrote:
> More feedback welcome. :)

Thanks

> zmodload -F zsh/files b:zf_mkdir

afaik this module isn't guaranteed to be available. In most cases it will be,
but i've mentioned on here before my adventures with zsh on ipkg/opkg systems.
Then again, if you don't have the files module you probably don't have the
newuser module either, so it's *probably* fine...?

> setopt INC_APPEND_HISTORY_TIME
> setopt HIST_EXPIRE_DUPS_FIRST

No objections to these personally

> PS1='%F{magenta}%$(( [#10] .2 * COLUMNS ))>..>%n%f@%F{cyan}%M%f%>>:'
> PS1+='%B%F{blue}%$(( [#10] .2 * COLUMNS ))<..<%~%b%<< '

The %M (instead of %m) feels excessive. Ellipses have three dots, not two (see
below also)

> PS1+='%(?,%F{green},%F{black}%K{red})%#%f%k '

I like this, seems like a nice accessibility compromise

> RPS1=' %(1S,%S${SECONDS}s%s ,)%w %T'

Again the time stamp actually feels *less* useful with transient RPROMPT than
it already did to me, and i'm also not sure if the average user really wants
the execution time, but i'll go along with however the others feel (see below
also)

> setopt PROMPT_SUBST

I think most of the devs discourage PROMPT_SUBST. If nothing else it feels a
bit advanced for what we're trying to achieve here

> :zshrc:timer() { SECONDS=0 }

This function naming convention is OK with me. But i don't like the behaviour,
it renders the manual's explanation of SECONDS confusingly false and it will
cause problems for people who want to use it for timing other things

> # If $LS_COLORS hasn't been defined, try to generate it.

Again, is this our business? I'm OK with *using* LS_COLORS/dircolors when
available, but *setting* it? This is an environment variable for a third-party
tool. It's one thing for a distro packager to do it, but i'm not sure we as
shell devs should mess with it. Otherwise, why not set their GREP_COLORS and
whatever else too?

And if it's *not* our business, i think we should take care to avoid making it
appear set when it wasn't already. (I'm not sure if the recent 'declared null'
stuff impacts this, haven't updated in a bit, but in 5.8 `typeset -T` will
cause e.g. $+LS_COLORS to yield 1)

> zstyle ':completion:*' cache-path "$_zcachedir/compcache"

This should be $zcachedir, right?

> zf_mkdir -pm 0700 $zcachedir

I'm sure nobody will ever do ZDOTDIR=-foo but just in case we can probably add
the -- to these mkdirs. All the XDGBDS stuff makes sense to me otherwise

> setopt AUTO_CD ...

I know some of these cd settings are OMZ defaults. I'm ambivalent about most
of them, but i don't think i like CHASE_LINKS. It can cause people who are
used to the standard behaviour (used by other shells afaik?) to lose track of
where they are. But let's see what everyone else thinks

> unsetopt CASE_GLOB
> setopt EXTENDED_GLOB

I like NO_CASE_GLOB. I also personally like EXTENDED_GLOB, but i wonder if
others will object? It's actually not an OMZ default, i don't think, possibly
because it confuses bash converts

> setopt GLOB_DOTS

Don't like that, seems unexpected and risky

> setopt GLOB_STAR_SHORT
> setopt NUMERIC_GLOB_SORT

Ambivalent

> unsetopt CLOBBER

Mixed feelings. I know a lot of power users like this, and i see the appeal,
but it contradicts a lot of defaults and historical conventions

> unsetopt FLOW_CONTROL
> setopt INTERACTIVE_COMMENTS

I like these. Doubt the average user needs flow-control sequences, and
interactive comments matches the default bash and OMZ behaviour

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  8:29                       ` Roman Perepelitsa
@ 2021-02-09 23:16                         ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-09 23:16 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Marlon Richert, Zsh hackers list

On Tue, Feb 9, 2021 at 12:29 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 9:18 AM Marlon Richert <marlon.richert@gmail.com> wrote:
> >
> > On Tue, Feb 9, 2021 at 3:42 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > > %F{8} and %F{12} do nothing on my terminal (ssh in Terminal.app from
> > > Mac to Ubuntu, in this case), they just emit the same as %F{default}
> >
> > I can change it, but I want to note that I happen to use macOS's
> > Terminal.app to ssh to an Ubuntu server, too, and it works fine for me
> > there.
>
> It's a matter of TERM. If you set TERM=xterm, you'll see that all
> colors with the codes above 7 look like the default.

I've got TERM=xterm-color and it still acts that way.  I get
darker/fainter from F{8}/F{12} if I use xterm-256color.  Doesn't
usefully stand out on my white background.

Which reminds me, it's odd to have an SPROMPT without also "setopt CORRECT"?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 23:15                                       ` dana
@ 2021-02-10  0:02                                         ` Bart Schaefer
  2021-02-10  7:02                                           ` Marlon Richert
  2021-02-10  6:57                                         ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-10  0:02 UTC (permalink / raw)
  To: dana; +Cc: Marlon Richert, Zsh hackers list

I'll reply to this first and then look at the file itself when I have
more time ...

On Tue, Feb 9, 2021 at 3:15 PM dana <dana@dana.is> wrote:
>
> > zmodload -F zsh/files b:zf_mkdir
>
> Then again, if you don't have the files module you probably don't have the
> newuser module either, so it's *probably* fine...?

This ends up being something for a package maintainer ... I think it's
OK to assume the existence of most of the standard modules, the
exceptions being e.g. zsh/cap, zsh/clone, zsh/pcre

> > PS1='%F{magenta}%$(( [#10] .2 * COLUMNS ))>..>%n%f@%F{cyan}%M%f%>>:'
> > PS1+='%B%F{blue}%$(( [#10] .2 * COLUMNS ))<..<%~%b%<< '

I'm one of those people who don't like PROMPT_SUBST.

> > PS1+='%(?,%F{green},%F{black}%K{red})%#%f%k '
>
> I like this, seems like a nice accessibility compromise

The black % on red background just disappears for me, it looks like
the prompt just ends in a red block.  %F{white} maybe?

> > RPS1=' %(1S,%S${SECONDS}s%s ,)%w %T'
>
> Again the time stamp actually feels *less* useful with transient RPROMPT

Also, you can get the elapsed time from something like ${${=$(fc -lD
-1)}[2]} instead of constantly resetting/reading $SECONDS (are the
fractional seconds really necessary?)

> > :zshrc:timer() { SECONDS=0 }

(see above)

> This function naming convention is OK with me.

I guess it's OK with me too.

> > # If $LS_COLORS hasn't been defined, try to generate it.
>
> Again, is this our business?
>
> And if it's *not* our business, i think we should take care to avoid making it
> appear set when it wasn't already.

Agree.

> (I'm not sure if the recent 'declared null'
> stuff impacts this [...])

Not in native zsh mode in any case.

> > setopt AUTO_CD ...
>
> I know some of these cd settings are OMZ defaults. I'm ambivalent about most
> of them, but i don't think i like CHASE_LINKS.

Agree about (not) CHASE_LINKS.

> > unsetopt CASE_GLOB
> > setopt EXTENDED_GLOB
>
> I like NO_CASE_GLOB.

I don't.  See the discussion leading up to my CASE_PATHS patch ...
NO_CASE_GLOB can cause globs that should succeed to fail, and globs
that should find a single result to return multiple results.

>I also personally like EXTENDED_GLOB, but i wonder if
> others will object?

I'm ambivalent.  I don't use it (have a wrapper function that enables
it when I need it, and hmm I just thought of what might be a better
way to do that) but it doesn't really cause that much issue if you
don't use the syntax.

> > setopt GLOB_DOTS
>
> Don't like that, seems unexpected and risky

Agree.

> > setopt GLOB_STAR_SHORT
> > setopt NUMERIC_GLOB_SORT
>
> Ambivalent

Me too.  I'm beginning to think I might like GLOB_STAR_SHORT but I
don't yet use it.

> > unsetopt CLOBBER
>
> Mixed feelings. I know a lot of power users like this, and i see the appeal,
> but it contradicts a lot of defaults and historical conventions

I personally do use NO_CLOBBER, but I abstain from the decision here.

> > unsetopt FLOW_CONTROL
> > setopt INTERACTIVE_COMMENTS
>
> I like these. Doubt the average user needs flow-control sequences, and
> interactive comments matches the default bash and OMZ behaviour

I like NO_FLOW_CONTROL, but I dislike INTERACTIVE_COMMENTS.  Not
strongly enough in the latter case to argue.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 21:41                                     ` Marlon Richert
  2021-02-09 23:15                                       ` dana
@ 2021-02-10  2:30                                       ` Bart Schaefer
  2021-02-10  7:44                                         ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-10  2:30 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Tue, Feb 9, 2021 at 1:42 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> https://gitlab.com/marlonrichert/zsh-sensible/-/commit/3d867257b7dcdb7826bc07f44756ba30bf539fda?w=1

> # %F{x}: set bacKground color to x;  %k: default bacKground color

Typo, should be %K{x}

> # $(( [#10] x )): cast x to int; COLUMNS: current line width of terminal

Is there any advantage to computing this with PROMPT_SUBST versus, for
example, reassigning PS1 with a new width in precmd?  Anyway if you're
already allowing the dynamic parts to consume 40% of the terminal
width I'm not sure it's worth the effort of making them dependent on
that.  Just pick a width for %n@%M and a number of trailing components
for %~.

> add-zle-hook-widget line-finish :zshrc:timer

See previous comments in other messages, but if keeping this I'd put
it in preexec instead.

> PS4=$': -> %(?,%F{g},%F{b}%K{r})%?%f%k\t%e: %F{g}%1N %f%2x:%I ;
> %(1_,%S%_%s ,)%f%k'

The :...; trick doesn't work if you have an ">" in PS4, it becomes a
redirection upon copy-paste.  I don't think you need the semicolon if
you have a newline.

> # m:{[:lower:]-}={[:upper:]_} does zsh-name -> ZSH_NAME

Doesn't work for completing parameter names, e.g. $xdg-TAB just beeps.
Is that an issue?

> typeset -T LS_COLORS ls_colors

Per previous discussion, I'd protect this with a test that LS_COLORS
is set.  Unless you've setopt WARN_CREATE_GLOBAL, the later reference
to "$ls_colors[@]" will be harmless.

Speaking of that, heh, there should be a warning comment (?) or
something that all of this expects to load in zsh native mode,
otherwise those naked subscripts etc. will break.

> () {
>  local zcachedir=${ZDOTDIR:-${XDG_CACHE_HOME:-$HOME/.cache}/zsh}

I wonder if it would be less potentially puzzling to use "function {"
here instead of empty parens?

> setopt AUTO_PUSHD # Go back to previous dirs with `cd (+|-)[<num>]` or `~(+|-)[<num>]`.

That description doesn't seem quite right to me.  The behavior of cd
doesn't depend on this option; it depends on using the directory
stack, but you can do that without AUTO_PUSHD.

I think we've commented regarding everything else.  Thanks again.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09 23:15                                       ` dana
  2021-02-10  0:02                                         ` Bart Schaefer
@ 2021-02-10  6:57                                         ` Marlon Richert
  2021-02-12  0:10                                           ` Bart Schaefer
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-10  6:57 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

On Wed, Feb 10, 2021 at 1:15 AM dana <dana@dana.is> wrote:
> > PS1='%F{magenta}%$(( [#10] .2 * COLUMNS ))>..>%n%f@%F{cyan}%M%f%>>:'
> > PS1+='%B%F{blue}%$(( [#10] .2 * COLUMNS ))<..<%~%b%<< '
>
> The %M (instead of %m) feels excessive. Ellipses have three dots, not two (see
> below also)

Would using the actual ellipsis character be OK? Or do we have to
stick to ASCII?


> > RPS1=' %(1S,%S${SECONDS}s%s ,)%w %T'
>
> Again the time stamp actually feels *less* useful with transient RPROMPT than
> it already did to me, and i'm also not sure if the average user really wants
> the execution time, but i'll go along with however the others feel (see below
> also)

I'm also trying to show off Zsh features to new users. If they don't
find it useful, they can always delete it. :)


> > setopt PROMPT_SUBST
>
> I think most of the devs discourage PROMPT_SUBST. If nothing else it feels a
> bit advanced for what we're trying to achieve here

Why exactly do you discourage the use of PROMPT_SUBST? Why is it a problem?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10  0:02                                         ` Bart Schaefer
@ 2021-02-10  7:02                                           ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-10  7:02 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dana, Zsh hackers list

On Wed, Feb 10, 2021 at 2:02 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> I like NO_FLOW_CONTROL, but I dislike INTERACTIVE_COMMENTS.  Not
> strongly enough in the latter case to argue.

I like INTERACTIVE_COMMENTS for the same reason that you use that : ;
trick: It makes it easier to paste code into the command line.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10  2:30                                       ` Bart Schaefer
@ 2021-02-10  7:44                                         ` Marlon Richert
  2021-02-10 20:27                                           ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-10  7:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Wed, Feb 10, 2021 at 4:30 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > # $(( [#10] x )): cast x to int; COLUMNS: current line width of terminal
>
> Is there any advantage to computing this with PROMPT_SUBST versus, for
> example, reassigning PS1 with a new width in precmd?  Anyway if you're
> already allowing the dynamic parts to consume 40% of the terminal
> width I'm not sure it's worth the effort of making them dependent on
> that.  Just pick a width for %n@%M and a number of trailing components
> for %~.

When using $PROMPT_SUBST, the prompt will automatically adapt when I
resize my terminal window. It might not be necessary or the fastest
solution, but it certainly does increase the "cool" factor of the
prompt. ;)


> See previous comments in other messages, but if keeping this I'd put
> it in preexec instead.

I had it in preexec initially, but then, each time you press Enter on
an empty line or use a widget that doesn't trigger preexec, then the
timer keeps increasing, which looks stupid.


> > # m:{[:lower:]-}={[:upper:]_} does zsh-name -> ZSH_NAME
>
> Doesn't work for completing parameter names, e.g. $xdg-TAB just beeps.
> Is that an issue?

You're right; it doesn't work. That's weird. It seems to fail for
$parameter substitutions only. If I create a function FOO_BAR() {} and
type foo- , then Tab completes it just fine. Likewise, if I type xdg-
without the $, it works fine, too. Even when I set the matcher-list to
just 'm:{-}={_}', $XDG- still fails, but all the other cases succeed.
Feels like a bug to me.


> Speaking of that, heh, there should be a warning comment (?) or
> something that all of this expects to load in zsh native mode,
> otherwise those naked subscripts etc. will break.

Isn't safe to assume that new users are running in Zsh native mode? Or
why would anyone want to run .zshrc when not using Zsh? Or maybe I
misunderstand. What do you mean with "zsh native mode"? It feels to me
like such a comment is excessive. If you're going to unsetopt
PROMPT_PERCENT, then the prompt will break. Should we warn against
that, too?


> > () {
> >  local zcachedir=${ZDOTDIR:-${XDG_CACHE_HOME:-$HOME/.cache}/zsh}
>
> I wonder if it would be less potentially puzzling to use "function {"
> here instead of empty parens?

I don't think so. If you don't know how anonymous functions work in
Zsh in the first place, then merelymchanging the syntax is not going
to make it any clearer. I can add a comment to explain it or then
refactor it not use an anonymous function.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10  7:44                                         ` Marlon Richert
@ 2021-02-10 20:27                                           ` Marlon Richert
  2021-02-11  8:30                                             ` Bart Schaefer
  2021-02-12 23:26                                             ` Oliver Kiddle
  0 siblings, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-10 20:27 UTC (permalink / raw)
  To: Bart Schaefer, dana, Daniel Shahaf; +Cc: Zsh hackers list

New update: https://gitlab.com/marlonrichert/zsh-sensible/-/commit/85db3c0f8c6abdcfea12017b1ba7d5d81e918490?w=1


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10 20:27                                           ` Marlon Richert
@ 2021-02-11  8:30                                             ` Bart Schaefer
  2021-02-11 21:11                                               ` Marlon Richert
  2021-02-12  5:47                                               ` Marlon Richert
  2021-02-12 23:26                                             ` Oliver Kiddle
  1 sibling, 2 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-11  8:30 UTC (permalink / raw)
  To: Marlon Richert; +Cc: dana, Daniel Shahaf, Zsh hackers list

On Wed, Feb 10, 2021 at 12:28 PM Marlon Richert
<marlon.richert@gmail.com> wrote:
>
> New update: https://gitlab.com/marlonrichert/zsh-sensible/-/commit/85db3c0f8c6abdcfea12017b1ba7d5d81e918490?w=1

I'm a bit embarrassed about this, but felt I should mention it:

> HISTFILE=${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history

My own zsh history is in $HOME, because $ZDOTDIR is maintained with
git.  A file $ZDOTDIR/history file is part of my shell startup,
sourced from .zshrc to set up the collection of history-related
variables and options.  I also avoid incremental history and have a
shell function "die" that kills the shell without allowing any history
to be written, so that I can manually control whether something I've
been doing is saved.  It never occurred to me that $HISTFILE would be
set to a name that did not begin with either a "." or a "z" or both.
Consequently when I sourced the sample zshrc to see what the prompts
etc. looked like, the commands I subsequently executed were
incrementally appended to a file that was then loaded the next time I
started a shell, which fortunately didn't do anything but alarm me.
I've now made everything in $ZDOTDIR, and the directory itself,
read-only.

This is my fault for not re-verifying that the file locations in the
sample did not conflict with any of my defaults.  I point it out
because something like this is one of the reasons that
zsh-newuser-install asks questions before choosing file locations,
which is part of what we're supposed to be discussing in this thread.

Now back to the recent changes ... I don't actually have that much
comment on the recent changes ...

> autoload -Uz compinit; compinit -d $zcachedir/compdump

I should have thought to ask about this before:  Why is this changed
from the default location?  If we feel the default is wrong, shouldn't
we be patching compinit?  (Oddly, compinit and compdump disagree on
what the default should be.)

Incidentally, I append -$ZSH_VERSION to the compdump file name.

> zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.

Hmm, I wouldn't think this was necessary after compinit.

> zstyle ':completion:*' completer _expand _complete _history _correct _ignored

Did I miss the reason for removing _oldlist?

Speaking of things I missed:

PS2='%S%_%s > '  # Left side
RPS2=' < %S%^%s' # Right side

I would suggest that if we are going to use RPS2 + TRANSIENT_RPROMPT,
that we set PS2=''.  The advantage to this is that after entering a
multi-line command, all the prompts except PS1 have disappeared, and
you have something you can copy-paste, which we've been striving for
elsewhere (e.g. PS4).

That's really about it for this pass.  I'll try to find time tomorrow
to respond to some of the earlier discussion.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-11  8:30                                             ` Bart Schaefer
@ 2021-02-11 21:11                                               ` Marlon Richert
  2021-02-11 22:57                                                 ` Bart Schaefer
  2021-02-12  5:47                                               ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-11 21:11 UTC (permalink / raw)
  To: Bart Schaefer, Daniel Shahaf, dana; +Cc: Zsh hackers list

I made some more changes. Here's the latest version:
https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-11 21:11                                               ` Marlon Richert
@ 2021-02-11 22:57                                                 ` Bart Schaefer
  2021-02-12  5:49                                                   ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-11 22:57 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Daniel Shahaf, dana, Zsh hackers list

On Thu, Feb 11, 2021 at 1:12 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> I made some more changes. Here's the latest version:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

Nothing new to say, really.  One nitpick:

PROMPT_EOL_MARK='%S%F{c}%#%s%f'

I know it probably doesn't matter, but shouldn't the states be turned
off in the opposite order that they're turned on?  That is,
%S%F...%f%s


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-09  8:17                     ` Marlon Richert
  2021-02-09  8:29                       ` Roman Perepelitsa
@ 2021-02-12  0:09                       ` Bart Schaefer
  2021-02-12  5:58                         ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-12  0:09 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Catching up on some stuff from the past couple of days ...

On Tue, Feb 9, 2021 at 12:18 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 3:42 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> > [...] application mode is exactly the opposite of how I want my shell
> > behaving, unless I'm misinterpreting your code.
>
> If we don't put the terminal into application mode, then we cannot use
> terminfo.

I'm surprised we haven't heard from Roman about this, given the
content of that reddit thread he linked back at the start of this.

> > Don't mess with Ctrl-U.
>
> Why not? Control-U does backward-kill-line everywhere, except in Zsh.

This is going to sound curmudgeonly (and it is), but the answer is
because the standard tty driver (stty) doesn't have
backward-kill-line.  ^U is "kill" not "kill to the left".

WORDCHARS='' bothers me for the same reason, I want ^W to do the same
thing whether I'm at the shell prompt or typing to a dumb stdin with
no built-in smart editor.

But, this is just my opinion, I have no pretense to veto power here.

> > I'm not sure I like your choices for Enter / Alt-Enter in menuselect,
> > because it seems to presume that the most common case is to do
> > menu-selection on the last word being entered for a command
>
> I didn't make any such assumption. I use menu selection quite at
> random; mostly when I cannot get what I want at the top of the list by
> typing. Can you please explain how you came to that conclusion and how
> my choice of menuselect bindings would impact your case?

OK, let me try to explain more fully.

My most common usage is when I am unable to remember all the
command-line options or subcommand phrases for commands such as "git".
Thus, when I enter menu selection, it's rarely the case that once I
have chosen something I want to immediately execute the command line;
the majority of those options or phrases need more words to follow.

For me, this is by far the most frequent situation.  I'd be typing
Alt-Enter (if that even works, on some keyboards it doesn't and I'd
have to type ESC followed by Enter) constantly.  It would make much
more sense to me for the single unmodified keystroke to exit the
selection but leave me at the command line, and the modified key to
mean that the command is complete and should be executed immediately.

The only time it would be obvious to me that I should instantly
execute the command after selecting from the menu is when the word
being selected is the only one remaining to form a complete command.
That's usually the last word on the line, hence my presumption about
the use case for which you made this choice of bindings.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10  6:57                                         ` Marlon Richert
@ 2021-02-12  0:10                                           ` Bart Schaefer
  2021-02-12  5:59                                             ` Roman Perepelitsa
  0 siblings, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-12  0:10 UTC (permalink / raw)
  To: Marlon Richert; +Cc: dana, Zsh hackers list

On Tue, Feb 9, 2021 at 10:58 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
[RE prompt truncation]
>
> Would using the actual ellipsis character be OK? Or do we have to
> stick to ASCII?

We probably have to aim at lower-capability terminals.  I suppose it
might make sense to check [[ -o multibyte ]] and assume the terminal
could handle the ellipsis if so, but how would multibyte become set?
In the /etc/ files?

> > > setopt PROMPT_SUBST
> >
> > I think most of the devs discourage PROMPT_SUBST. If nothing else it feels a
> > bit advanced for what we're trying to achieve here
>
> Why exactly do you discourage the use of PROMPT_SUBST? Why is it a problem?

Here's one reason:

zsh% P='${(%%)P}'
zsh% setopt promptsubst
zsh% print -P $P
zsh: segmentation fault (core dumped)  Src/zsh -f

Do that accidentally once with PS1 or RPS1, and you're locked out of your shell.

The main thing, though, is that it encourages the prompt to contain
$(fork something expensive).  If you have to think about when/where
you're capturing that output, you write better code.

(From another message)
> When using $PROMPT_SUBST, the prompt will automatically adapt when I
> resize my terminal window.

Granted.  It would be nice if the character-counting ability of
%(l.t.f) could be used in the numeric argument of %>x> and %<y<.
"prompt bart" gets around this with a TRAPWINCH, but that's out of
scope for this.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-11  8:30                                             ` Bart Schaefer
  2021-02-11 21:11                                               ` Marlon Richert
@ 2021-02-12  5:47                                               ` Marlon Richert
  2021-02-12 23:43                                                 ` Oliver Kiddle
  2021-02-13  1:11                                                 ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-12  5:47 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dana, Daniel Shahaf, Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]



> On 11. Feb 2021, at 10.30, Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is my fault for not re-verifying that the file locations in the
> sample did not conflict with any of my defaults.  I point it out
> because something like this is one of the reasons that
> zsh-newuser-install asks questions before choosing file locations,
> which is part of what we're supposed to be discussing in this thread.

Sure, I think that’s at least one thing that’s safe to ask. Something like this:

Where do you want to store Zsh config, cache and history files?

1. All in your $HOME dir.
2. All in another dir of you choosing
3. In the standard locations defined by the XDG Base Directory Specification (subdirs in ~/.config, ~/.cache and ~/.local/share, respectively, by default).


> Incidentally, I append -$ZSH_VERSION to the compdump file name.

That’s not necessary. compdump saves $ZSH_VERSION in the compdump file and compinit checks for it: https://github.com/zsh-users/zsh/blob/2cf6032a301d994c578e5e1942c4815e85651647/Completion/compinit#L491


>> zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.
> 
> Hmm, I wouldn't think this was necessary after compinit.

No, but it is necessary _before_ compinit. And compinit even has a style it checks and which should thus be set before running compinit: https://github.com/zsh-users/zsh/blob/2cf6032a301d994c578e5e1942c4815e85651647/Completion/compinit#L566


>> zstyle ':completion:*' completer _expand _complete _history _correct _ignored
> 
> Did I miss the reason for removing _oldlist?

No, I didn’t give a reason. I tried out both _list and _oldlist, but both seemed unnecessary to get the behavior I’m after.


[-- Attachment #2: Type: text/html, Size: 2949 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-11 22:57                                                 ` Bart Schaefer
@ 2021-02-12  5:49                                                   ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-12  5:49 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Daniel Shahaf, dana, Zsh hackers list


> Nothing new to say, really.  One nitpick:
> 
> PROMPT_EOL_MARK='%S%F{c}%#%s%f'
> 
> I know it probably doesn't matter, but shouldn't the states be turned
> off in the opposite order that they're turned on?  That is,
> %S%F...%f%s

I tested it and it really doesn’t seem to matter. It’s not HTML. :) 



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12  0:09                       ` Bart Schaefer
@ 2021-02-12  5:58                         ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-12  5:58 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list


>>> Don't mess with Ctrl-U.
>> 
>> Why not? Control-U does backward-kill-line everywhere, except in Zsh.
> 
> This is going to sound curmudgeonly (and it is), but the answer is
> because the standard tty driver (stty) doesn't have
> backward-kill-line.  ^U is "kill" not "kill to the left".
> 
> WORDCHARS='' bothers me for the same reason, I want ^W to do the same
> thing whether I'm at the shell prompt or typing to a dumb stdin with
> no built-in smart editor.
> 
> But, this is just my opinion, I have no pretense to veto power here.

The defaults of ^U and WORDCHARS are by far the most common complaints I’ve seen from new users. I feel very strongly we should change them.


> My most common usage is when I am unable to remember all the
> command-line options or subcommand phrases for commands such as "git".
> Thus, when I enter menu selection, it's rarely the case that once I
> have chosen something I want to immediately execute the command line;
> the majority of those options or phrases need more words to follow.

In which you can just type space or whatever else you would type when you wouldn’t be using menu selection. After all, the cursor is still on the command line and it will respond as such (with the exception of those key bindings that are overriding this in the menuselect keymap). But having said that, I’m fine with reverting this change.




^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12  0:10                                           ` Bart Schaefer
@ 2021-02-12  5:59                                             ` Roman Perepelitsa
  2021-02-13  0:23                                               ` dana
  0 siblings, 1 reply; 114+ messages in thread
From: Roman Perepelitsa @ 2021-02-12  5:59 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Marlon Richert, dana, Zsh hackers list

On Fri, Feb 12, 2021 at 1:10 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Feb 9, 2021 at 10:58 PM Marlon Richert <marlon.richert@gmail.com> wrote:
> >
> [RE prompt truncation]
> >
> > Would using the actual ellipsis character be OK? Or do we have to
> > stick to ASCII?
>
> We probably have to aim at lower-capability terminals.  I suppose it
> might make sense to check [[ -o multibyte ]] and assume the terminal
> could handle the ellipsis if so, but how would multibyte become set?
> In the /etc/ files?

There is no straightforward way to check whether the terminal can
display a specific unicode character (e.g., the ellipsis). Even if
there was, and even if the check was simple, the benefits wouldn't be
high enough to justify the extra complexity in the default zshrc.

> I'm surprised we haven't heard from Roman about this, given the
> content of that reddit thread he linked back at the start of this.

I stopped commenting on this once I realized that my vision of what
the default zshrc should include is very different from everyone
else's here. In my view only the crucial things must be included.

How much is gained from defining PS2 and PS4? I think not much. I'd
remove them without second thoughts. Or consider history setup:

    HISTFILE=${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history

    if [[ ! -d $HISTFILE:h ]]; then
      zmodload -F zsh/files b:zf_mkdir
      zf_mkdir -pm 0700 - $HISTFILE:h
    fi

    SAVEHIST=10000
    HISTSIZE=$(( 1.2 * SAVEHIST ))
    setopt EXTENDED_HISTORY
    setopt INC_APPEND_HISTORY_TIME
    setopt HIST_EXPIRE_DUPS_FIRST
    setopt HIST_IGNORE_DUPS

I'd replace it with this:

    HISTFILE=~/.zsh_history  # store command history in this file
    SAVEHIST=100000          # store at most this many commands in the file
    HISTSIZE=100000          # store at most this many commands in memory

Perhaps ${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history
is better than ~/.zsh_history (I don't know if it is) but it's so much
more complex. Ditto for all the pet peeve options and arithmetic
expansions.

As far as prompt goes, I'd leave only PS1. No right prompt.

The only non-default option I would use is INTERACTIVE_COMMENTS. This
is important to allow people to copy-paste code from StackOverflow and
the like.

The amount of complexity brought in by the bindings is very high. If
the delete/home/end keys don't work, it's a disaster. On the other
hand, the binding for `redo` can be removed without anyone noticing or
complaining. As I mentioned earlier, I wouldn't use terminfo. It makes
the config more complex for little to no benefit. It also breaks
bindings when there is no terminfo definition for $TERM. This happens
when using a terminal with exotic terminfo (e.g., alacritty,
xterm-kitty, or tmux-256color) and connecting to another machine over
ssh.

In my opinion the default config shouldn't aim to provide the best
solution to anything: the best history setup, the best prompt, etc. It
should make zsh usable by someone who considers bash usable out of the
box (e.g., on Debian) but other than that be as simple and as short as
possible. Experienced zsh users are welcome to share more elaborate
and opinionated configs through other channels.

Roman.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-10 20:27                                           ` Marlon Richert
  2021-02-11  8:30                                             ` Bart Schaefer
@ 2021-02-12 23:26                                             ` Oliver Kiddle
  2021-02-13  0:15                                               ` Marlon Richert
                                                                 ` (2 more replies)
  1 sibling, 3 replies; 114+ messages in thread
From: Oliver Kiddle @ 2021-02-12 23:26 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

I viewed the latest file from git and am commenting on that directly.

> # Use `exec zsh` to apply changes after editing this file.

Not sure I'd recommend that because if you mistype "zsh", your shell+terminal
disappears. And if they've broken .zshrc, that can leave them unable to log
back in.

> bindkey -e  # Use `emacs` as the main keymap.

I don't argue with the direct emacs binding. But would be tempted to add
a commented-out line suggesting what vi users may want to try, either
bindkey -v or:
  bindkey '\e' vi-cmd-mode

That's closer to what many vi users actually want and to what vi mode on bash does.

> HISTFILE=${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history

> # Create parent dir, if necessary.
> if [[ ! -d $HISTFILE:h ]]; then
>   zmodload -F zsh/files b:zf_mkdir
>   zf_mkdir -pm 0700 - $HISTFILE:h
> fi

I'm not sure it helps new users to understand their new setup file if it needs
this stuff. Should we just keep it simple at the expense of ignoring the XDG stuff.

> # Primary prompt, left side

> # %x<y<z%<<: if z is wider than x characters, then trim z from the left & insert y

The trunction adds complexity that I'm not sure is needed. Many people want to
know how to enable vcs_info. I'm not saying it should be included by
default but perhaps in a comment.

> PS2='%S%_%s '                           # Left side
> RPS2='Press %SAlt-Q%s to return to PS1' # Right side
> bindkey '^[q' push-line-or-edit # Alt-Q

It can be quite helpful to leave PS2 empty and put <%^ in the [transient] right
- allows for copy and paste without intervening prompts. And that doesn't mean
it can't include the hint too.

> # Spelling correction prompt
> # %R: word to correct;  %r: suggested correction
> SPROMPT='Correct %B%F{w}%K{r}%R%b%f%k to %F{g}%r%f? [%Sy%ses/%Sn%so/%Se%sdit/%Sa%sbort] '

Is it perhaps better to spell out white, red and green just to make this a
little more readable. This is also elsewhere (apart from the first case).

> ZLE_REMOVE_SUFFIX_CHARS=$' \t\n;' # Characters that remove completion suffixes.
> ZLE_SPACE_SUFFIX_CHARS=$'&|'      # Characters that instead replace them with a space.

The first of these assignments is actually redundant because the latter takes
precedence.

> zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.

Is that really needed? I've never bothered.

> # These are tried in order until one of them succeeds:
> # _expand: expansion substitutions (See http://zsh.sourceforge.net/Doc/Release/Expansion.html)
> # _complete: regular completions
> # _history: words from history
> # _correct: spelling corrections
> # _ignored: any completions that have been ignored so far
> zstyle ':completion:*' completer _expand _complete _history _correct _ignored

These seem reasonable choices. _extensions wouldn't cause any unpleasant
surprises for a new user but it does need to come first.

I'm not fond of _expand in unconfigured form - would consider some of
keep-prefix true, accept-exact continue and tag-order all-expansions.

> # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR
but not vice versa.

> # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> zstyle ':completion:*:complete:*' matcher-list \
>   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}' \
>   'r:|?=** m:{[:lower:]}={[:upper:]}'

I'd be significantly more conservative on these. They really can cause
surprises for new users and break some things completely like trying to force
the type of listed matches with punctuation prefixes.

I mostly use generous matchers with more specific contexts.
To give one example, the following helps when suspended jobs are all
man, less or vim and I want to select on the argument:
zstyle ':completion:*:(-command-|[fb]g):*:jobs' matcher 'l:%|=*'

> # For options only, add - -> + for each item in the list above.
> zstyle ':completion:*:options' matcher 'm:{-}={+}'

Isn't the more limited 'b:-=+' sufficient here? 

> # Show and insert `man` sections.
> zstyle ':completion:*' insert-sections yes

I wouldn't bother for section 1:
  zstyle ':completion:*:manuals.(^1*)' insert-sections true

Not only because it is mostly redundant but it is easier to simplify that to
all sections than to do the reverse.

> zstyle ':completion:*' separate-sections yes

That also applies elsewhere, e.g. words for dict.

> # Press Alt-Shift-Hyphen to redo (after undo).
> bindkey '^[_' redo

I'd be inclined to bind Ctrl-Z to undo. Forget Emacs and Vi - Ctrl-Z is what
the rest of the world uses for undo. That doesn't disable anything else and too
few people know the shell has an undo. It's invaluable with completion,
especially with approximate completion or the fuzzier matching controls such as
r:|?=**.

> setopt GLOB_STAR_SHORT      # Use `**` for recursive globbing; `***` to include symlinks, too.

Need to say 'without a trailing "/"' **/ is already recursive globbing
and you don't need this option to enable it.

The comment confused me but like Bart I don't use the option but found
myself wondering whether I should.

> typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath

These are tied, no need to list both forms. The -g adds nothing either
outside of a function.

Oliver


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12  5:47                                               ` Marlon Richert
@ 2021-02-12 23:43                                                 ` Oliver Kiddle
  2021-02-13  1:11                                                 ` Bart Schaefer
  1 sibling, 0 replies; 114+ messages in thread
From: Oliver Kiddle @ 2021-02-12 23:43 UTC (permalink / raw)
  To: Zsh hackers list

Marlon Richert wrote:
>     Incidentally, I append -$ZSH_VERSION to the compdump file name.
>
> That’s not necessary. compdump saves $ZSH_VERSION in the compdump file and
> compinit checks for it: [1]https://github.com/zsh-users/zsh/blob/

It's useful for someone who regularly switches between zsh versions and
wants to reduce how often they get regenerated but doesn't mind clearing
out old ones from time to time. For Bart, it likely makes sense. For the
average new user, not.

I hash the combination of $HOST and $FPATH (the latter typically
includes the version number) to create a suffix. The hostname can matter
with an NFS shared home directory which is probably not as common as it
once was.

Oliver


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12 23:26                                             ` Oliver Kiddle
@ 2021-02-13  0:15                                               ` Marlon Richert
  2021-02-13  1:33                                                 ` Bart Schaefer
  2021-02-13  1:36                                                 ` Oliver Kiddle
  2021-02-13  1:28                                               ` Bart Schaefer
  2021-04-22 13:57                                               ` Marlon Richert
  2 siblings, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-13  0:15 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

On Sat, Feb 13, 2021 at 1:26 AM Oliver Kiddle <opk@zsh.org> wrote:
> > # Use `exec zsh` to apply changes after editing this file.
>
> Not sure I'd recommend that because if you mistype "zsh", your shell+terminal
> disappears. And if they've broken .zshrc, that can leave them unable to log
> back in.

I got this tip from Roman. We've both seen new users get into all
kinds of trouble by repeatedly doing `source ~/.zshrc`.


> > HISTFILE=${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history
>
> > # Create parent dir, if necessary.
> > if [[ ! -d $HISTFILE:h ]]; then
> >   zmodload -F zsh/files b:zf_mkdir
> >   zf_mkdir -pm 0700 - $HISTFILE:h
> > fi
>
> I'm not sure it helps new users to understand their new setup file if it needs
> this stuff. Should we just keep it simple at the expense of ignoring the XDG stuff.

Bart suggested we could instead, in zsh-newuser-install, ask the users
what they would actually prefer. I think that's reasonable. I put a
suggested text in my reply to him. I will start adding the new version
of zsh-newuser-install to the repo, too.


> > # %x<y<z%<<: if z is wider than x characters, then trim z from the left & insert y
>
> The trunction adds complexity that I'm not sure is needed. Many people want to
> know how to enable vcs_info. I'm not saying it should be included by
> default but perhaps in a comment.

I personally don't use truncation, because I use a multi-line prompt.
Others in this thread, though, insisted that new users should get a
single-line prompt. However, if you use an 80-column terminal that
often means you will run out of horizontal space quickly. I tried
truncating by leaving out segments, but I found the effect of that
undesirable: When the segments are short, it feels like information is
needlessly being hidden from you, whereas when the segments are long,
it still doesn't really save any space. Truncating to a fixed width
proved to be much more pleasant all-round, IMO. This way, it looked
more like the path was scrolling off-screen, which felt more natural.


> > zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.
>
> Is that really needed? I've never bothered.

I guess it depends on your Zsh installation. I thought I'd better be
safe than sorry. I already saw one error where add-zle-hook-widget
failed, because zsh/zle wasn't loaded yet.


> > # These are tried in order until one of them succeeds:
> > # _expand: expansion substitutions (See http://zsh.sourceforge.net/Doc/Release/Expansion.html)
> > # _complete: regular completions
> > # _history: words from history
> > # _correct: spelling corrections
> > # _ignored: any completions that have been ignored so far
> > zstyle ':completion:*' completer _expand _complete _history _correct _ignored
>
> These seem reasonable choices. _extensions wouldn't cause any unpleasant
> surprises for a new user but it does need to come first.

_extensions feels rather useless when you can get the same effect
through matchers, but without requiring the leading *.


> > # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR
> but not vice versa.

Yes, that is intentional. :)


> > # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> > zstyle ':completion:*:complete:*' matcher-list \
> >   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}' \
> >   'r:|?=** m:{[:lower:]}={[:upper:]}'
>
> I'd be significantly more conservative on these. They really can cause
> surprises for new users and break some things completely like trying to force
> the type of listed matches with punctuation prefixes.

I've used something like this for quite a while now. I'm unsure what
kind of breakage you are referring to.


> I mostly use generous matchers with more specific contexts.
> To give one example, the following helps when suspended jobs are all
> man, less or vim and I want to select on the argument:
> zstyle ':completion:*:(-command-|[fb]g):*:jobs' matcher 'l:%|=*'

I'm hesitant to do this kind of tweaking. I'd rather apply the Pareto
principle and have a generic solution that's good enough for most
cases. If there's anything specific that needs to be done for certain
completion, then it should happen in the completion function IMO.


> > # For options only, add - -> + for each item in the list above.
> > zstyle ':completion:*:options' matcher 'm:{-}={+}'
>
> Isn't the more limited 'b:-=+' sufficient here?

Perhaps, if you can explain to me what it does. :)


> > # Show and insert `man` sections.
> > zstyle ':completion:*' insert-sections yes
>
> I wouldn't bother for section 1:
>   zstyle ':completion:*:manuals.(^1*)' insert-sections true
>
> Not only because it is mostly redundant but it is easier to simplify that to
> all sections than to do the reverse.

Again, I don't see any real gain to adding that. It works fine without.


> I'd be inclined to bind Ctrl-Z to undo. Forget Emacs and Vi - Ctrl-Z is what
> the rest of the world uses for undo. That doesn't disable anything else and too
> few people know the shell has an undo. It's invaluable with completion,
> especially with approximate completion or the fuzzier matching controls such as
> r:|?=**.

Sure. And then Ctrl-Y to redo? Seems reasonable to me.


> > setopt GLOB_STAR_SHORT      # Use `**` for recursive globbing; `***` to include symlinks, too.
>
> Need to say 'without a trailing "/"' **/ is already recursive globbing
> and you don't need this option to enable it.
>
> The comment confused me but like Bart I don't use the option but found
> myself wondering whether I should.

I personally find it quite useful, especially when combined with the
_expand completer. :)


> > typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath
>
> These are tied, no need to list both forms.

The documentation of typeset -U says otherwise, though:

http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-typeset
> -U
> For arrays (but not for associative arrays), keep only the first occurrence of each duplicated value. This may also be set for tied parameters (see -T) or colon-separated special parameters like PATH or FIGNORE, etc. Note the flag takes effect on assignment, and the type of the variable being assigned to is determinative; for variables with shared values it is therefore recommended to set the flag for all interfaces, e.g. ‘typeset -U PATH path’.

Should that text be changed?


> The -g adds nothing either outside of a function.

I know, but I felt like it's good to be consistent, in case the user
ever puts in a function.


Thanks for your input!


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12  5:59                                             ` Roman Perepelitsa
@ 2021-02-13  0:23                                               ` dana
  0 siblings, 0 replies; 114+ messages in thread
From: dana @ 2021-02-13  0:23 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Marlon Richert, Zsh hackers list

On 11 Feb 2021, at 23:59, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> In my opinion the default config shouldn't aim to provide the best
> solution to anything: the best history setup, the best prompt, etc. It
> should make zsh usable by someone who considers bash usable out of the
> box (e.g., on Debian) but other than that be as simple and as short as
> possible.

I'll be a little busy for a while, so i can't comment on the latest revisions
now, but i wanted to point out that some of zsh's biggest distributors already
provide default configs that go beyond the limitations you seem to be
advocating; for example, both macOS and Debian (+ its derivatives) change the
default options and use terminfo to set key bindings.

That's an important consideration imo because it doesn't seem like creating an
up-stream config that does less than what people are already getting for zsh
defaults in the real world will be very useful to anyone. It may be nice for
completeness's sake to have something 'official', but presumably neither those
distributors nor their users will be very interested in it if they already
have something that does the same job or better.

I'm not sure about the others, but my personal desire with a config like this
was to reduce the perceived need that people have to immediately go out and
install something like OMZ. We can't make much of a dent in that if it's *too*
minimal. That said, i do think there are plenty of things that are outside the
scope of that goal, like fancy Unicode characters and clocks in the prompt.
(Looks like those aren't in the current revision, but just for example i
mean.) I'm starting to agree that XDGBDS is excessive too. Maybe some other
things. I definitely don't think it needs to be 'the best'... just nice enough
that people might actually use it.

That's my thinking anyway

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12  5:47                                               ` Marlon Richert
  2021-02-12 23:43                                                 ` Oliver Kiddle
@ 2021-02-13  1:11                                                 ` Bart Schaefer
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13  1:11 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Thu, Feb 11, 2021 at 9:47 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> On 11. Feb 2021, at 10.30, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.
> >
> > Hmm, I wouldn't think this was necessary after compinit.
>
> No, but it is necessary _before_ compinit.

That shouldn't be true either.  zstyle is an autoloaded builtin.

Src/zsh -f
ubuntu% zmodload
zsh/compctl
zsh/complete
zsh/main
zsh/zle
ubuntu% zstyle
ubuntu% zmodload
zsh/compctl
zsh/complete
zsh/main
zsh/zle
zsh/zutil
ubuntu%

You should only get an error if $module_path is wrong.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12 23:26                                             ` Oliver Kiddle
  2021-02-13  0:15                                               ` Marlon Richert
@ 2021-02-13  1:28                                               ` Bart Schaefer
  2021-02-13  1:34                                                 ` Bart Schaefer
  2021-04-22 13:57                                               ` Marlon Richert
  2 siblings, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13  1:28 UTC (permalink / raw)
  To: Zsh hackers list; +Cc: Marlon Richert

On Fri, Feb 12, 2021 at 3:26 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> > # Use `exec zsh` to apply changes after editing this file.
>
> Not sure I'd recommend that because if you mistype "zsh", your shell+terminal
> disappears. And if they've broken .zshrc, that can leave them unable to log
> back in.

zsh -l && exit

perhaps?  Also, check for minimal correctness with

zsh -nf .zshrc

> It can be quite helpful to leave PS2 empty and put <%^ in the [transient] right
> - allows for copy and paste without intervening prompts.

I believe I mentioned this also.  Actually, what I'd really like is a
variant of %_ that outputs N spaces for every level of complex command
depth; I'd use that in PS2 and %^ in transient RPS2, and presto you
get neatly indented code to copy-paste.

> > ZLE_REMOVE_SUFFIX_CHARS=$' \t\n;' # Characters that remove completion suffixes.
> > ZLE_SPACE_SUFFIX_CHARS=$'&|'      # Characters that instead replace them with a space.
>
> The first of these assignments is actually redundant because the latter takes
> precedence.

Is it really redundant?  Both settings will be applied, it's just that
SPACE_SUFFIX is tested first?

> > typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath
>
> These are tied, no need to list both forms. The -g adds nothing either
> outside of a function.

The -U does nothing for the scalars, either.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13  0:15                                               ` Marlon Richert
@ 2021-02-13  1:33                                                 ` Bart Schaefer
  2021-02-13  1:36                                                 ` Oliver Kiddle
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13  1:33 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Oliver Kiddle, Zsh hackers list

On Fri, Feb 12, 2021 at 4:16 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> > > zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.
> >
> > Is that really needed? I've never bothered.
>
> I guess it depends on your Zsh installation.

Only if you have an odd/broken installation.

> I already saw one error where add-zle-hook-widget
> failed, because zsh/zle wasn't loaded yet.

That's an entirely different thing, and might be happening because
zsh/newuser is loaded too early in the startup.

> > I'd be inclined to bind Ctrl-Z to undo.
>
> Sure. And then Ctrl-Y to redo? Seems reasonable to me.

No, ^Y is already bound to "yank", don't change that.  The point is ^Z
isn't bound, so it's harmless to bind it.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13  1:28                                               ` Bart Schaefer
@ 2021-02-13  1:34                                                 ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13  1:34 UTC (permalink / raw)
  To: Zsh hackers list

On Fri, Feb 12, 2021 at 5:28 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The -U does nothing for the scalars, either.

I stand corrected.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13  0:15                                               ` Marlon Richert
  2021-02-13  1:33                                                 ` Bart Schaefer
@ 2021-02-13  1:36                                                 ` Oliver Kiddle
  2021-02-13  2:53                                                   ` Bart Schaefer
  2021-02-13 10:26                                                   ` Marlon Richert
  1 sibling, 2 replies; 114+ messages in thread
From: Oliver Kiddle @ 2021-02-13  1:36 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Marlon Richert wrote:
> Bart suggested we could instead, in zsh-newuser-install, ask the users
> what they would actually prefer. I think that's reasonable. I put a
> suggested text in my reply to him. I will start adding the new version
> of zsh-newuser-install to the repo, too.

zsh-newuser-install could also check $XDG_DATA_HOME and handle the mkdir
if the user agrees. Then leave it hardcoded in the fresh .zshrc. There's
benefits to leaving people with a simpler config file.

If we do end up asking questions in zsh-newuser-install, I'd prefer
less text initially. I see it just often enough (with empty accounts)
that I have to skim the text to work out how to tell it to just go away
and give me a prompt. Currently, the wording can leave you unsure as
to whether q quits zsh completely. Escape or Ctrl-C should work and I
wouldn't mind if only one key continues with setup and anything else
goes to print -z.

> I personally don't use truncation, because I use a multi-line prompt.

I do actually use the conditional newline that the oliver theme
demonstrates even though I don't otherwise use that theme. I like
having a complete path that can be selected with the mouse and pasted
elsewhere. Most of the time my prompt remains single-line.

> I guess it depends on your Zsh installation. I thought I'd better be
> safe than sorry. I already saw one error where add-zle-hook-widget
> failed, because zsh/zle wasn't loaded yet.

As I think Bart mentioned, if you use zstyle after compinit it should
definitely be safe.

> _extensions feels rather useless when you can get the same effect
> through matchers, but without requiring the leading *.

With a matcher, you'll only complete one of them unless you have
_all_matches. _extensions preserves the all sense by leaving the initial
*. or ^*. alone. It is mostly less useful because most extensions are
short - but it is generally fairly harmless too.

> > > # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR
> > but not vice versa.
>
> Yes, that is intentional. :)

I realise. I mentioned it as a suggested addition to the comment because
it might not be obvious to a new user.

> > > # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> > > zstyle ':completion:*:complete:*' matcher-list \
> > >   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}' \
> > >   'r:|?=** m:{[:lower:]}={[:upper:]}'
> >
> > I'd be significantly more conservative on these. They really can cause
> > surprises for new users and break some things completely like trying to force
> > the type of listed matches with punctuation prefixes.
>
> I've used something like this for quite a while now. I'm unsure what
> kind of breakage you are referring to.

What I was alluding to there is that there are times when I'll type an
initial prefix to limit the sort of matches I get. So with this,
completion after the following does not give me only completion functions:
  which _<tab>
Any command with an underscore gets matched while completion functions
remain ignored.

Otherwise it is sometimes quite aggressive and transforms what you've typed
considerably. I've known people to complain about _approximate for that.
I'm personally not keen on the ** forms with r:

If you like it that way, don't mind me. I've probably built up habits
over the years that would never be intuitive to a new user anyway.

> > I mostly use generous matchers with more specific contexts.
> > To give one example, the following helps when suspended jobs are all
> > man, less or vim and I want to select on the argument:
> > zstyle ':completion:*:(-command-|[fb]g):*:jobs' matcher 'l:%|=*'
>
> I'm hesitant to do this kind of tweaking. I'd rather apply the Pareto
> principle and have a generic solution that's good enough for most
> cases. If there's anything specific that needs to be done for certain
> completion, then it should happen in the completion function IMO.

That's fine. The generic solution is probably more appropriate here just
perhaps not quite so aggressive. I wasn't suggesting that style just
using it as an example. Certainly I would also be hesitant to include
it and dozens like it. (Though your following one for options is along
similar lines.)

> > > # For options only, add - -> + for each item in the list above.
> > > zstyle ':completion:*:options' matcher 'm:{-}={+}'
> >
> > Isn't the more limited 'b:-=+' sufficient here?
>
> Perhaps, if you can explain to me what it does. :)

It only applies at the beginning of a word. So typeset -<tab> will still
list all the + options which I assume is the intent. The m: form matches
any - to any +, b: only at the beginning. Removing the curly brackets has
no effect on the behaviour, they're superfluous when you only have one
character.

> Sure. And then Ctrl-Y to redo? Seems reasonable to me.

That's already yank, unfortunately.

> > > typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath
> >
> > These are tied, no need to list both forms.
>
> The documentation of typeset -U says otherwise, though:

> Should that text be changed?

The text appears to be correct - I didn't know that. So no change
needed.

Oliver


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13  1:36                                                 ` Oliver Kiddle
@ 2021-02-13  2:53                                                   ` Bart Schaefer
  2021-02-13 10:26                                                   ` Marlon Richert
  1 sibling, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13  2:53 UTC (permalink / raw)
  To: Zsh hackers list

On Fri, Feb 12, 2021 at 5:36 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> > The documentation of typeset -U says otherwise, though:
>
> > Should that text be changed?
>
> The text appears to be correct - I didn't know that.

Well, that makes ME feel better.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13  1:36                                                 ` Oliver Kiddle
  2021-02-13  2:53                                                   ` Bart Schaefer
@ 2021-02-13 10:26                                                   ` Marlon Richert
  2021-02-13 22:53                                                     ` Marlon Richert
  2021-02-13 22:56                                                     ` Bart Schaefer
  1 sibling, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-13 10:26 UTC (permalink / raw)
  To: Oliver Kiddle, Bart Schaefer, dana; +Cc: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 9769 bytes --]

Thank you all for your input! :) Since there's a lot of overlap and
redundancy by now, I'll reply to everything in one email.


On Sat, Feb 13, 2021 at 2:23 AM dana <dana@dana.is> wrote:
> it doesn't seem like creating an
> up-stream config that does less than what people are already getting for
zsh
> defaults in the real world will be very useful to anyone. It may be nice
for
> completeness's sake to have something 'official', but presumably neither
those
> distributors nor their users will be very interested in it if they already
> have something that does the same job or better.
>
> I'm not sure about the others, but my personal desire with a config like
this
> was to reduce the perceived need that people have to immediately go out
and
> install something like OMZ. We can't make much of a dent in that if it's
*too*
> minimal.

I just want to say that I completely agree with all of the above.


> That said, i do think there are plenty of things that are outside the
> scope of that goal, like fancy Unicode characters and clocks in the
prompt.
> (Looks like those aren't in the current revision, but just for example i
> mean.) I'm starting to agree that XDGBDS is excessive too. Maybe some
other
> things. I definitely don't think it needs to be 'the best'... just nice
enough
> that people might actually use it.

Yes, I can get behind that.


On Sat, Feb 13, 2021 at 3:11 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:
> That shouldn't be true either.  zstyle is an autoloaded builtin.

Is there a list of which modules and their builtins get autoloaded? I
cannot find this documented anywhere.


On Sat, Feb 13, 2021 at 3:28 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:
> > > # Use `exec zsh` to apply changes after editing this file.
> >
> > Not sure I'd recommend that because if you mistype "zsh", your
shell+terminal
> > disappears. And if they've broken .zshrc, that can leave them unable to
log
> > back in.
>
> zsh -l && exit
>
> perhaps?  Also, check for minimal correctness with
>
> zsh -nf .zshrc

Should we perhaps add a function that does that, to save the user from
having to remember this? Something like this:

zrestart() {
  zsh -nf .zshrc && zsh -l && exit
}

Not sure about the name.


On Sat, Feb 13, 2021 at 3:33 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:
> > I already saw one error where add-zle-hook-widget
> > failed, because zsh/zle wasn't loaded yet.
>
> That's an entirely different thing, and might be happening because
> zsh/newuser is loaded too early in the startup.

No, this was with the code copy-pasted directly into a .zshrc file. No
zsh/newuser involved.


> > > I'd be inclined to bind Ctrl-Z to undo.
> >
> > Sure. And then Ctrl-Y to redo? Seems reasonable to me.
>
> No, ^Y is already bound to "yank", don't change that.  The point is ^Z
> isn't bound, so it's harmless to bind it.

What about using ^Z for undo and ^[z for redo? That's similar to Cmd-Z for
undo and Cmd-Shift-Z for redo in macOS.

Although, I'm starting to think, given the amount of custom key bindings
the new .zshrc includes by now, would it make more sense to introduce a
completely new keymap in the C code? As Oliver stated:

> Forget Emacs and Vi - Ctrl-Z is what the rest of the world uses for undo.

Well, the rest of the world also uses Ctrl-V for paste, plus a whole bunch
of other standardized keyboard shortcuts that are nothing like those used
in shells, some of which I added in this new user .zshrc. However, that
part of the file is getting quite long. If we would introduce an entirely
new keymap for this, then we would both make this new user .zshrc more
simple _and_ give an easy way for all the other users to get the same
keybindings, without having to maintain them individually in their .zshrc
files.


On Sat, Feb 13, 2021 at 3:36 AM Oliver Kiddle <opk@zsh.org> wrote:
> zsh-newuser-install could also check $XDG_DATA_HOME and handle the mkdir
> if the user agrees. Then leave it hardcoded in the fresh .zshrc. There's
> benefits to leaving people with a simpler config file.

Yes, if we already ask this in zsh-newuser-install, then there's no need to
also check for this in the .zshrc file.


> If we do end up asking questions in zsh-newuser-install, I'd prefer
> less text initially.

Oh yes, completely agree. KISS.


> I do actually use the conditional newline that the oliver theme
> demonstrates even though I don't otherwise use that theme. I like
> having a complete path that can be selected with the mouse and pasted
> elsewhere. Most of the time my prompt remains single-line.
>
> PS1="$pcolr$user$host%~%"'$((COLUMNS-12))'"(l.$prompt_newline.
)[%h%1(j.%%%j.)%0(?..:%?)]%# %b%f%k"

I used PROMPT_SUBST with $((COLUMNS)) earlier, but Dana & Bart were against
it:

> > > > setopt PROMPT_SUBST
> > >
> > > I think most of the devs discourage PROMPT_SUBST. If nothing else it
feels a
> > > bit advanced for what we're trying to achieve here
> >
> > Why exactly do you discourage the use of PROMPT_SUBST? Why is it a
problem?
>
> Here's one reason:
>
> zsh% P='${(%%)P}'
> zsh% setopt promptsubst
> zsh% print -P $P
> zsh: segmentation fault (core dumped)  Src/zsh -f
>
> Do that accidentally once with PS1 or RPS1, and you're locked out of your
shell.
>
> The main thing, though, is that it encourages the prompt to contain
> $(fork something expensive).  If you have to think about when/where
> you're capturing that output, you write better code.


> As I think Bart mentioned, if you use zstyle after compinit it should
> definitely be safe.

Sure, but compinit actually checks the completer style to decide whether to
rebind ^I to complete-word or leave it at expand-or-complete. So, then at
least that style needs to come before compinit and then we have to zmodload
zstyle before compinit anyway. Should then perhaps that piece of code in
compinit be changed, so all zstyle calls can occur after compinit?


> > _extensions feels rather useless when you can get the same effect
> > through matchers, but without requiring the leading *.
>
> With a matcher, you'll only complete one of them unless you have
> _all_matches. _extensions preserves the all sense by leaving the initial
> *. or ^*. alone. It is mostly less useful because most extensions are
> short - but it is generally fairly harmless too.

If I want multiple files with an extension, then _expand handles *.foo just
fine. I still don't see the point of _extensions. :)


> > > > # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> > > > zstyle ':completion:*:complete:*' matcher-list \
> > > >   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}' \
> > > >   'r:|?=** m:{[:lower:]}={[:upper:]}'
> > >
> > > I'd be significantly more conservative on these. They really can cause
> > > surprises for new users and break some things completely like trying
to force
> > > the type of listed matches with punctuation prefixes.
> >
> > I've used something like this for quite a while now. I'm unsure what
> > kind of breakage you are referring to.
>
> What I was alluding to there is that there are times when I'll type an
> initial prefix to limit the sort of matches I get. So with this,
> completion after the following does not give me only completion functions:
>   which _<tab>
> Any command with an underscore gets matched while completion functions
> remain ignored.
>
> Otherwise it is sometimes quite aggressive and transforms what you've
typed
> considerably. I've known people to complain about _approximate for that.
> I'm personally not keen on the ** forms with r:

But r:|?=** is part only of the second matcher. When you type _<tab>, it
will get matched already by the first matcher in matcher-list.


> > > I mostly use generous matchers with more specific contexts.
> > > To give one example, the following helps when suspended jobs are all
> > > man, less or vim and I want to select on the argument:
> > > zstyle ':completion:*:(-command-|[fb]g):*:jobs' matcher 'l:%|=*'
> >
> > I'm hesitant to do this kind of tweaking. I'd rather apply the Pareto
> > principle and have a generic solution that's good enough for most
> > cases. If there's anything specific that needs to be done for certain
> > completion, then it should happen in the completion function IMO.
>
> That's fine. The generic solution is probably more appropriate here just
> perhaps not quite so aggressive. I wasn't suggesting that style just
> using it as an example. Certainly I would also be hesitant to include
> it and dozens like it. (Though your following one for options is along
> similar lines.)

I feel like options are common enough to warrant an exception, especially
because they won't get shown until you type a dash. Without the additional
matcher below, you might never realize that `set` and `functions` (for
example) also have + options, because they will not get listed.


> > > > # For options only, add - -> + for each item in the list above.
> > > > zstyle ':completion:*:options' matcher 'm:{-}={+}'
> > >
> > > Isn't the more limited 'b:-=+' sufficient here?
> >
> > Perhaps, if you can explain to me what it does. :)
>
> It only applies at the beginning of a word. So typeset -<tab> will still
> list all the + options which I assume is the intent. The m: form matches
> any - to any +, b: only at the beginning. Removing the curly brackets has
> no effect on the behaviour, they're superfluous when you only have one
> character.

Thanks, I didn't know that. That wasn't clear to me from the way it's
described in the documentation:

http://zsh.sourceforge.net/Doc/Release/Completion-Widgets.html#Completion-Matching-Control
> The b and B forms are similar to l and L with an empty anchor, but need
to match only the beginning of the word on the command line or trial
completion, respectively.

[-- Attachment #2: Type: text/html, Size: 12134 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13 10:26                                                   ` Marlon Richert
@ 2021-02-13 22:53                                                     ` Marlon Richert
  2021-02-14  0:34                                                       ` Bart Schaefer
  2021-02-13 22:56                                                     ` Bart Schaefer
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-13 22:53 UTC (permalink / raw)
  To: Oliver Kiddle, Bart Schaefer, dana; +Cc: Zsh hackers list

I added a first draft for a new `zsh-newuser-install` script:
https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zsh-newuser-install

And I added some more refinements to the .zshrc template:
https://gitlab.com/marlonrichert/zsh-sensible/-/commit/16f9ec800d469caa61f70964cffb1fce216741c6?w=1#37e915f6ec0aeb1a403e1d14b71f3f58379a9cb2


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13 10:26                                                   ` Marlon Richert
  2021-02-13 22:53                                                     ` Marlon Richert
@ 2021-02-13 22:56                                                     ` Bart Schaefer
  2021-02-14  8:01                                                       ` Marlon Richert
  2021-02-19 21:34                                                       ` Rewrite of zsh-newuser-install Marlon Richert
  1 sibling, 2 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-13 22:56 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Sat, Feb 13, 2021 at 2:27 AM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> Is there a list of which modules and their builtins get autoloaded? I cannot find this documented anywhere.

Src/bltinmods.list

For example, the following means that the builtins ("b:") named
"limit", "ulimit", and "unlimit" are autoloaded when in zsh emulation
mode:

/* linked-in known module `zsh/rlimits' */
  {
    char *zsh_features[] = {
      "b:limit",
      "b:ulimit",
      "b:unlimit",
      NULL
    };
    char *emu_features[] = {
      "b:ulimit",
      NULL
    };
    autofeatures("zsh", "zsh/rlimits",
       EMULATION(EMULATE_ZSH) ? zsh_features : emu_features,
       0, 1);
  }

(Hmm, I see that the documentation for "zsh/param/private" is actually
incorrect, I changed "private" from an autoloaded builtin to a
reserved word and forgot to edit that paragraph.)

> Should we perhaps add a function that does that, to save the user from having to remember this? Something like this:
>
> zrestart() {
>   zsh -nf .zshrc && zsh -l && exit
> }
>
> Not sure about the name.

This is not a bad idea.  I agree about the naming difficulty, but
don't have a good suggestion.  "test_new_zshrc"?

> > > I already saw one error where add-zle-hook-widget
> > > failed, because zsh/zle wasn't loaded yet.
>
> [...] this was with the code copy-pasted directly into a .zshrc file. No zsh/newuser involved.

Hm.  zsh/zle is one of the default modules, it should always be there
unless the stdin is not a terminal.

> What about using ^Z for undo and ^[z for redo? That's similar to Cmd-Z for undo and Cmd-Shift-Z for redo in macOS.

That would be fine, I think.

> Although, I'm starting to think, given the amount of custom key bindings the new .zshrc includes by now, would it make more sense to introduce a completely new keymap in the C code?

This is possibly worth considering, but you're adding bindings in a
bunch of keymaps.

A compromise might be to have a second file that creates a keymap
using "bindkey" commands, and (optionally?) load + switch to that.  If
it goes well, then we can add it to the C later.

> Sure, but compinit actually checks the completer style to decide whether to rebind ^I to complete-word or leave it at expand-or-complete. So, then at least that style needs to come before compinit and then we have to zmodload zstyle before compinit anyway.

Again, no, the main shell should know from link time that any
reference to the ztyle command should pull in the zsh/zutil module.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13 22:53                                                     ` Marlon Richert
@ 2021-02-14  0:34                                                       ` Bart Schaefer
  2021-02-14  8:12                                                         ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-14  0:34 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On Sat, Feb 13, 2021 at 2:53 PM Marlon Richert <marlon.richert@gmail.com> wrote:
>
> I added a first draft for a new `zsh-newuser-install` script:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zsh-newuser-install

I would suggest that (1) there be a path into (a possibly less verbose
version of) the current zsh-newuser-install questionnaire, with the
default choice being to simply install the "recommended" zshrc, and
(2) the recommended file include the $startline and $endline markers
so that someone who wants to dive into the questionnaire later can do
so.

This also leaves open the possibility that (3) we could offer two
"recommended" zshrc files, the one we've been working on here and a
minimalist one as described by Roman.

> And I added some more refinements to the .zshrc template:
> https://gitlab.com/marlonrichert/zsh-sensible/-/commit/16f9ec800d469caa61f70964cffb1fce216741c6?w=1#37e915f6ec0aeb1a403e1d14b71f3f58379a9cb2

Only one remark, really:

+ HISTFILE=<HISTFILE>

I realize the string "<HISTFILE>" is meant to be replaced by
zsh-newuser-install, but you could still make this look like a working
shell construct, e.g.,

HISTFILE=${HISTFILE:-}

Similarly of course for _comp_dumpfile and _cache_dir.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13 22:56                                                     ` Bart Schaefer
@ 2021-02-14  8:01                                                       ` Marlon Richert
  2021-02-19 21:38                                                         ` Marlon Richert
  2021-02-19 21:34                                                       ` Rewrite of zsh-newuser-install Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-14  8:01 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list



> On 14. Feb 2021, at 0.56, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> Although, I'm starting to think, given the amount of custom key bindings the new .zshrc includes by now, would it make more sense to introduce a completely new keymap in the C code?
> 
> This is possibly worth considering, but you're adding bindings in a
> bunch of keymaps.

“A bunch” in this case is two: main & menuselect. But I get your point.

However, this just highlights an underlying problem in how menuselect currently works: The keybindings one wants in menuselect are closely correlated to the bindings one wants in the main keymap. But there’s only one menuselect keymap, which you are not allowed to alias to another keymap. And because there’s only one menuselect keymap, Zsh cannot prepopulate it with too many defaults, because it has to be usablr for both emacs and vi modes. So, the user ends up having to define a lot of their keybindings twice to be able to get a consistent behavior between main & menuselect. 

What I would like to see is that menuselect behaves like main: Zsh provides a couple of defaults for you (say, emacs-menu, vi-menu & perhaps a new friendly-menu) and then you alias menuselect to one of those.

Could this be done?






^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-14  0:34                                                       ` Bart Schaefer
@ 2021-02-14  8:12                                                         ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-14  8:12 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list



> On 14. Feb 2021, at 2.34, Bart Schaefer <schaefer@brasslantern.com> wrote:
> I would suggest that (1) there be a path into (a possibly less verbose
> version of) the current zsh-newuser-install questionnaire, with the
> default choice being to simply install the "recommended" zshrc, and
> (2) the recommended file include the $startline and $endline markers
> so that someone who wants to dive into the questionnaire later can do
> so.

No, I completely disagree here. I don’t think anybody wants the questionnaire. It’s extremely cumbersome to use. Editing your .zshrc file is actually easier. The hard part is trying to figure out what to put in there and what it all actually does. That’s what we’re trying to help new users with here.


> This also leaves open the possibility that (3) we could offer two
> "recommended" zshrc files, the one we've been working on here and a
> minimalist one as described by Roman.

My feeling is that the % of new users that actually wants what Roman describes it is tiny. And those that do want it can a) choose not to run zsh-newuser-install and write such a simple .zshrc file themselves or b) just delete what they don’t like from the generated .zshrc file. Let’s not add unnecessary moving parts to this. Let’s instead focus on getting new users a better out-of-the-box experience.



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-13 22:56                                                     ` Bart Schaefer
  2021-02-14  8:01                                                       ` Marlon Richert
@ 2021-02-19 21:34                                                       ` Marlon Richert
  1 sibling, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-19 21:34 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Sun, Feb 14, 2021 at 12:56 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
> > Is there a list of which modules and their builtins get autoloaded? I cannot find this documented anywhere.
>
> Src/bltinmods.list

I cannot find that file anywhere, but I guess it is generated by
https://github.com/zsh-users/zsh/blob/master/Src/mkbltnmlst.sh

Do I need to build Zsh from source to get that list?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-14  8:01                                                       ` Marlon Richert
@ 2021-02-19 21:38                                                         ` Marlon Richert
  2021-02-20  0:30                                                           ` dana
  2021-02-22  3:54                                                           ` Paul
  0 siblings, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-19 21:38 UTC (permalink / raw)
  To: Bart Schaefer, Daniel Shahaf, dana, Oliver Kiddle; +Cc: Zsh hackers list

I made some more changes. Please try them out and let me know what you think.

* https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zsh-newuser-install
* https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-19 21:38                                                         ` Marlon Richert
@ 2021-02-20  0:30                                                           ` dana
  2021-02-20  8:18                                                             ` Marlon Richert
  2021-02-22  3:54                                                           ` Paul
  1 sibling, 1 reply; 114+ messages in thread
From: dana @ 2021-02-20  0:30 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 14 Feb 2021, at 02:12, Marlon Richert <marlon.richert@gmail.com> wrote:
> No, I completely disagree here. I don’t think anybody wants the
> questionnaire. It’s extremely cumbersome to use.

Despite the title of the thread, i didn't actually expect that large of a
change to zsh-newuser-install itself. I know from comments i've seen on-line
that many people find the wizard overwhelming, but i don't have any evidence
that specifically points to '[nobody] wants the questionnaire'. I'm fine with
getting rid of it if the others want to, i just don't know myself.

There are also some moving parts we haven't really even discussed, like how
these changes will affect packagers. Are we going to get rid of the
recommended-zshrc mechanism (option 2) that is used by Debian &al.? Or is this
config going to co-exist with it? Or are we going to unify them somehow?

Should we consult with some down-stream maintainers on this? I argued before
that the config is not going to be very useful if it does less than what
down-stream are doing already, but it's also not going to be useful if the
maintainers just override it with skel or whatever because they don't like it.

As for what's currently in the rewritten script... i wonder if it's really
even necessary to ask every new user where they want to put their shell files.
I don't have any evidence, but it seems like a high burden (having to read and
answer the questions) compared to the amount of people who are actually going
to feel strongly about it.

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-20  0:30                                                           ` dana
@ 2021-02-20  8:18                                                             ` Marlon Richert
  2021-02-20 18:57                                                               ` Bart Schaefer
  2021-02-24 22:15                                                               ` dana
  0 siblings, 2 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-20  8:18 UTC (permalink / raw)
  To: dana, Bart Schaefer, Oliver Kiddle, Daniel Shahaf; +Cc: Zsh hackers list


> On 20. Feb 2021, at 2.30, dana <dana@dana.is> wrote:
> Despite the title of the thread, i didn't actually expect that large of a
> change to zsh-newuser-install itself. I know from comments i've seen on-line
> that many people find the wizard overwhelming, but i don't have any evidence
> that specifically points to '[nobody] wants the questionnaire'. I'm fine with
> getting rid of it if the others want to, i just don't know myself.

While I have no quantifiable evidence for this particular case, it is a general principle of modern UX Design to give the user good defaults, which they then can change later, rather than present them with lots of choices upfront. This is backed up by actual, credible usability research. And I do have lots of anecdotal evidence that shell users prefer to just have a default config that they can edit manually.


> There are also some moving parts we haven't really even discussed, like how
> these changes will affect packagers. Are we going to get rid of the
> recommended-zshrc mechanism (option 2) that is used by Debian &al.?

I don’t know what is the “recommended-zshrc mechanism (option 2)”. How does that work?


> Or is this
> config going to co-exist with it? Or are we going to unify them somehow?
> 
> Should we consult with some down-stream maintainers on this?

Yes, I think that’s definitely a good idea. Is that just a matter of asking on their mailing lists?

Perhaps one idea would be to make this parametrizable a little, to make it easier for downstream maintainers to build their defaults on top of this. So, instead of presenting the users with lots of questions, we instead give the downstream maintainers an easy way to selectively override our suggested defaults.


> As for what's currently in the rewritten script... i wonder if it's really
> even necessary to ask every new user where they want to put their shell files.
> I don't have any evidence, but it seems like a high burden (having to read and
> answer the questions) compared to the amount of people who are actually going
> to feel strongly about it.

I would be fine with just using the XDG Base Dir spec for this, but not everyone seems to agree. Hence the question. It’s a compromise. :)



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-20  8:18                                                             ` Marlon Richert
@ 2021-02-20 18:57                                                               ` Bart Schaefer
  2021-02-21 19:24                                                                 ` Marlon Richert
  2021-02-24 22:15                                                               ` dana
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-02-20 18:57 UTC (permalink / raw)
  To: Marlon Richert; +Cc: dana, Oliver Kiddle, Daniel Shahaf, Zsh hackers list

On Sat, Feb 20, 2021 at 12:18 AM Marlon Richert
<marlon.richert@gmail.com> wrote:
>
> While I have no quantifiable evidence for this particular case, it is a general principle of modern UX Design to give the user good defaults, which they then can change later, rather than present them with lots of choices upfront.

I have no quibble with this, but I've actually used the questionnaire
myself to set up zsh on hosts from which I can't access the repository
with my $ZDOTDIR.  I would be dismayed to have it completely thrown
away/inaccessible.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-20 18:57                                                               ` Bart Schaefer
@ 2021-02-21 19:24                                                                 ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-02-21 19:24 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: dana, Oliver Kiddle, Daniel Shahaf, Zsh hackers list

On Sat, Feb 20, 2021 at 8:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > While I have no quantifiable evidence for this particular case, it is a general principle of modern UX Design to give the user good defaults, which they then can change later, rather than present them with lots of choices upfront.
>
> I have no quibble with this, but I've actually used the questionnaire
> myself to set up zsh on hosts from which I can't access the repository
> with my $ZDOTDIR.  I would be dismayed to have it completely thrown
> away/inaccessible.

Wouldn't it be even more convenient if the default config was good
enough that you wouldn't have to go through the questionnaire again?
:)

On Sat, Feb 20, 2021 at 8:58 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sat, Feb 20, 2021 at 12:18 AM Marlon Richert
> <marlon.richert@gmail.com> wrote:
> >
> > While I have no quantifiable evidence for this particular case, it is a general principle of modern UX Design to give the user good defaults, which they then can change later, rather than present them with lots of choices upfront.
>
> I have no quibble with this, but I've actually used the questionnaire
> myself to set up zsh on hosts from which I can't access the repository
> with my $ZDOTDIR.  I would be dismayed to have it completely thrown
> away/inaccessible.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-19 21:38                                                         ` Marlon Richert
  2021-02-20  0:30                                                           ` dana
@ 2021-02-22  3:54                                                           ` Paul
  2021-02-22  8:14                                                             ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Paul @ 2021-02-22  3:54 UTC (permalink / raw)
  To: Marlon Richert, Bart Schaefer, Daniel Shahaf, dana, Oliver Kiddle
  Cc: Zsh hackers list

On Fri Feb 19, 2021 at 3:38 PM CST, Marlon Richert wrote:
> I made some more changes. Please try them out and let me know what you
> think.
>
> * https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

I decided to try out some of these, but there seems to be an issue with
completions, specifically when completing 'functions -<Tab>':

https://i.imgur.com/d7polcy.png

Minimal file which reproduces this issue with 'zsh -f':

---

zstyle ':completion:*:complete:*' matcher-list 'r:?|[-_]=**'
zstyle ':completion:*:functions' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
zmodload zsh/complist
setopt MENU_COMPLETE
zstyle ':completion:*:default' menu yes select
autoload -Uz compinit
compinit

# plus either of the following two lines:
zstyle ':completion:*:options' matcher 'b:-=+'
zstyle ':completion:*:options' matcher 'm:{-}={+}'

---

This might be an issue with an upstream completion function, but it
should regardless be fixed before the new newusers is incorporated.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-22  3:54                                                           ` Paul
@ 2021-02-22  8:14                                                             ` Marlon Richert
  2021-02-22 16:31                                                               ` Bug in compdescribe with matcher 'b:-=+' Bart Schaefer
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-22  8:14 UTC (permalink / raw)
  To: Paul; +Cc: Bart Schaefer, Daniel Shahaf, dana, Oliver Kiddle, Zsh hackers list

On Mon, Feb 22, 2021 at 5:56 AM Paul <GammaFunction@vivaldi.net> wrote:
>
> On Fri Feb 19, 2021 at 3:38 PM CST, Marlon Richert wrote:
> > I made some more changes. Please try them out and let me know what you
> > think.
> >
> > * https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc
>
> I decided to try out some of these, but there seems to be an issue with
> completions, specifically when completing 'functions -<Tab>':
>
> https://i.imgur.com/d7polcy.png
>
> Minimal file which reproduces this issue with 'zsh -f':
>
> ---
>
> zstyle ':completion:*:complete:*' matcher-list 'r:?|[-_]=**'
> zstyle ':completion:*:functions' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
> zmodload zsh/complist
> setopt MENU_COMPLETE
> zstyle ':completion:*:default' menu yes select
> autoload -Uz compinit
> compinit
>
> # plus either of the following two lines:
> zstyle ':completion:*:options' matcher 'b:-=+'
> zstyle ':completion:*:options' matcher 'm:{-}={+}'
>
> ---
>
> This might be an issue with an upstream completion function, but it
> should regardless be fixed before the new newusers is incorporated.

I can reproduce it with just this:

autoload -Uz compinit; compinit
zstyle ':completion:*:functions' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
zstyle ':completion:*:options' matcher 'b:-=+'

The bug also occurs when completing options for `autoload`, but not
for any of the other commands completed by `_typeset`.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Bug in compdescribe with matcher 'b:-=+'
  2021-02-22  8:14                                                             ` Marlon Richert
@ 2021-02-22 16:31                                                               ` Bart Schaefer
  0 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-02-22 16:31 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Paul, Daniel Shahaf, dana, Oliver Kiddle, Zsh hackers list

(Was zsh-newuser-install)

On Mon, Feb 22, 2021 at 12:14 AM Marlon Richert
<marlon.richert@gmail.com> wrote:
>
> On Mon, Feb 22, 2021 at 5:56 AM Paul <GammaFunction@vivaldi.net> wrote:
> >
> > https://i.imgur.com/d7polcy.png
>
> I can reproduce it with just this:
>
> autoload -Uz compinit; compinit
> zstyle ':completion:*:functions' ignored-patterns '[[:punct:]]*[[:alnum:]]*'
> zstyle ':completion:*:options' matcher 'b:-=+'

When the matcher 'b:-=+' is present, this test at line 129 of _describe:

        +_describe:129> compdescribe -g csl2 _args _tmpm _tmpd

which is the conditional for a "while" loop, succeeds 17 times, each
time executing

       +_describe:134> compadd -E10 -Q -M 'r:|[_-]=* r:|=*' -M 'b:-=+'
-J -default- -X option -d _tmpd -a _tmpm

This results in 30 matches being generated, instead of the 9 when that
matcher is omitted (in which case compdescribe never succeeds).

I believe the issue is that compdescribe ("cd_get" in
Src/Zle/computil.c) is not propagating the correct description into
_tmpd, but that's the extent of my understanding of these internals.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-20  8:18                                                             ` Marlon Richert
  2021-02-20 18:57                                                               ` Bart Schaefer
@ 2021-02-24 22:15                                                               ` dana
  2021-02-25  8:05                                                                 ` Daniel Shahaf
  1 sibling, 1 reply; 114+ messages in thread
From: dana @ 2021-02-24 22:15 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

On 20 Feb 2021, at 02:18, Marlon Richert <marlon.richert@gmail.com> wrote:
> it is a general principle of modern UX Design to give the user good
> defaults, which they then can change later, rather than present them with
> lots of choices upfront

Right, which is the point of this whole endeavour. idk, like i said, i'm not
invested in it personally, just wanted to mention that we don't seem to know
anything about how it's used in the real world. I wouldn't have known Bart
uses it

On 20 Feb 2021, at 02:18, Marlon Richert <marlon.richert@gmail.com> wrote:
> I don’t know what is the “recommended-zshrc mechanism (option 2)”. How does
> that work?

Packagers can provide their own zshrc at /etc/zsh/newuser.zshrc.recommended,
which, if detected by the wizard, appears as an option on that initial screen
as 'the configuration recommended by the system administrator'

On 20 Feb 2021, at 02:18, Marlon Richert <marlon.richert@gmail.com> wrote:
> Yes, I think that’s definitely a good idea. Is that just a matter of asking
> on their mailing lists?

Axel is the maintainer for Debian, we've brought him in on the list here
before. I can't remember the others we usually work with, Daniel would know

On 20 Feb 2021, at 02:18, Marlon Richert <marlon.richert@gmail.com> wrote:
> I would be fine with just using the XDG Base Dir spec for this, but not
> everyone seems to agree. Hence the question. It’s a compromise. :)

idk how strongly everyone feels about it, seemed like most people were leaning
towards it being non-critical

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-24 22:15                                                               ` dana
@ 2021-02-25  8:05                                                                 ` Daniel Shahaf
  2021-02-25 16:58                                                                   ` dana
  2021-02-26 22:31                                                                   ` Marlon Richert
  0 siblings, 2 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-02-25  8:05 UTC (permalink / raw)
  To: Zsh hackers list; +Cc: Marlon Richert

dana wrote on Wed, Feb 24, 2021 at 16:15:58 -0600:
> On 20 Feb 2021, at 02:18, Marlon Richert <marlon.richert@gmail.com> wrote:
> > Yes, I think that’s definitely a good idea. Is that just a matter of asking
> > on their mailing lists?
> 
> Axel is the maintainer for Debian, we've brought him in on the list here
> before. I can't remember the others we usually work with, Daniel would know

In general, there's <https://repology.org/project/zsh/versions>, but
I don't think we should rely on it.  If we have a question to downstream
maintainers, we should ask it on an appropriate mailing list — e.g.,
-workers@, or workers@ with an appropriate subject prefix/tag, or as
a drive-by mention in the next email to announce@.

In this specific case, however, which downstreams actually ship
a recommended zshrc?  I suspect few do, so we can contact them directly.
For Debian, we should address our questions to pkg-zsh-devel
alioth-lists.debian.net.  (Those already familiar with bugs.debian.org
incantations may prefer to create a bug with X-Debbugs-Cc instead.)

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-25  8:05                                                                 ` Daniel Shahaf
@ 2021-02-25 16:58                                                                   ` dana
  2021-02-26 22:31                                                                   ` Marlon Richert
  1 sibling, 0 replies; 114+ messages in thread
From: dana @ 2021-02-25 16:58 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list, Marlon Richert

On 25 Feb 2021, at 02:05, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> In this specific case, however, which downstreams actually ship
> a recommended zshrc?  I suspect few do, so we can contact them directly.

That's a good point, i think i was imagining further-reaching consequences
than it will actually have when i first mentioned it. Anyway, Debian, Ubuntu,
and their derivatives are the only ones i know of. Google suggests Kali Linux
has its own (it doesn't just use Debian's), but i don't know much about that
distro. macOS and Homebrew definitely don't use it. It looks like Fedora uses
skel, so they'll never see the change at all :/

dana



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-25  8:05                                                                 ` Daniel Shahaf
  2021-02-25 16:58                                                                   ` dana
@ 2021-02-26 22:31                                                                   ` Marlon Richert
  2021-02-27 13:21                                                                     ` Daniel Shahaf
  1 sibling, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-02-26 22:31 UTC (permalink / raw)
  To: Daniel Shahaf, dana, Bart Schaefer, Oliver Kiddle; +Cc: Zsh hackers list

On Thu, Feb 25, 2021 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> In general, there's <https://repology.org/project/zsh/versions>, but
> I don't think we should rely on it.  If we have a question to downstream
> maintainers, we should ask it on an appropriate mailing list — e.g.,
> -workers@, or workers@ with an appropriate subject prefix/tag, or as
> a drive-by mention in the next email to announce@.
>
> In this specific case, however, which downstreams actually ship
> a recommended zshrc?  I suspect few do, so we can contact them directly.
> For Debian, we should address our questions to pkg-zsh-devel
> alioth-lists.debian.net.  (Those already familiar with bugs.debian.org
> incantations may prefer to create a bug with X-Debbugs-Cc instead.)

Since I have little experience with downstream packagers, I'll leave
it up to you to contact them. However, it would be great if you could
CC me in the correspondence, so I can read their feedback first-hand.

In the meantime, here's another update to the code for you to review:
https://gitlab.com/marlonrichert/zsh-sensible/-/commit/799be4eccb870b5fc7b8563008e4b2547448ab40?w=1


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-26 22:31                                                                   ` Marlon Richert
@ 2021-02-27 13:21                                                                     ` Daniel Shahaf
  2021-02-27 13:46                                                                       ` Daniel Shahaf
                                                                                         ` (2 more replies)
  0 siblings, 3 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-02-27 13:21 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Marlon Richert wrote on Sat, Feb 27, 2021 at 00:31:27 +0200:
> On Thu, Feb 25, 2021 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > In general, there's <https://repology.org/project/zsh/versions>, but
> > I don't think we should rely on it.  If we have a question to downstream
> > maintainers, we should ask it on an appropriate mailing list — e.g.,
> > -workers@, or workers@ with an appropriate subject prefix/tag, or as
> > a drive-by mention in the next email to announce@.
> >
> > In this specific case, however, which downstreams actually ship
> > a recommended zshrc?  I suspect few do, so we can contact them directly.
> > For Debian, we should address our questions to pkg-zsh-devel
> > alioth-lists.debian.net.  (Those already familiar with bugs.debian.org
> > incantations may prefer to create a bug with X-Debbugs-Cc instead.)
> 
> Since I have little experience with downstream packagers, I'll leave
> it up to you to contact them. However, it would be great if you could
> CC me in the correspondence, so I can read their feedback first-hand.

They're just people.  They maintain glue code that ties their distro's
build system (ports(7), deb, rpm, …) to our tarballs, as well as any
custom patches or configuration their distro uses.  If you have
a question for them, you can drop them a line and ask, or start a thread
here and then drop them a line to make sure they're aware of it (not all
downstream maintainers necessarily follow -workers@ closely).

In the latter case I'd recommend to use some subject tag that downstream
maintainers can simply filter their -workers@ subscription for on an
ongoing basis, in order to remove the need for manual notifications in
the future.

> In the meantime, here's another update to the code for you to review:
> https://gitlab.com/marlonrichert/zsh-sensible/-/commit/799be4eccb870b5fc7b8563008e4b2547448ab40?w=1

Here's another bit of code that might be useful:

if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]} )); then
  # vi mode for menu selection
  bindkey -M menuselect j down-line-or-history
  bindkey -M menuselect k up-line-or-history
  bindkey -M menuselect h backward-char
  bindkey -M menuselect l forward-char
  # Make <space> accept the completion-so-far,
  bindkey -M 'menuselect' ' ' accept-line # same binding as ^M,^J; and see above
fi

I haven't actually 


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-27 13:21                                                                     ` Daniel Shahaf
@ 2021-02-27 13:46                                                                       ` Daniel Shahaf
  2021-03-19 22:12                                                                       ` Marlon Richert
  2021-03-24 10:00                                                                       ` Marlon Richert
  2 siblings, 0 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-02-27 13:46 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Daniel Shahaf wrote on Sat, 27 Feb 2021 13:21 +00:00:
> Here's another bit of code that might be useful:
> 
> if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]} )); then
>   # vi mode for menu selection
>   bindkey -M menuselect j down-line-or-history
>   bindkey -M menuselect k up-line-or-history
>   bindkey -M menuselect h backward-char
>   bindkey -M menuselect l forward-char
>   # Make <space> accept the completion-so-far,
>   bindkey -M 'menuselect' ' ' accept-line # same binding as ^M,^J; and see above
> fi
> 
> I haven't actually 

(Oops.  Ignore that incomplete sentence.)




^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-27 13:21                                                                     ` Daniel Shahaf
  2021-02-27 13:46                                                                       ` Daniel Shahaf
@ 2021-03-19 22:12                                                                       ` Marlon Richert
  2021-03-24 13:45                                                                         ` gi1242+zsh
                                                                                           ` (2 more replies)
  2021-03-24 10:00                                                                       ` Marlon Richert
  2 siblings, 3 replies; 114+ messages in thread
From: Marlon Richert @ 2021-03-19 22:12 UTC (permalink / raw)
  To: Daniel Shahaf, Bart Schaefer, dana, Oliver Kiddle; +Cc: Zsh hackers list

Hi all! I pushed in another update:
https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

I reorganized the entire .zshrc file in an effort to make it easier to
read. I'd love to get your feedback.

Also, I'm wondering: How do you plan to make a decision on moving
forward with this? At which point are the new files good enough to
replace the existing zsh-newuser-install?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-27 13:21                                                                     ` Daniel Shahaf
  2021-02-27 13:46                                                                       ` Daniel Shahaf
  2021-03-19 22:12                                                                       ` Marlon Richert
@ 2021-03-24 10:00                                                                       ` Marlon Richert
  2021-03-25  1:15                                                                         ` Daniel Shahaf
  2 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-03-24 10:00 UTC (permalink / raw)
  To: Daniel Shahaf, dana, Bart Schaefer; +Cc: Zsh hackers list

On Sat, Feb 27, 2021 at 3:21 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > On Thu, Feb 25, 2021 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > In general, there's <https://repology.org/project/zsh/versions>, but
> > > I don't think we should rely on it.  If we have a question to downstream
> > > maintainers, we should ask it on an appropriate mailing list — e.g.,
> > > -workers@, or workers@ with an appropriate subject prefix/tag, or as
> > > a drive-by mention in the next email to announce@.
>
> They're just people.  They maintain glue code that ties their distro's
> build system (ports(7), deb, rpm, …) to our tarballs, as well as any
> custom patches or configuration their distro uses.  If you have
> a question for them, you can drop them a line and ask, or start a thread
> here and then drop them a line to make sure they're aware of it (not all
> downstream maintainers necessarily follow -workers@ closely).
>
> In the latter case I'd recommend to use some subject tag that downstream
> maintainers can simply filter their -workers@ subscription for on an
> ongoing basis, in order to remove the need for manual notifications in
> the future.

On Thu, Feb 25, 2021 at 6:58 PM dana <dana@dana.is> wrote:
>
> On 25 Feb 2021, at 02:05, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > In this specific case, however, which downstreams actually ship
> > a recommended zshrc?  I suspect few do, so we can contact them directly.
>
> That's a good point, i think i was imagining further-reaching consequences
> than it will actually have when i first mentioned it. Anyway, Debian, Ubuntu,
> and their derivatives are the only ones i know of. Google suggests Kali Linux
> has its own (it doesn't just use Debian's), but i don't know much about that
> distro. macOS and Homebrew definitely don't use it. It looks like Fedora uses
> skel, so they'll never see the change at all :/

Can one of you point me in the right direction? The number of mailing
lists for Debian and Ubuntu is HUGE, but then for Kali Linux, I cannot
find a mailing list at all. I have no idea where I should post for any
of these.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-19 22:12                                                                       ` Marlon Richert
@ 2021-03-24 13:45                                                                         ` gi1242+zsh
  2021-03-24 14:16                                                                           ` Paul
  2021-03-24 17:44                                                                           ` Bart Schaefer
  2021-03-25  3:36                                                                         ` Paul
  2021-04-05 18:16                                                                         ` Daniel Shahaf
  2 siblings, 2 replies; 114+ messages in thread
From: gi1242+zsh @ 2021-03-24 13:45 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Few suggestions from a lurker (feel free to ignore).

1. In zrestart: exec zsh -l instead of zsh -l && exit

2. HISTFILE location: XDG conventions suggest putting things in
   .cache/zsh

3. Same with completion cache, recent dirs file, etc.

Also, what I'd like to see in a default zshrc is something that's not
going to set personal preference options by default (clobber/globstar),
but give the user many commented options that they can change quickly
without having to read 300 man pages.

As a result I would only put in things that give the user "least
surprise", and is still functional. So I would leave in history saving,
colors, prompt, highlighting, completion and maybe even a few **really
really** standard keybindings defined. (I also think Ctrl Y is more
standard than alt ctrl z for redo btw). However I would comment out
everything else (autocd, pushd, globstar, and especially clobber). 

I would also put some commented out bindings to set vi mode. (That's all
I use myself.)

This should let most users just use it out of the box and get colorful
prompts / nice completion; and if they want their favorite options they
can just edit the files and find the more common options there...

GI

-- 
Two banks with different rates have a conflict of interest.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-24 13:45                                                                         ` gi1242+zsh
@ 2021-03-24 14:16                                                                           ` Paul
  2021-03-24 17:44                                                                           ` Bart Schaefer
  1 sibling, 0 replies; 114+ messages in thread
From: Paul @ 2021-03-24 14:16 UTC (permalink / raw)
  To: gi1242+zsh, Marlon Richert; +Cc: Zsh hackers list

On Wed Mar 24, 2021 at 8:45 AM CDT,  wrote:
> As a result I would only put in things that give the user "least
> surprise", and is still functional. So I would leave in history saving,
> colors, prompt, highlighting, completion and maybe even a few **really
> really** standard keybindings defined.

One could argue that the history saving, colors, prompt and completions
are "surprising".

> (I also think Ctrl Y is more standard than alt ctrl z for redo btw).

Agree. Ctrl-Shift-Z would be even nicer, but not possible to bind.

> However I would comment out everything else (autocd, pushd, globstar,
> and especially clobber).

I don't think autocd or globstarshort would cause *any* bad surprises.

- Without autocd, users just get an "permission denied" error instead
  of cd'ing. For all its flaws, OhMyZsh sets autocd and it is one of
  the most commonly cited "features" by novice OMZ users.

- globstarshort makes '**' match Bash's globstar behavior.

- pushd/popd aren't that commonly used. I could see autopushd being
  problematic for *some* users. *However*, this should be set if the
  Alt-Minus and Alt-Equals bindings are to be of any use to most users.
  Like autocd, this is a feature that most users will quickly miss when
  switching back to other shells.

- I half-agree with not unsetting clobber. noclobber is better default
  behavior (it prevents much more damaging surprises), but just seeing
  "file exists" or "no such file or directory" without any '>|' or '>>|'
  suggestion is frustrating.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-24 13:45                                                                         ` gi1242+zsh
  2021-03-24 14:16                                                                           ` Paul
@ 2021-03-24 17:44                                                                           ` Bart Schaefer
  2021-03-24 20:38                                                                             ` Marlon Richert
  1 sibling, 1 reply; 114+ messages in thread
From: Bart Schaefer @ 2021-03-24 17:44 UTC (permalink / raw)
  To: gi1242+zsh, Marlon Richert, Zsh hackers list

On Wed, Mar 24, 2021 at 6:46 AM <gi1242+zsh@gmail.com> wrote:
>
> 1. In zrestart: exec zsh -l instead of zsh -l && exit

We already discussed this earlier in this thread.  If there's an error
in the file, "exec" will kill the shell leaving the error in place,
and thus potentially make it impossible to log in again.

>
> 2. HISTFILE location: XDG conventions suggest putting things in
>    .cache/zsh

Discussed this too, and rejected dependence on XDG, I believe.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-24 17:44                                                                           ` Bart Schaefer
@ 2021-03-24 20:38                                                                             ` Marlon Richert
  0 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-03-24 20:38 UTC (permalink / raw)
  To: Bart Schaefer, gi1242+zsh, Paul; +Cc: Zsh hackers list

On Wed, Mar 24, 2021 at 7:45 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > 2. HISTFILE location: XDG conventions suggest putting things in
> >    .cache/zsh
>
> Discussed this too, and rejected dependence on XDG, I believe.

"Rejected" is a bit of an overstatement. I instead made it a choice in
the `zsh-newuser-install` wizard:
https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zsh-newuser-install

To safely try out the new wizard, do this:

% cd $(mktemp -d)
% git clone --depth 1 -- https://gitlab.com/marlonrichert/zsh-sensible.git
% unset _comp_dumpfile ZDOTDIR XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME
% FPATH=$PWD/zsh-sensible:$FPATH HOME=$PWD PS1='%# ' exec zsh

Then the wizard will start automatically, but without affecting your
current dotfiles.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-24 10:00                                                                       ` Marlon Richert
@ 2021-03-25  1:15                                                                         ` Daniel Shahaf
  2021-04-05 14:00                                                                           ` Marlon Richert
  0 siblings, 1 reply; 114+ messages in thread
From: Daniel Shahaf @ 2021-03-25  1:15 UTC (permalink / raw)
  To: Marlon Richert; +Cc: dana, Bart Schaefer, Zsh hackers list

Marlon Richert wrote on Wed, Mar 24, 2021 at 12:00:17 +0200:
> On Sat, Feb 27, 2021 at 3:21 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > On Thu, Feb 25, 2021 at 10:05 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > > In general, there's <https://repology.org/project/zsh/versions>, but
> > > > I don't think we should rely on it.  If we have a question to downstream
> > > > maintainers, we should ask it on an appropriate mailing list — e.g.,
> > > > -workers@, or workers@ with an appropriate subject prefix/tag, or as
> > > > a drive-by mention in the next email to announce@.
> >
> > They're just people.  They maintain glue code that ties their distro's
> > build system (ports(7), deb, rpm, …) to our tarballs, as well as any
> > custom patches or configuration their distro uses.  If you have
> > a question for them, you can drop them a line and ask, or start a thread
> > here and then drop them a line to make sure they're aware of it (not all
> > downstream maintainers necessarily follow -workers@ closely).
> >
> > In the latter case I'd recommend to use some subject tag that downstream
> > maintainers can simply filter their -workers@ subscription for on an
> > ongoing basis, in order to remove the need for manual notifications in
> > the future.
> 
> On Thu, Feb 25, 2021 at 6:58 PM dana <dana@dana.is> wrote:
> >
> > On 25 Feb 2021, at 02:05, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > In this specific case, however, which downstreams actually ship
> > > a recommended zshrc?  I suspect few do, so we can contact them directly.
> >
> > That's a good point, i think i was imagining further-reaching consequences
> > than it will actually have when i first mentioned it. Anyway, Debian, Ubuntu,
> > and their derivatives are the only ones i know of. Google suggests Kali Linux
> > has its own (it doesn't just use Debian's), but i don't know much about that
> > distro. macOS and Homebrew definitely don't use it. It looks like Fedora uses
> > skel, so they'll never see the change at all :/
> 
> Can one of you point me in the right direction? The number of mailing
> lists for Debian and Ubuntu is HUGE, but then for Kali Linux, I cannot
> find a mailing list at all. I have no idea where I should post for any
> of these.

For Debian, the maintainers are listed at
<https://tracker.debian.org/pkg/zsh>.  There's a mailing list, so you
can just email that.  In general, Debian tends to like things being
organized around bug reports, but filing a bug without reportbug(1)
isn't the most user-friendly workflow in the world, so I'll gloss over
it for now.

Other distros generally have browsable package indexes that list the
current version and maintainer of each package.  There's also 
https://repology.org/project/zsh/versions which lists information from
multiple distros.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-19 22:12                                                                       ` Marlon Richert
  2021-03-24 13:45                                                                         ` gi1242+zsh
@ 2021-03-25  3:36                                                                         ` Paul
  2021-04-05 18:16                                                                         ` Daniel Shahaf
  2 siblings, 0 replies; 114+ messages in thread
From: Paul @ 2021-03-25  3:36 UTC (permalink / raw)
  To: Marlon Richert, Daniel Shahaf, Bart Schaefer, dana, Oliver Kiddle
  Cc: Zsh hackers list


> 	zle -N zle-line-init .zshrc.app-mode; .zshrc.app-mode() { echoti smkx }
> 	if [[ -n "$terminfo[rmkx]" ]]; then
> 	  zle -N zle-line-finish .zshrc.raw-mode; .zshrc.raw-mode() { echoti rmkx }
> 	fi

Might I suggest:

	autoload add-zle-hook-widget
	add-zle-hook-widget zle-line-init .zshrc.app-mode; .zshrc.app-mode() { echoti smkx }
	if [[ -n "$terminfo[rmkx]" ]]; then
	  add-zle-hook-widget zle-line-finish .zshrc.raw-mode; .zshrc.raw-mode() { echoti rmkx }
	fi

Unless we expect users to migrate this config to older versions of Zsh.
 


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-25  1:15                                                                         ` Daniel Shahaf
@ 2021-04-05 14:00                                                                           ` Marlon Richert
  2021-04-05 18:36                                                                             ` Daniel Shahaf
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon Richert @ 2021-04-05 14:00 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: dana, Bart Schaefer, Zsh hackers list

On Thu, Mar 25, 2021 at 3:15 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> For Debian, the maintainers are listed at
> <https://tracker.debian.org/pkg/zsh>.  There's a mailing list, so you
> can just email that.  In general, Debian tends to like things being
> organized around bug reports, but filing a bug without reportbug(1)
> isn't the most user-friendly workflow in the world, so I'll gloss over
> it for now.
>
> Other distros generally have browsable package indexes that list the
> current version and maintainer of each package.  There's also
> https://repology.org/project/zsh/versions which lists information from
> multiple distros.

On March 25th, I sent out an RFC by email to the Zsh package
maintainers of all Linux distros that I could find that include a
custom .zshrc file for new users:
* Debian
* Adélie
* ALT Linux
* openSUSE
* Fedora

I got replies so far from openSUSE and Fedora, and made some minor
changes based on their feedback:
https://gitlab.com/marlonrichert/zsh-sensible/-/commit/b111f20b14891af4a385b3867fe690dc8281fe8f

The only feedback that I didn't act on was the observation that the
use of $RPS1 could feel confusing to users coming from Bash. I'm not
sure I want to do anything about that; I think that not using $RPS1
would actually make the current prompt worse. Otherwise, their
feedback was all positive.

I haven't heard anything from Debian's, Adélie's and ALT Linux's Zsh
package maintainers yet.

Should I ping them again or just wait a bit longer?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-03-19 22:12                                                                       ` Marlon Richert
  2021-03-24 13:45                                                                         ` gi1242+zsh
  2021-03-25  3:36                                                                         ` Paul
@ 2021-04-05 18:16                                                                         ` Daniel Shahaf
  2021-04-05 18:52                                                                           ` Sorting of <-> (was Re: Rewrite of zsh-newuser-install) Bart Schaefer
                                                                                             ` (3 more replies)
  2 siblings, 4 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-04-05 18:16 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

[ for skimmers: there's an unrelated question in the P.S.. ]

Marlon Richert wrote on Sat, Mar 20, 2021 at 00:12:28 +0200:
> Hi all! I pushed in another update:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc
> 
> I reorganized the entire .zshrc file in an effort to make it easier to
> read. I'd love to get your feedback.
> 
> Also, I'm wondering: How do you plan to make a decision on moving
> forward with this? At which point are the new files good enough to
> replace the existing zsh-newuser-install?

Here's a quick review of zshrc and your version of zsh-newuser-install.

Haven't read the entire thread yet, so apologies if I'm repeating issues
previously raised.

Issues in the first-run wizard:

0. I recommend against reusing the name zsh-newuser-install for
a completely different thing.  Names shouldn't be overloaded.

1. Errors from «mkdir ZDOTDIR» are discarded.

2. Uses of eval are unsafe (lack ${(q)}) and unnecessary.

3. That also applies to the munging of $template.

4. "$zshrc~" is silently overwritten

5. what happens if the exec on the last line fails?

6. Outputting `man zsh' in two different colours is confusing.

7. zsh's homepage is https://www.zsh.org/.

8. zrestart doesn't handle $ZDOTDIR.

9. For educational purposes, printing should use «print -r --» throughout.

10. Should zrestart use «exec»?

11. «print '\n'» prints _two_ newlines.  That's too obscure for
educational code.

Issues in zshrc:

12. Some settings seems like they could break the principle of least
surprise: e.g., FLOW_CONTROL, NUMERIC_GLOB_SORT, matcher 'b:-=+',
check-for-changes (as opposed to check-for-staged-changes).

13. Recommend not to hide symbols from grep, as in up-line-or-{search,history}

14. Use of «bindkey -s … '^Q…'» seems questionable.  As a way to inject
commands, it prints them to the tty and adds them to the history; that
doesn't seem elegant enough for example code that all new users would be
pointed to.  It's also brittle in that it depends on ^Q not being
re-bindkey'd to anything else.

A few proposed additions:

15. hjkl bindings for menu selection:

    if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]} )); then
      bindkey -M menuselect j down-line-or-history
      bindkey -M menuselect k up-line-or-history
      bindkey -M menuselect h backward-char
      bindkey -M menuselect l forward-char
    fi

17. Configure vcs_info to show the original patch's information during
rebases, etc..  It basically boils down to doing
«hook_com[applied-string]=$1» in a gen-applied-string hook.  I posted
a fuller version in workers/47519 at the end.

18. Show how to use terminal colours/attributes other than the basic
ones.  E.g., I use ${terminfo[dim]} in some places.

Cheers,

Daniel

P.S.  I wonder if «: <->» should always behave as though
NUMERIC_GLOB_SORT is set.  Haven't tried to nail down a complete
functional spec yet; just thinking out loud.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-05 14:00                                                                           ` Marlon Richert
@ 2021-04-05 18:36                                                                             ` Daniel Shahaf
  2021-04-05 19:22                                                                               ` Daniel Shahaf
  0 siblings, 1 reply; 114+ messages in thread
From: Daniel Shahaf @ 2021-04-05 18:36 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Marlon Richert wrote on Mon, Apr 05, 2021 at 17:00:20 +0300:
> I haven't heard anything from Debian's, Adélie's and ALT Linux's Zsh
> package maintainers yet.
> 
> Should I ping them again or just wait a bit longer?

They'll have read your first message to them.  What would be the reason
to ping them again?  Is there an impending code change that would affect
the to-be-pinged downstreams' users, patches, etc.?

Your message to them was phrased as "Please review this patch to the
upstream project".  Pinging such a request could be taken for
entitlement, especially given that patches to the upstream project
should be discussed upstream, and that you've received some reviews
already, including from other downstreams.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Sorting of <-> (was Re: Rewrite of zsh-newuser-install)
  2021-04-05 18:16                                                                         ` Daniel Shahaf
@ 2021-04-05 18:52                                                                           ` Bart Schaefer
  2021-04-05 21:31                                                                           ` Rewrite of zsh-newuser-install gammafunction
                                                                                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 114+ messages in thread
From: Bart Schaefer @ 2021-04-05 18:52 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Marlon Richert, Zsh hackers list

On Mon, Apr 5, 2021 at 11:17 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> P.S.  I wonder if «: <->» should always behave as though
> NUMERIC_GLOB_SORT is set.

I think it would be confusing (let alone difficult to implement) if
NUMERIC_GLOB_SORT applied only to a substring of the matches.  That
is, if I have say « foo<->bar* » and there is a trailing numeric
component matched by the « * », what happens?  What about say «
[1-9]<->[2468] » ?  Patterns with « (...|...) » where « <-> » appears
only in one branch?


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-05 18:36                                                                             ` Daniel Shahaf
@ 2021-04-05 19:22                                                                               ` Daniel Shahaf
  0 siblings, 0 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-04-05 19:22 UTC (permalink / raw)
  To: Marlon Richert; +Cc: Zsh hackers list

Daniel Shahaf wrote on Mon, 05 Apr 2021 18:36 +00:00:
> Marlon Richert wrote on Mon, Apr 05, 2021 at 17:00:20 +0300:
> > I haven't heard anything from Debian's, Adélie's and ALT Linux's Zsh
> > package maintainers yet.
> > 
> > Should I ping them again or just wait a bit longer?
> 
> They'll have read your first message to them.  What would be the reason
> to ping them again?  Is there an impending code change that would affect
> the to-be-pinged downstreams' users, patches, etc.?
> 
> Your message to them was phrased as "Please review this patch to the
> upstream project".

That's a paraphrase, not a quote.

> Pinging such a request could be taken for
> entitlement, especially given that patches to the upstream project
> should be discussed upstream, and that you've received some reviews
> already, including from other downstreams.
> 
> Cheers,
> 
> Daniel
> 
>


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-05 18:16                                                                         ` Daniel Shahaf
  2021-04-05 18:52                                                                           ` Sorting of <-> (was Re: Rewrite of zsh-newuser-install) Bart Schaefer
@ 2021-04-05 21:31                                                                           ` gammafunction
  2021-04-07 14:45                                                                           ` Marlon
  2021-04-07 18:17                                                                           ` Mikael Magnusson
  3 siblings, 0 replies; 114+ messages in thread
From: gammafunction @ 2021-04-05 21:31 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Marlon Richert, Zsh hackers list

On Mon Apr 5, 2021 at 1:16 PM CDT, Daniel Shahaf wrote:
> 0. I recommend against reusing the name zsh-newuser-install for
> a completely different thing. Names shouldn't be overloaded.
> 
> 11. «print '\n'» prints _two_ newlines. That's too obscure for
> educational code.

zsh-newusers-install is replacing the old zsh-newusers-install.
This isn't educational code like the rest of the files in the
repo are.

> {1..4} {6..9}

+1 on all these.

> 5. what happens if the exec on the last line fails?
> 
> 10. Should zrestart use «exec»?

(Addressed previously) zrestart doesn't use exec because it
could fail due to an error in the zshrc that wasn't caught
by the zsh -n line before.

That said, the same should apply to the newusers function.

> 12. Some settings seems like they could break the principle of least
> surprise: e.g., FLOW_CONTROL, NUMERIC_GLOB_SORT, matcher 'b:-=+',
> check-for-changes (as opposed to check-for-staged-changes).

- FLOW_CONTROL is unset by default, the line can be removed
- Not sure about NUMERIC_GLOB_SORT, do you have a surprising example?
- The 'b:-=+' is only prefixes, and only for the options tag. I would
   actually almost prefer 'b:-=[^[:alnum:]]' to catch all kinds of 
obscure
   option styles programs use, make them discoverable from just typing 
'-'.
- (No comment on check-for-changes)

> 13. Recommend not to hide symbols from grep, as i
> up-line-or-{search,history}

I agree, brace expansions make it hard to search.

> 14. Use of «bindkey -s … '^Q…'» seems questionable. As a way to inject
> commands, it prints them to the tty and adds them to the history; that
> doesn't seem elegant enough for example code that all new users would 
> be
> pointed to.

(Personally) I would rather directory changes being added to history.

> It's also brittle in that it depends on ^Q not being
> re-bindkey'd to anything else.

I can write a proper widget.

> 15. hjkl bindings for menu selection:

I type during menu selection, and users will be able to as well.
I think being able to type normally, except for a select few letters
would be confusing.

> 18. Show how to use terminal colours/attributes other than the basic
> ones. E.g., I use ${terminfo[dim]} in some places.

We already 'autoload -Uz colors; colors', so $colors[faint] may be
preferred. Although it doesn't have \e[ like $terminfo[dim] does.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-05 18:16                                                                         ` Daniel Shahaf
  2021-04-05 18:52                                                                           ` Sorting of <-> (was Re: Rewrite of zsh-newuser-install) Bart Schaefer
  2021-04-05 21:31                                                                           ` Rewrite of zsh-newuser-install gammafunction
@ 2021-04-07 14:45                                                                           ` Marlon
  2021-04-09 16:49                                                                             ` Marlon
  2021-04-07 18:17                                                                           ` Mikael Magnusson
  3 siblings, 1 reply; 114+ messages in thread
From: Marlon @ 2021-04-07 14:45 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list



> On 5. Apr 2021, at 21.16, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 
> 1. Errors from «mkdir ZDOTDIR» are discarded.
> 
> 2. Uses of eval are unsafe (lack ${(q)}) and unnecessary.
> 
> 3. That also applies to the munging of $template.
> 
> 4. "$zshrc~" is silently overwritten

Thanks, I’ll try to fix those.


> 6. Outputting `man zsh' in two different colours is confusing.
> 
> 7. zsh's homepage is https://www.zsh.org/.
> 
> 8. zrestart doesn't handle $ZDOTDIR.
> 
> 9. For educational purposes, printing should use «print -r --» throughout.

Same for these.


> 18. Show how to use terminal colours/attributes other than the basic
> ones.  E.g., I use ${terminfo[dim]} in some places.

Sure, that sounds like a good idea. I wasn’t aware of $terminfo[dim].



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-05 18:16                                                                         ` Daniel Shahaf
                                                                                             ` (2 preceding siblings ...)
  2021-04-07 14:45                                                                           ` Marlon
@ 2021-04-07 18:17                                                                           ` Mikael Magnusson
  2021-04-07 18:56                                                                             ` Daniel Shahaf
  3 siblings, 1 reply; 114+ messages in thread
From: Mikael Magnusson @ 2021-04-07 18:17 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Marlon Richert, Zsh hackers list

On 4/5/21, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> 15. hjkl bindings for menu selection:
>
>     if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]}
> )); then
>       bindkey -M menuselect j down-line-or-history
>       bindkey -M menuselect k up-line-or-history
>       bindkey -M menuselect h backward-char
>       bindkey -M menuselect l forward-char
>     fi

This sucks for people that don't use qwerty :). Easy enough to delete
though I suppose. I guess it would also break the "interactive" mode.

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-07 18:17                                                                           ` Mikael Magnusson
@ 2021-04-07 18:56                                                                             ` Daniel Shahaf
  0 siblings, 0 replies; 114+ messages in thread
From: Daniel Shahaf @ 2021-04-07 18:56 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Marlon Richert, Zsh hackers list

Mikael Magnusson wrote on Wed, 07 Apr 2021 18:17 +00:00:
> On 4/5/21, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > 15. hjkl bindings for menu selection:
> >
> >     if zmodload zsh/complist 2>/dev/null || (( ${+keymaps[(r)menuselect]}
> > )); then
> >       bindkey -M menuselect j down-line-or-history
> >       bindkey -M menuselect k up-line-or-history
> >       bindkey -M menuselect h backward-char
> >       bindkey -M menuselect l forward-char
> >     fi
> 
> This sucks for people that don't use qwerty :). Easy enough to delete
> though I suppose.

Could at least make it conditional on [[ ! -o dvorak ]] to get closer to
100% coverage.

> I guess it would also break the "interactive" mode.


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-07 14:45                                                                           ` Marlon
@ 2021-04-09 16:49                                                                             ` Marlon
  2021-04-09 23:14                                                                               ` Daniel Shahaf
  0 siblings, 1 reply; 114+ messages in thread
From: Marlon @ 2021-04-09 16:49 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list


> On 7 Apr 2021, at 17:45, Marlon <marlon.richert@gmail.com> wrote:
>> 18. Show how to use terminal colours/attributes other than the basic
>> ones.  E.g., I use ${terminfo[dim]} in some places.
> 
> Sure, that sounds like a good idea. I wasn’t aware of $terminfo[dim].

Where would I use it, though? I can’t really find a good place for it.

Where I would really like to use it is in $zle_highlight, but it’s not supported there. :(



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-09 16:49                                                                             ` Marlon
@ 2021-04-09 23:14                                                                               ` Daniel Shahaf
  2021-04-10  1:17                                                                                 ` Oliver Kiddle
  0 siblings, 1 reply; 114+ messages in thread
From: Daniel Shahaf @ 2021-04-09 23:14 UTC (permalink / raw)
  To: Marlon; +Cc: Zsh hackers list

Marlon wrote on Fri, Apr 09, 2021 at 19:49:56 +0300:
> 
> > On 7 Apr 2021, at 17:45, Marlon <marlon.richert@gmail.com> wrote:
> >> 18. Show how to use terminal colours/attributes other than the basic
> >> ones.  E.g., I use ${terminfo[dim]} in some places.
> > 
> > Sure, that sounds like a good idea. I wasn’t aware of $terminfo[dim].
> 
> Where would I use it, though? I can’t really find a good place for it.

Then make one up, or use some other code, e.g., 

% man 5 terminfo | grep italic
          enter_italics_mode          sitm      ZH     Enter italic mode
          exit_italics_mode           ritm      ZR     End italic mode
⋮
% 

FWIW, I use dim in my vcs_info output (see 47519, referenced by 48435).

> Where I would really like to use it is in $zle_highlight, but it’s not supported there. :(

Incidentally, just yesterday z-sy-h received a (duplicate) bug report
requesting, ultimately, that $zle_highlight grow support for italics.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-04-09 23:14                                                                               ` Daniel Shahaf
@ 2021-04-10  1:17                                                                                 ` Oliver Kiddle
  0 siblings, 0 replies; 114+ messages in thread
From: Oliver Kiddle @ 2021-04-10  1:17 UTC (permalink / raw)
  To: Zsh hackers list

Daniel Shahaf wrote:
> FWIW, I use dim in my vcs_info output (see 47519, referenced by 48435).

The dim attribute doesn't appear to have any effect with my terminal
emulator.

> > Where I would really like to use it is in $zle_highlight, but it’s not supported there. :(
>
> Incidentally, just yesterday z-sy-h received a (duplicate) bug report
> requesting, ultimately, that $zle_highlight grow support for italics.

I did recently apply 47510 (0721060) which makes two bits available in
zattr which would be enough for one attribute, i.e. italics. Would now
be fairly easy to add if someone wants to give it a go - just copy and
paste from bold/reverse/underline. Only danger is if we find that 47510
causes problems and needs to be backed out.

Oliver


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: Rewrite of zsh-newuser-install
  2021-02-12 23:26                                             ` Oliver Kiddle
  2021-02-13  0:15                                               ` Marlon Richert
  2021-02-13  1:28                                               ` Bart Schaefer
@ 2021-04-22 13:57                                               ` Marlon Richert
  2 siblings, 0 replies; 114+ messages in thread
From: Marlon Richert @ 2021-04-22 13:57 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

On 13 Feb 2021, at 01:26, Oliver Kiddle <opk@zsh.org> wrote:
>> # Use `exec zsh` to apply changes after editing this file.
> 
> Not sure I'd recommend that because if you mistype "zsh", your shell+terminal
> disappears. And if they've broken .zshrc, that can leave them unable to log
> back in.

What exactly would you have to put into your .zshrc file to make it so broken that you’re unable to log in?




^ permalink raw reply	[flat|nested] 114+ messages in thread

end of thread, other threads:[~2021-04-22 13:57 UTC | newest]

Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-06 20:03 Rewrite of zsh-newuser-install Marlon Richert
     [not found] ` <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com>
2021-02-06 20:19   ` Marlon Richert
2021-02-06 20:33     ` Lawrence Velázquez
2021-02-06 21:54       ` Bart Schaefer
2021-02-07 13:41       ` Marlon Richert
2021-02-07 13:51         ` Roman Perepelitsa
2021-02-07 17:10           ` Marlon Richert
2021-02-07 17:28             ` Marlon Richert
2021-02-07 20:20               ` Bart Schaefer
2021-02-07 21:06             ` dana
2021-02-07 21:15               ` Marlon Richert
2021-02-08 21:57                 ` Marlon Richert
2021-02-08 23:33                   ` Lawrence Velázquez
2021-02-09  1:42                   ` Bart Schaefer
2021-02-09  2:00                     ` Bart Schaefer
2021-02-09  8:18                       ` Marlon Richert
2021-02-09 23:09                         ` Bart Schaefer
2021-02-09  8:17                     ` Marlon Richert
2021-02-09  8:29                       ` Roman Perepelitsa
2021-02-09 23:16                         ` Bart Schaefer
2021-02-12  0:09                       ` Bart Schaefer
2021-02-12  5:58                         ` Marlon Richert
2021-02-09  4:51                   ` dana
2021-02-09  6:00                     ` Bart Schaefer
2021-02-09  7:30                       ` dana
2021-02-09  7:34                         ` dana
2021-02-09  9:55                       ` Marlon Richert
2021-02-09 10:01                         ` Roman Perepelitsa
2021-02-09 10:04                           ` Marlon Richert
2021-02-09 10:56                             ` dana
2021-02-09 11:14                               ` Roman Perepelitsa
2021-02-09 11:39                               ` Marlon Richert
2021-02-09 17:21                                 ` dana
2021-02-09 21:01                                   ` Marlon Richert
2021-02-09 21:41                                     ` Marlon Richert
2021-02-09 23:15                                       ` dana
2021-02-10  0:02                                         ` Bart Schaefer
2021-02-10  7:02                                           ` Marlon Richert
2021-02-10  6:57                                         ` Marlon Richert
2021-02-12  0:10                                           ` Bart Schaefer
2021-02-12  5:59                                             ` Roman Perepelitsa
2021-02-13  0:23                                               ` dana
2021-02-10  2:30                                       ` Bart Schaefer
2021-02-10  7:44                                         ` Marlon Richert
2021-02-10 20:27                                           ` Marlon Richert
2021-02-11  8:30                                             ` Bart Schaefer
2021-02-11 21:11                                               ` Marlon Richert
2021-02-11 22:57                                                 ` Bart Schaefer
2021-02-12  5:49                                                   ` Marlon Richert
2021-02-12  5:47                                               ` Marlon Richert
2021-02-12 23:43                                                 ` Oliver Kiddle
2021-02-13  1:11                                                 ` Bart Schaefer
2021-02-12 23:26                                             ` Oliver Kiddle
2021-02-13  0:15                                               ` Marlon Richert
2021-02-13  1:33                                                 ` Bart Schaefer
2021-02-13  1:36                                                 ` Oliver Kiddle
2021-02-13  2:53                                                   ` Bart Schaefer
2021-02-13 10:26                                                   ` Marlon Richert
2021-02-13 22:53                                                     ` Marlon Richert
2021-02-14  0:34                                                       ` Bart Schaefer
2021-02-14  8:12                                                         ` Marlon Richert
2021-02-13 22:56                                                     ` Bart Schaefer
2021-02-14  8:01                                                       ` Marlon Richert
2021-02-19 21:38                                                         ` Marlon Richert
2021-02-20  0:30                                                           ` dana
2021-02-20  8:18                                                             ` Marlon Richert
2021-02-20 18:57                                                               ` Bart Schaefer
2021-02-21 19:24                                                                 ` Marlon Richert
2021-02-24 22:15                                                               ` dana
2021-02-25  8:05                                                                 ` Daniel Shahaf
2021-02-25 16:58                                                                   ` dana
2021-02-26 22:31                                                                   ` Marlon Richert
2021-02-27 13:21                                                                     ` Daniel Shahaf
2021-02-27 13:46                                                                       ` Daniel Shahaf
2021-03-19 22:12                                                                       ` Marlon Richert
2021-03-24 13:45                                                                         ` gi1242+zsh
2021-03-24 14:16                                                                           ` Paul
2021-03-24 17:44                                                                           ` Bart Schaefer
2021-03-24 20:38                                                                             ` Marlon Richert
2021-03-25  3:36                                                                         ` Paul
2021-04-05 18:16                                                                         ` Daniel Shahaf
2021-04-05 18:52                                                                           ` Sorting of <-> (was Re: Rewrite of zsh-newuser-install) Bart Schaefer
2021-04-05 21:31                                                                           ` Rewrite of zsh-newuser-install gammafunction
2021-04-07 14:45                                                                           ` Marlon
2021-04-09 16:49                                                                             ` Marlon
2021-04-09 23:14                                                                               ` Daniel Shahaf
2021-04-10  1:17                                                                                 ` Oliver Kiddle
2021-04-07 18:17                                                                           ` Mikael Magnusson
2021-04-07 18:56                                                                             ` Daniel Shahaf
2021-03-24 10:00                                                                       ` Marlon Richert
2021-03-25  1:15                                                                         ` Daniel Shahaf
2021-04-05 14:00                                                                           ` Marlon Richert
2021-04-05 18:36                                                                             ` Daniel Shahaf
2021-04-05 19:22                                                                               ` Daniel Shahaf
2021-02-22  3:54                                                           ` Paul
2021-02-22  8:14                                                             ` Marlon Richert
2021-02-22 16:31                                                               ` Bug in compdescribe with matcher 'b:-=+' Bart Schaefer
2021-02-19 21:34                                                       ` Rewrite of zsh-newuser-install Marlon Richert
2021-02-13  1:28                                               ` Bart Schaefer
2021-02-13  1:34                                                 ` Bart Schaefer
2021-04-22 13:57                                               ` Marlon Richert
2021-02-09 23:05                                 ` Bart Schaefer
2021-02-09  9:44                     ` Marlon Richert
2021-02-09 18:13                       ` Greg Klanderman
2021-02-08  9:21               ` Peter Stephenson
2021-02-08  6:35             ` Daniel Shahaf
2021-02-08  8:44               ` Marlon Richert
2021-02-08  8:46                 ` Marlon Richert
2021-02-08 10:32                   ` Daniel Shahaf
2021-02-08 17:44                     ` Marlon Richert
2021-02-08 20:47                       ` Bart Schaefer
2021-02-09 21:44             ` Eric Cook
2021-02-09 22:34               ` Bart Schaefer
2021-02-07 20:22         ` Bart Schaefer

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git