From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10965 invoked by alias); 10 Jun 2015 04:38:40 -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: 35429 Received: (qmail 3036 invoked from network); 10 Jun 2015 04:38:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=YFzu3noIfiE/N641gr9vC9J5E2/RIWlcSWmmXi6xkkw=; b=LrkIe5MvBdHpisaaIOe7We1eK4Om+ZMhJM4yAmmC08JEECF+/R24AbCajNdJSIOxVh werMva6sTv666PYIk9hqKEcHMUk5q2tlS2mdaEHHziX0gZ7ZKkmMUCwo5LYdORNGWUqH 94/qIncXGwXnj83LuBqx/ke4SqQiLUN5xpylQ158Y9lXlzmnFzyYrNmMiOM+PhvaGX3B rkqrU2JmMSa9soHx9qgO4mKSdvSw6QFaNb0tf5EWenOFPvf0sh9WswI11v9ASx312K9N V5CHXZ3u7cAgxvjCi7kiJNxOjPeFdSAklYullawDMO96W135heWZDqZoeSTlZ5WkNBip 8+cw== X-Gm-Message-State: ALoCoQkrncRrmwnXF+6fVTCVEr+b+DzIKLTbMvRwjc9b2/b9lUCrzpGvCCWdomnGJduhpCnhIqXG X-Received: by 10.202.57.137 with SMTP id g131mr891283oia.122.1433911114575; Tue, 09 Jun 2015 21:38:34 -0700 (PDT) From: Bart Schaefer Message-Id: <150609213830.ZM29868@torch.brasslantern.com> Date: Tue, 9 Jun 2015 21:38:29 -0700 In-Reply-To: <7701.1433896116@thecus.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: bracketed paste mode in xterm and urxvt" (Jun 10, 2:28am) References: <55677AF5.50709@thequod.de> <27004.1433345491@thecus.kiddle.eu> <3098.1433511607@thecus.kiddle.eu> <7701.1433896116@thecus.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: bracketed paste mode in xterm and urxvt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 10, 2:28am, Oliver Kiddle wrote: } } This links it to a new BRACKETED_PASTE option. A concern with that } approach is that if logic is needed in init_term() to disable the } feature, the distinction between the user explicitly disabling the } feature and init_term() doing it wouldn't be clear. 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. So I'd vote for scrapping the setopt and adding a ZLE_BRACKETED_PASTE variable instead.