From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18896 invoked from network); 9 Feb 2021 04:51:34 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2021 04:51:34 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1612846294; b=vJr/S4ykJlco8iXQQjpFwpfyEvsWnWt71w9LIqoxRjRMU9WZjPTuOdufCmyt870+oVx37MAKE9 7r10BaMVM9VogSthYZm6lS9LE5s7Kh4M8APGlo08vXpRhP0jEYHYXCUjwKzy9d7bDYJ3ZfEgNE Fu1xyXYBR7459u4VMPbBjwllH4nibootthVnOxtE3nSnSTwOUdWOPho8THvMIGhHb9bIRwm6eY OjLkWK0BLeUpCnSALTDdyWLZIzBjMwPZQ0mqKvJfPY4JQc4LkJZM/TGpoH4IOmNtEj3Sm26X4w AoDKb89lp9b8E2rmKnzDn5z6RZDbL6f4EQBuZU8gmkQVDA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-io1-f49.google.com) smtp.remote-ip=209.85.166.49; dkim=pass header.d=dana-is.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=dana.is; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1612846294; bh=/d/pxV1G0Bz9zREPnHtfQhSSDBWtRPEIAmpe8nEQrTI=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:To:References:Message-ID:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:MIME-Version:Content-Type:DKIM-Signature: DKIM-Signature; b=tffOEm9SLHhGkadnUdUD5hifKUhUKF6uHgkbv+YOFYJlwDlq6RRYGb15sH5b/9a4DnMvyVyTs/ Af9UnSJ3tvCwMFVrob9BKarGAFFngPvH+5N5qCZXEniBPkBxF1GP27rh+wUfq645wd6GW717Vn UIAJWGop4n93mQSnoPAbRpLxC+AzqdQNrrqMY4dnMSVD3vPtORQSrVd2Dd8Nru8EJHS3l6OGfo y4OD3aeOnON7adH5B3DDkVCrFKxzJgmm8wPN5orHfnWhcQNxOrmohTnzp5CmLiVYHNFsN+T3TJ jn4Kb0AFzi4q/2eRoCU0mVX4C21T8ErA4WMLyx3woOyROA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=Rjh/LMxDHOca8jFH45bk5EvG5H5XPjnvSqhKEkJbCQE=; b=icJ9oRARr7hlk/Tfd7u8sJutkn FUIWPwNLRoLBgkl7I2xE9PIPiXtmSQ1AQYJL3HcTCd3GBOtMNQDpLqqMchNRifYjLO3Nr1u8tsR56 eKZrqAKE+hBTaOXugFh+7rJ3rixbmb4LWYBpUz0kgMlG5rlH7C5qFXchOZtXtGP0eLn2hU3I/IpN7 aZpsOVOfzZDEDWyVyQkXjrLfzOfRQ0fejrUg7VPqjdcBOLMxaM7sFGX9tNplzVfQf4KaiQZNrnP1O NqDhbBxbcwe34Fw7kmf+7ups6imVEkXg3Ce5pbUCIrhf26qVzPe7L3yIpaxyiNS3DB57A2BnTE6+v No1uUE7Q==; Received: from authenticated user by zero.zsh.org with local id 1l9Kzo-000Gkd-Gy; Tue, 09 Feb 2021 04:51:28 +0000 Authentication-Results: zsh.org; iprev=pass (mail-io1-f49.google.com) smtp.remote-ip=209.85.166.49; dkim=pass header.d=dana-is.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=dana.is; arc=none Received: from mail-io1-f49.google.com ([209.85.166.49]:39072) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1l9KzX-000Gb6-Q6; Tue, 09 Feb 2021 04:51:12 +0000 Received: by mail-io1-f49.google.com with SMTP id s24so17500831iob.6 for ; Mon, 08 Feb 2021 20:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dana-is.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rjh/LMxDHOca8jFH45bk5EvG5H5XPjnvSqhKEkJbCQE=; b=upx224wrr/oP5jVJwXsdv+rL70/n/s5u4RgVDYKeyGNz3HncoWkmd3gwN21glI/dh6 iaXjPvYgUHoRb/Oc5TxTTi7jAII3MLFewx9MgaAEDnni91vbJXnXiiq93XhNh1IInNRd g+CkjjpKHBuy/iF5ZOdnwPkvfynRPiO2yElVyUjb03DV+fyCsfv9JgZUJaJ0vUpTAo12 JDA4CI8S/RrhDG5DMfRrolMYsvOvK3400FHPRC9lC1/u7b6YgYja0WVl7XAtZYOUByyF fwZSMMqAV/lzdHpfIiFM6a07QuDTyqbkekyAkGNYyS6NGMY1C6GQ7EyCFg7Z5FFUDYIk nxKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rjh/LMxDHOca8jFH45bk5EvG5H5XPjnvSqhKEkJbCQE=; b=JjjgMHxpplfOcx9Y5VdJ/bYjFQqSxZ/FHeO3PyZ6lGOcjx//bc3LHgYGsMZ+GztTjm /BnSkN78B/rxlxO0DwNZm7cduUI3crhFgJfQd605GBQNtxwy8cwOaIUOw5QVxKUMc+eI x6itf9A0LIP6lqrS1/vsFlJRzM0gjcnL239Hfce7o6HF9VysQGegyPT+WkiPWV8F/Ese 5+eE3wDtzHltsFr1xgFPc+mBsr9x9RS1+C3oeXjXuYBSat+LMEBHSsl2tACe4vUn4Hya BSba4MQ69IOfTVoupI4PTPpMC4fLJbR8GAO7I6mPno+0HEOpyrBio/sZCAJt62L4dnKM 9zdg== X-Gm-Message-State: AOAM531O06GGn5WMluIHjxY0NqsfnMEz+Ln5jG4bhDskJQSG0dwBidv+ IL4kLZy5kK0FR98QuIT0eRJyBw== X-Google-Smtp-Source: ABdhPJzN11UAWnkhdr8Xlp9fgiOCXs8B968cSlNFyB+dUo1o90IxwDwHhCSUORrTlRb+dO+daN98Nw== X-Received: by 2002:a02:cbb0:: with SMTP id v16mr21318022jap.126.1612846270448; Mon, 08 Feb 2021 20:51:10 -0800 (PST) Received: from heartswap.lan.dana.is (173-17-84-59.client.mchsi.com. [173.17.84.59]) by smtp.gmail.com with ESMTPSA id u14sm556935ilv.0.2021.02.08.20.51.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 20:51:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Rewrite of zsh-newuser-install From: dana In-Reply-To: Date: Mon, 8 Feb 2021 22:51:08 -0600 Cc: Zsh hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <19996A10-103F-4054-AD57-FCED8E406687@dana.is> References: <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com> <8BA25288-0FFB-4FF4-9799-541D6A3C52DA@dana.is> To: Marlon Richert X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Seq: 47961 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: On 8 Feb 2021, at 15:57, Marlon Richert = 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=3D${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 =E2=80=94 whereas i think of my = shell history as persistent personal data. > HISTFILE=3D${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 =E2=80=94 i can't = really think of any down sides to it (?), and again it's an OMZ default. > PS1=3D' > ...' 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=3D'%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=3D( 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=3Dvi(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