Zsh Mailing List Archive
Messages sorted by:
Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines
- X-seq: zsh-users 18658
- From: m0viefreak <m0viefreak.cm@xxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines
- Date: Sun, 23 Mar 2014 04:41:29 +0100
- 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==
- In-reply-to: <140322103747.ZM9034@torch.brasslantern.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <532D99DE.email@example.com> <firstname.lastname@example.org> <140322103747.ZM9034@torch.brasslantern.com>
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
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.
Messages sorted by: