Zsh Mailing List Archive
Messages sorted by:
Re: Completion in empty double-quotes generates error
- X-seq: zsh-workers 38467
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Completion in empty double-quotes generates error
- Date: Tue, 10 May 2016 13:13:55 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=u6VKduVVC6pWPGWfTRt4eNedmXDNXxPZX75TBEWDgJY=; b=d7K7X6XwVtKosZ7AY9yU/b7zeZlY0OLRcGx9NNaQAdcRHMGIxeGIIgreBSo/NrPH7w c+/SrM1qpGC44ZQfVpXTamh1UYN1+wuMhLJgTqf1rVvTpbS3Ofqv5o9bI+biSvilaZGj ssKpA2WE4mKnMyePC4SP0mLt0eFsySYyf7waX8vTp5WWtXhukN0CF9UyugHktb9JGQqG kaz1M1cYQh3xyIu8w6wZ0EPrEika4F9EZNXLN7hz1jqUidaZz0qItMuzEUoLu/NJD7Q5 LlQm2cyljuYPQIEsWkwZKYSXQ8omEuzur20dw5cAECqzM6IQnxGlMXhKU0PBLbDftJ3b OJcQ==
- In-reply-to: <20160510184031.GA27856@tarsus.local2>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <160330110652.ZM1432@torch.brasslantern.com> <20160401053633.GA17993@tarsus.local2> <160401181824.ZM23675@torch.brasslantern.com> <20160402032950.GA10638@tarsus.local2> <160401232021.ZM25900@torch.brasslantern.com> <160402111815.ZM1925@torch.brasslantern.com> <160406121053.ZM31877@torch.brasslantern.com> <20160510184031.GA27856@tarsus.local2>
On May 10, 6:40pm, Daniel Shahaf wrote:
} Subject: Re: Completion in empty double-quotes generates error
} 'tmux new <TAB>' segfaults:
} $ zsh -f
} % echo $ZSH_PATCHLEVEL
burner% echo $ZSH_PATCHLEVEL
burner% echo $ZSH_VERSION
I never get the "-dev-1" part in PATCHLEVEL.
} % autoload compinit
} % compinit
} % tmux new <TAB>5: compcore.c:1657: expecting 'x' at offset -7 of "x"
} Program received signal SIGSEGV, Segmentation fault.
Well, that's got to be because of this:
} > The change in gotword() is necessary but of a little concern. AFAICT
} > we only care about wb when examining the word under the cursor, so it
} > shouldn't hurt to skip updating it when doing so would violate the
} > wb <= zlemetacs <= we constraint, but there may be some corner case I
} > haven't tried that depends on the old behavior.
Apparently here is a case that depends on wb / we always being updated,
or at least being initialized in some way that has been missed.
I won't have a chance to look at this for at least another 3 weeks, so if
anyone else cares to try deciphering the interaction of the lexer with
compcore, it's all yours.
Messages sorted by: