From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20602 invoked by alias); 23 Mar 2014 04:40:38 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18658 Received: (qmail 16830 invoked from network); 23 Mar 2014 04:40:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0VkKKghAQ0bnf9v87bxZImFQHDIVIw4gtfV6eV2GA4g=; b=apqNbFIbspMgrtI/kGJcrGPtgcj7qUvbCOcxaxKmWratlyY4EKey/KneqBHo8PIVyF iJAiVTuMUV6YdwcGiOA9LUifHaDkOgyPujDnVZRBGQOZjCJ0TKpHB3jb/AmkNZwNnqQL /LPB37bRPY4lVd4ing/rI9/HgDQ+OGEadwevS64Bo/Mp/SbTjJFSmXglZJlWbJ8zjHin h+j1pdbAJJ5e5A25W6zEEJwAQogQsDpcOm09THGjJVUBEdWiDlpW9/9KNWr9bYv7ggnf tlR2mcn5JodRr0nzB9+B4UX52fAnu8j1rEV6vqDTwThnBwMhnu3z3I7qfLBCi6WjfVSK q0aA== X-Received: by 10.14.37.8 with SMTP id x8mr56070119eea.32.1395546091554; Sat, 22 Mar 2014 20:41:31 -0700 (PDT) Message-ID: <532E57E9.7000807@googlemail.com> Date: Sun, 23 Mar 2014 04:41:29 +0100 From: m0viefreak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: zsh-users@zsh.org Subject: Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines References: <532D99DE.6090503@googlemail.com> <1395506625-4132-1-git-send-email-m0viefreak.cm@googlemail.com> <140322103747.ZM9034@torch.brasslantern.com> In-Reply-To: <140322103747.ZM9034@torch.brasslantern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22.03.2014 18:37, Bart Schaefer wrote: > The presence or absence of \n in the -r string doesn't seem to make any > difference for me. The suffix is auto-removed on accept-line whether > invoked as ctrl+m or ctrl+j or enter/return, with or without \n there. > > And of course the \t only matters if you type ctrl+v tab, because in > other cases complete-word is invoked and no character is inserted. Right, I basically added them for completeness, because according to the man page the default behavior (-q) includes them: Thus `-S "=" -q' is the same as `-S "=" -r "= \t\n\-"'. Giving -q AND -r is superfluous, so I removed -q. And there actually is use for \n: When entering multiple commands on multiple lines (ALT+Return) without calling accept-line. This way we get the default behavior, just as if only -q was given, PLUS the additional . @ ~ ^ characters. > Hmm. However, here's something really strange. Starting from zsh -f > with compinit loaded and tab bound to complete-word ... > > With the original code: > > compset -S '..*' || suf=( -qS .. -r '.@~ ^:' ) > > the trailing ".." is not boldfaced like an autoremovable suffix is by > default, and indeed it is not removed upon accept-line, though it is > auto-removed by e.g. a space. > > With this: > > compset -S '..*' || suf=( -qS .. -r '.@~ ^:\-' ) > > (note that the only change is to add '\-' to the -r string), the ".." IS > shown in boldface and is auto-removed by accept-line. > > I have no idea why that would make a difference. I noticed that too. The part that makes the boldface work seems to be the '\-'. Accoding to the man-page the only thing it does is `\-' stands for all characters that insert nothing. which is exactly what is needed to make it work with accept-line, but I can't see how this is related to the boldface.