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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14981 invoked from network); 7 Feb 2021 17:11:17 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 7 Feb 2021 17:11:17 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1612717877; b=ZlxDSYKrURXULwPIci/G64PmscaqeaInP16P5PIbOdpIXf5STu7ljVyxivzlHn7ZmWMUuy32rB 0P5YJmEJzmY2Bp/F4cyqkAoaA2DYDuHMGYtzVdc7nasZ9wp/QCoELglnUliXIsQXMoRmTQGl5/ eYc5MdUJ0Pj1KSSX+cb1BKqslGN9Kt8Me8Li5sClqx6sCyn/xiCxU8cUuqYxinvFZHwjY3iCDp FMn53jAgZfhrk2J2X9sEsqlBTYdW+PnMWqt//B5o6IqytlopaTjMmfb4PwQYJywsMkw0f9i+vG adbRQNlo7xq0GfTHB8HyaGxMlshu0fEVgXbQIGXDmK5GWw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lf1-f41.google.com) smtp.remote-ip=209.85.167.41; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1612717877; bh=Gr4icfQbVf8RzOmoBumiAQGpN0gfiv7LsOCQENC2yRU=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:Cc:To:Subject: Message-ID:Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature: DKIM-Signature; b=wipVunDAfKE+aHBHswdQHazJE1tds5or17j1GoZFEaewwCOgBPW9mULoR2nKzo0Bg5vFgeOzhw neh2Ej/zf0zReWgNSLBJ0VbZanQjaPlLszQ0DXRbSf1suIt/jqmWCDaaKtIU+Rk7SLFsHKkM+Z pqIE/Wk0wRGdOakF7t/lEiopMXMmHALvBRucwocb8xP6vx7UvU9KA/e/An7mNuZviRwUlZ+TF0 UhL/F56kz0/Wp6vWtQLZJUTc7NGoK6pSBWUtTi3+nc5m6TMZFACwPTKvNaDvpARQ6R0faKlJx0 IMynTLoYb77tVwJOK/fXTmV3fib/t3FethHYHQjH0dPY6Q==; 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:Content-Transfer-Encoding: Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=Gr4icfQbVf8RzOmoBumiAQGpN0gfiv7LsOCQENC2yRU=; b=x+GnMBoSS4Zri+31BPJ0JXoWPQ Y3bVApCXi+E+VAUwRIX6s6qNoDyeKwVQj9IGcVWDlFeKp1y5qlNHtoEijpfivBAeA0vx7PJkXKsLp oxjyOKwwIieR0HV3YWS33PaAm9qPUIrNs93854VCzgDDtwIENIbWcJGGfBLr+nmm9bFEkv8mT1aFj /LKrmXah/s7wJuAMeaxOVOZXPe1WuDgOJlLBWj8KNY6/1exfChcsU2N1YkEWqImLEe+wI7N7ocMLj 0TzPBy9tDUjoMfVkQYgUPR6WjHNm46oBthqHMcGPlsLqHRlHwcu6Q4AEZs3bhi0kxYGWD93V+UZdB gMDjKxhQ==; Received: from authenticated user by zero.zsh.org with local id 1l8nad-0007AV-Cg; Sun, 07 Feb 2021 17:11:15 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lf1-f41.google.com) smtp.remote-ip=209.85.167.41; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-lf1-f41.google.com ([209.85.167.41]:45459) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1l8naO-00071Q-FU; Sun, 07 Feb 2021 17:11:01 +0000 Received: by mail-lf1-f41.google.com with SMTP id q12so18571716lfo.12 for ; Sun, 07 Feb 2021 09:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Gr4icfQbVf8RzOmoBumiAQGpN0gfiv7LsOCQENC2yRU=; b=MG6skJHnMJIEBJ6ItGWpHHNRYCHJfC9RPXxeRcYVnuHfHIUN9wLhuoYL74u9f0xLUa RDBMbiukNxGKqhKbVFacH/G6CkHFiDJiF2p61dE2z970deo8VuJwy22QkmqFMzFkf24j 5+DAFNWJi+QXt88R7GyOoqeKtJ4Kg367axpzl1VfghJLg8Vgwlx8ymq5vQ37rgnhKoLC rap8OUwQHYyZ6qF71ZJqAXXeYuNE9ucKtlqjJe92blzbKBdGAC6FohfQeGAnnkqYerGB 5eN6j/OYFJCim6Jab5iuUje+LC1GiffxsZ8GBham7C2y77R86giDTJNffJcDlVZhaTx0 gwRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Gr4icfQbVf8RzOmoBumiAQGpN0gfiv7LsOCQENC2yRU=; b=c0LQ5wst2E/dYJYKMVTIoizPyukg+ASlqFqgRX3+mhjmWLWvyZMXGvxwLjxeTGACvJ OHqwdHUPE8ewm9ph/+XHLrfWkZiHc8D0C49RW+Ta9ft3oxP6WTKn/zmQmafmIdlWAL2l Q3zbRG0TsO7pfkF8UI9/vYPnB/zC61Nlmkot66KjgzU8wl21XOyGHydMqzQpp4BBVDBa Tt5DzlTosPdp4PhisP8A6wjXhb8RLy1K1SKtkp2V4rM5v6rmusGFIoQUmtj1zPV+/dHp W2vCijhAN+ixuvkE3lQ/1ApY3eU9tPzeiVqpdjZuVgVog6zbUe39XSV6HsoYMYMipTT0 sNEw== X-Gm-Message-State: AOAM531R9qfv2lH5LW7zhgFgABb2ukT7AZwhpr8Fo2iNqvYFUtFdyj7H gr+1gN53L9rE5JFoOSMjxGJJFHTIHK//jFkwc4XusEbqHxXV2A== X-Google-Smtp-Source: ABdhPJwCVrCv9Nw/YpzpgHXrG7Fx7xFEpc8iQigxw+EHwdN3yHNE8G+rRrYPS9m7/ydRKuF95tpTYkHkKkLeJbJpQPc= X-Received: by 2002:a05:6512:131b:: with SMTP id x27mr8032671lfu.593.1612717859462; Sun, 07 Feb 2021 09:10:59 -0800 (PST) MIME-Version: 1.0 References: <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com> In-Reply-To: From: Marlon Richert Date: Sun, 7 Feb 2021 19:10:23 +0200 Message-ID: Subject: Re: Rewrite of zsh-newuser-install To: Roman Perepelitsa Cc: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= , Bart Schaefer , Patrick Reader <_@pxeger.com>, Zsh hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 47936 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 Sun, Feb 7, 2021 at 3:51 PM Roman Perepelitsa 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 e= nable users to get started (basic keys must work, prompt must show current = directory, completions must work -- this sort of stuff) *and* it must enabl= e 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 wi= ll have worse setup long term because of this. > To be more specific: > - no vcs_info. in some environments it makes prompt noticeably slow; it a= lso 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, b= e it zstyle or parameters; it's a config, not a meta config; users should b= e encouraged to edit it rather than create another config with parameters f= or 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 a= nd exported variables. Comments should also suggest where more information = can be found ("for more information about prompting, see xxx"). Links to we= b 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 con= fig based on your preferences. Let them compete. zsh should be *usable* upo= n 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 barr= ier 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 do= n't define auxiliary assoc arrays). This will show users how to define bind= ings. Also get rid of zle-line-begin/end hooks and stop changing terminal m= ode. 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 espe= cially 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., c= omments above bindings should say which key is being bound and what the wid= get does. It should also explain how to figure out escape codes for differe= nt keys and where to find the list of builtin widgets. > - Maybe fewer completion styles. Seems like too much but maybe they are r= eally 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 sp= ecifically limit the use of styles. The style system is an important aspect= of configuring zsh. There are very useful settings that can only be change= d that way, and it's important for users to know about it if they want to m= ake 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 powerleve= l10k. 90%+ of users won't ever open the default config file. 90% of those t= hat 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 ?