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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1200 invoked from network); 13 Feb 2021 01:36:54 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Feb 2021 01:36:54 -0000 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:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=7++nvKCzP/s+itSSr4Od6gKycJJ/RzJCQF2Lfwegtjo=; b=eCYIz3EnSX6Sp6hthGnNgQ5/d9 hy5G1UxeAd6SJujcq5uszaeqzhU5msAcm75IAUtOi75G+OTk1fB6Yp5ue+46LpsCYaB74SNqF13xA 7pyER687/lZehEQSuc27vuWNbfiQJFxckLlYqypNcGjS9ZJzdIPlfHynRv6GltNkDSrro1gYD0Yzu 2/gARGQLI1bio4v6j89b9BlvGa+MxX2kHGLFwa/SnBDrEF7ris5JFTKVgzlExYgR0gbHvT2GcYqQk k2bLqXB3VxHohmEjOapnn8t709ZuAqLC1Lz5eKDHGp5eDTZIiwoWrjsiLPyWKY4I261rOSRRXE+Rb 5eaPw8fg==; Received: from authenticated user by zero.zsh.org with local id 1lAjrh-000B3a-Pm; Sat, 13 Feb 2021 01:36:53 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1lAjrX-000Av4-Ez; Sat, 13 Feb 2021 01:36:43 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1lAjrV-000HXM-Bv; Sat, 13 Feb 2021 02:36:42 +0100 cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com> <8BA25288-0FFB-4FF4-9799-541D6A3C52DA@dana.is> <19996A10-103F-4054-AD57-FCED8E406687@dana.is> <86782FA5-6EBB-4FCD-90AD-D33F352455F1@dana.is> <63124-1613172369.335393@kj4H.lfui.ly3G> To: Marlon Richert Subject: Re: Rewrite of zsh-newuser-install MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67414.1613180201.1@hydra> Date: Sat, 13 Feb 2021 02:36:41 +0100 Message-ID: <67415-1613180201.366561@nSDd.R0ox.wLYA> X-Seq: 48034 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: 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 _ 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 - 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