Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160723130059.ZM19333@torch.brasslantern.com>
Date: Sat, 23 Jul 2016 13:00:59 -0700
In-Reply-To: <20160723180430.GA22451@tarsus.local2>
Comments: In reply to Daniel Shahaf <d.s@daniel.shahaf.name>
        "[PATCH] _describe and literal \n" (Jul 23,  6:04pm)
References: <20160723180430.GA22451@tarsus.local2>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] _describe and literal \n
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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.

Ideally the newlines would get noticed and the result would be more like

[[[
% f <TAB>
bar  -- lorem
        ipsum
foo  -- hello
        world
]]]

but that seems a tall hill to climb.