* 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; 117+ 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] 117+ messages in thread
[parent not found: <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com>]
* 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ messages in thread
* Bug in compdescribe with matcher 'b:-=+' 2021-02-22 8:14 ` Marlon Richert @ 2021-02-22 16:31 ` Bart Schaefer 2021-06-14 8:28 ` Marlon Richert 0 siblings, 1 reply; 117+ 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] 117+ messages in thread
* Re: Bug in compdescribe with matcher 'b:-=+' 2021-02-22 16:31 ` Bug in compdescribe with matcher 'b:-=+' Bart Schaefer @ 2021-06-14 8:28 ` Marlon Richert 2021-08-12 12:03 ` Marlon Richert 0 siblings, 1 reply; 117+ messages in thread From: Marlon Richert @ 2021-06-14 8:28 UTC (permalink / raw) To: Zsh hackers list; +Cc: Paul, Daniel Shahaf, dana, Oliver Kiddle, Bart Schaefer Is there anybody who could look into this? On Mon, Feb 22, 2021 at 6:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > (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] 117+ messages in thread
* Re: Bug in compdescribe with matcher 'b:-=+' 2021-06-14 8:28 ` Marlon Richert @ 2021-08-12 12:03 ` Marlon Richert 2021-08-12 16:15 ` Bart Schaefer 0 siblings, 1 reply; 117+ messages in thread From: Marlon Richert @ 2021-08-12 12:03 UTC (permalink / raw) To: Zsh hackers list; +Cc: Jun T, Lawrence Velázquez For future reference: This was fixed in workers 49211 (commit b4dff9a8e85802afcd52e7798176ebeb5e662da9). Thanks, Jun T! On Mon, Jun 14, 2021 at 11:28 AM Marlon Richert <marlon.richert@gmail.com> wrote: > > Is there anybody who could look into this? > > On Mon, Feb 22, 2021 at 6:31 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > (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] 117+ messages in thread
* Re: Bug in compdescribe with matcher 'b:-=+' 2021-08-12 12:03 ` Marlon Richert @ 2021-08-12 16:15 ` Bart Schaefer 0 siblings, 0 replies; 117+ messages in thread From: Bart Schaefer @ 2021-08-12 16:15 UTC (permalink / raw) To: Marlon Richert; +Cc: Zsh hackers list, Jun T, Lawrence Velázquez On Thu, Aug 12, 2021 at 5:04 AM Marlon Richert <marlon.richert@gmail.com> wrote: > > For future reference: This was fixed in workers 49211 (commit > b4dff9a8e85802afcd52e7798176ebeb5e662da9). > > Thanks, Jun T! Indeed ... but I think it would be more accurate to say that 49211 avoids tickling the actual bug in the internals. ^ permalink raw reply [flat|nested] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ 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; 117+ 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] 117+ messages in thread
end of thread, other threads:[~2021-08-12 16:15 UTC | newest] Thread overview: 117+ 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-06-14 8:28 ` Marlon Richert 2021-08-12 12:03 ` Marlon Richert 2021-08-12 16:15 ` 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
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).