From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19431 invoked by alias); 1 Sep 2015 23:32:24 -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: 36389 Received: (qmail 14932 invoked from network); 1 Sep 2015 23:32:23 -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=-1.9 required=5.0 tests=BAYES_00 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=a+0epEKsL/a+WOEjlFh6P8sfZgvk2mQWhc+ybuqtHXw=; b=ZiMGNHhq/GSyRvVDqX94c0ZbOfGkSIxU8L457Xb1ufmOHiuHCWPEuiYoOtNFw5tRR9 xZNcT2IBAR4bQkEzLx6SWYHIR2sdPuflIvuhyEKu+MgzNodcjpS1Ez1qlYTFgH09dCea xQMONMMQ2uNK/kHIHxe3gHfDGVxRssmy5aQQBGbWDn4twDk7+wyBAZQDAAuNz8gOGlmA PU177OvicNkMA3Pbj/C4kusYwxFaK271i/LefkNaFwxSMp5PSJalUGzyapEgGEjLMKIn dIIYplD3qiu/2aZUyl/lMzHhkMAidJWEUaiGzvHZGBT/ivzEu3m9BrfgqZcjkUjZNGyB soJg== X-Gm-Message-State: ALoCoQnE1yESMEuvapK9O3gS/9rqies8YKhmMkKQyLR7vUfgWlsAvf33OakJE7zEkKEL9/iqYC8j X-Received: by 10.60.74.103 with SMTP id s7mr18239962oev.86.1441150340403; Tue, 01 Sep 2015 16:32:20 -0700 (PDT) From: Bart Schaefer Message-Id: <150901163218.ZM2455@torch.brasslantern.com> Date: Tue, 1 Sep 2015 16:32:18 -0700 In-Reply-To: <23177.1441101027@thecus.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: PATCH v2 (complete): Implement zle -P" (Sep 1, 11:50am) References: <1441087664-9081-1-git-send-email-mikachu@gmail.com> <23177.1441101027@thecus.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH v2 (complete): Implement zle -P MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 1, 11:50am, Oliver Kiddle wrote: } } As Bart mentions in 28560, the auto-suffix-retain precedent would } suggest that we should perhaps consider another yank-pop-enable widget } (or perhaps hold-yank-state given that this now affects highlighting and } not just yank-pop). An advantage of that approach over the flags is that } the full implementation of the widget is contained within the function } definition file. Another possibility is that "zle -f" or whatever letter we assign is one of those special variants like "zle -R" / "zle -I" which only have an effect when run from inside another widget. This hypothetical zle-switch could set the flags that are to be in effect at the time the widget completes. This would make "zle auto-suffix-retain" equivalent to (for example) "zle -f auto-suffix-retain" and then we just add other strings for the other flags, rather than adding more special widgets (which clutter the namespace and can be uselessly overridden with "zle -N"). } With the flags, we might end up needing something like } #compdef so you can put #zledef -f yank as the first line of the } function definition. Agreed that this is less good than being able to control the effect from inside the widget implementation. } Another possibility would be to try to make something like } hold-yank-state automatic - assuming that hypothetical widget was } called after every yank/yank-pop/vi-put-* in a user-defined widget. I'm not sure I understand this one. Do you mean that any time one of the yank-related widgets is called, its flags would "stick" to the calling widget (at least until there was another later yank call)? Still, it'd be nice if one could do e.g. LBUFFER+=$SOMENEWTEXT zle -f yank to indicate that the insertion into LBUFFER should be treated like a yank even though it wasn't actually using the kill ring. Maybe there is no valid reason for that. } Either way, how can we be sure that yankb/yanke are even vaguely } sensible after the user-defined widget has finished? Yes, that is an issue. Probably I'd say than any future changes to the content of BUFFER invalidate the whole yank state. But that may be an awful lot of new record-keeping.