Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: bracketed paste mode in xterm and urxvt
- X-seq: zsh-workers 35475
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- Subject: Re: bracketed paste mode in xterm and urxvt
- Date: Tue, 16 Jun 2015 01:09:42 +0200
- Cc: zsh workers <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hVa5H7s0ymyn3z15zieq6OTXDaS2iEymTLornRmQZTA=; b=UDa3o0JisvjPgrUE6CCozJOzlyDA2TF5NuqJNrk5tZBT3JuajJ4sw3vu6Uk3N/oV12 WVhvhQN4THN9gMxsDISh1ochH0jm5PRQQ/8Hztvhq8tqxZf+U3M+6oIpgscvI6vqeGxk IYtfPztyhYBKR4q+vVJxqt+WTfkYLR19VgsAaOnsYiTcYbEXiKJ0ycWCP3f4r5TDx3NV ucUqYQTIid6PRjFK1Phjj7+iePoM3cJIyHu/5LvntGX0vwwSz0qHt54ZlYCOQMHJsBVM i3hCkld0D3xlYr5/SL6BcOBXpkShTf9Lm+gXJ3nZKcxJpUx31WRgmapKI1UYYbcGsCyd M+sg==
- In-reply-to: <20634.1434406318@thecus.kiddle.eu>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <BANLkTikh_-+L2W5=Yfu7h7iAe5CcpP6fxw@mail.gmail.com> <CAFOazAOfk=Sq-smkMGzJKO4b7jMb_1_m4vXXn8twoVA2wV55YA@mail.gmail.com> <55677AF5.50709@thequod.de> <mk9dc0$p0$1@ger.gmane.org> <27004.1433345491@thecus.kiddle.eu> <mkrus3$kdi$1@ger.gmane.org> <3098.1433511607@thecus.kiddle.eu> <mksc2m$n3q$1@ger.gmane.org> <7701.1433896116@thecus.kiddle.eu> <150609213830.ZM29868@torch.brasslantern.com> <20634.1434406318@thecus.kiddle.eu>
On Tue, Jun 16, 2015 at 12:11 AM, Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> On 9 Jun, Bart wrote:
>> This sounds like the same dilemma that we had with ZLE_RPROMPT_INDENT,
>> which we addressed with a variable rather than an option. This would
>> address several problems: namespace (ZLE-specific stuff should really
>> stop leaking into the base shell options); a place to store the string
>> to use in case it turns out not to be the same for all terminal types;
>> and distinguishing among unset/set/empty/non-empty semantics.
>
> That makes sense, thanks.
>
> So this next attempt uses ZLE_BRACKETED_PASTE_ON/OFF though I'm open to
> better ideas.
> I've not made them special, just initialised them with a call to
> setsparam as that seemed simple enough for the purpose. Is that
> reasonable or should they be special?
>
> I also looked around for places where keys are read and handled such
> that bracketedpaste() would not be called. I've not done anything in
> the case of single bytes such as for the vi r and f commands but I have
> added handling for the history and completion incremental searches and
> for the execute-named-command widget. It would be possible to avoid this
> special handling by adding logic to getkeycmd() so that they get a
> stream of self-insert widgets. That would somehow defeat the
> purpose of bracketed paste, however.
>
> In both the incremental search modes, backspace works like undo so the
> entire paste is undone. This same effect is also apparent if you press
> backspace after changing search direction with Ctrl-S or Ctrl-R.
>
> +int
> +bracketedpaste(UNUSED(char **args))
> +{
> + int n;
> + ZLE_STRING_T wpaste;
> + char *pbuf = bracketedstring();
> +
> + wpaste = stringaszleline((zmult == 1) ? pbuf :
> + quotestring(pbuf, NULL, QT_BACKSLASH), 0, &n, NULL, NULL);
> + zmult = 1;
This feature appears to be undocumented? I also think the
documentation for the widget should list the default bindings, as
other widgets do.
It might also be nice if the widget could take a parameter as an
argument to store the text in, rather than insert it into the command
line always.
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author