Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from <danielsh@apache.org>, 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.188452 secs); 23 Jul 2016 21:23:51 -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: Sat, 23 Jul 2016 21:23:45 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] _describe and literal \n
Message-ID: <20160723212345.GA2982@tarsus.local2>
References: <20160723180430.GA22451@tarsus.local2>
 <160723130059.ZM19333@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <160723130059.ZM19333@torch.brasslantern.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Seq: zsh-workers 38928

Bart Schaefer wrote on Sat, Jul 23, 2016 at 13:00:59 -0700:
> On Jul 23,  6:04pm, Daniel Shahaf wrote:
> }
> } Gives:
> } [[[
> } % f <TAB>
> } bar  -- lorem\nipsum
> } foo  -- hello\nworld
> } ]]]
> } 
> } Is this fix correct?
> 
> Boy, that's a tough one.  If the embedded newlines mess up something else,
> like for example menuselect keeping track of lines/columns/cursor, then
> I'd say this is the closest thing to a correct quick-fix.
> 
> On the other hand if the extra newlines are handled correctly, then I'd
> say this fix isn't warranted, and it's up to the caller to decide what
> is meant when a newline appears in the descriptions.

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 <TAB>
    baz  
    foo  -- lorem\nipsum
    bar  -- hello\nworld

With the patch:
    % f <TAB>
    baz  bar  -- lorem\nipsum
    foo       -- hello\nworld

Never mind the fact that current, unpatched, master escaped the newline
this time; the more important difference is that current master arranges
the display as though the description of foo is "lorem ipsum" and of bar
is "hello world", which is incorrect.

Cheers,

Daniel