From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22887 invoked by alias); 24 Jul 2016 21:30:52 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38942 Received: (qmail 25106 invoked from network); 24 Jul 2016 21:30:52 -0000 X-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.211.11.3):SA:0(-1.3/5.0):. Processed in 0.233973 secs); 24 Jul 2016 21:30:52 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at apache.org does not designate permitted sender hosts) Date: Sun, 24 Jul 2016 21:30:46 +0000 From: Daniel Shahaf To: Oliver Kiddle Cc: zsh-workers@zsh.org Subject: Re: [PATCH] _describe and literal \n Message-ID: <20160724213046.GB27932@tarsus.local2> References: <20160723180430.GA22451@tarsus.local2> <160723130059.ZM19333@torch.brasslantern.com> <20160723212345.GA2982@tarsus.local2> <5530.1469316428@hydra.kiddle.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5530.1469316428@hydra.kiddle.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Oliver Kiddle wrote on Sun, Jul 24, 2016 at 01:27:08 +0200: > Daniel Shahaf wrote: > > I haven't been able to get menu selection's highlighting to misbehave. > > > > However, consider this: > > > > Current master: > > % _f() { a=( $'foo:hello\nworld' $'bar:lorem\nipsum' $'baz:lorem\nipsum' ); _describe descr a } > > % f > > baz > > foo -- lorem\nipsum > > bar -- hello\nworld > > Is your fix to the internals of _describe or the more general code. The former: the patch is to cd_init(), which is guts of compdescribe, which in turn is only used by the _describe function. > Note that _describe truncates descriptions [...] I see truncation with . a=( foo:"$(yes | head -150 | xargs)" bar:"$(yes n | head -150 | xargs)" ) _describe descr a . but not if I remove the |xargs. The only difference between the two cases is whether the y's/n's are separated by spaces or newlines. > I'm not especially fond of the \n escapes. Would prefer they were mapped > to spaces. However, failing to group baz and foo is clearly wrong. > While the patch adds one case where a newline is escaped as \n, the incumbent code in master already uses that same escaping in another situation. > It could be worth experimenting with long strings that approach the > right edge of the terminal to see if it is affecting the calculations. I've found a problem, however, I'm not sure whether it's compdescribe's fault. Reproducer: $ zsh -f % autoload compinit % compinit % zstyle ':completion:*' completer _all_matches _match _expand _complete _ignored % zstyle -e :completion:\* list-colors 'reply=( "=(#b)(${(b)PREFIX})(?)([^ ]#)*=0=33=34=33" )' % zstyle ':completion:*' menu 'select=long-list' 'select=3' % pad=${(r:3*COLUMNS::x :):-} % _f() { a=( foo:$'fff\nfff'$pad bar:$'ggg\nggg'$pad ); _describe descr a } % compdef _f f % f This garbles the display, it shows a «ba» in reverse video and is offset one line too far down. Tabbing further keeps moving it down, eventually I get lines as though by `repeat $N print -rP -- "%Sba%sf bar foo"`. Or if you meant, to check whether the patch _break_ some width calculation, I think that's unlikely: the patch escapes the description value as soon as it's parsed out of the user-specified $foo:$bar value into the ->desc struct member, in the (as far as I can tell) only place that parsing is done. Cheers, Daniel (let me know if I should push the patch I'd posted)