From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15038 invoked by alias); 5 Nov 2013 16:29:11 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18097 Received: (qmail 13047 invoked from network); 5 Nov 2013 16:29:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f0a6d000007b1b-8c-52791a73ab96 Date: Tue, 05 Nov 2013 16:18:58 +0000 From: Peter Stephenson To: Zsh-Users List Subject: Re: Fish-like autosuggestions Message-id: <20131105161858.543037da@pwslap01u.europe.root.pri> In-reply-to: <131105075700.ZM18043@torch.brasslantern.com> References: <131030092555.ZM8077@torch.brasslantern.com> <131105075700.ZM18043@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42I5/e/4Zd1iqcoggzdNbBY7Tq5kdGD0WHXw A1MAYxSXTUpqTmZZapG+XQJXxt3ri1gLVvFVvJu+lLWB8QR3FyMnh4SAicSyO4eYIGwxiQv3 1rN1MXJxCAksZZR4cHUdK5TDJHFh+g02kCoWAVWJzfufsoDYbAKGElM3zWYEsUUE1CQuP1oO FhcGsn9vOARWzytgL9G/6Rk7iM0pYCWxdMlmFoihPxglnh6bwAqS4BfQl7j69xPUGfYSM6+c YYRoFpT4Mfke2FBmAS2JzduaWCFseYnNa94yT2AUmIWkbBaSsllIyhYwMq9iFE0tTS4oTkrP NdQrTswtLs1L10vOz93ECAnDLzsYFx+zOsQowMGoxMP74Gx5kBBrYllxZe4hRgkOZiUR3mP/ K4KEeFMSK6tSi/Lji0pzUosPMTJxcEo1MFbsvhGsdZmB1V+XbdoqLp2MihLGXIGFfMtNd5lG ruZKrvBxtD7J5R5fv6L4WGWg/nmNKXM9EwKTnbrPda1V5d8Vwia7wCasKCVsqWFI6eT+Bm8e tbvO/TkfrRLstHRm3OK84XvY6qlIRNbz+ctay7nERF89y81auSdiSVZVXPiXQJPC36eUWIoz Eg21mIuKEwHAn+LVIQIAAA== 4On Tue, 05 Nov 2013 07:57:00 -0800 Bart Schaefer wrote: > } - I'm only using recusive-edit because I couldn't do asynchronous updates > } to the zle RBUFFER using 'zle -F'(I started from the 'predict-on' code) > > Hmm; so the trick here is that if you start recursive-edit, then when > the zle -F handler executes the special parameters from the surrounding > (original) ZLE context are still defined in the handler? > > I'm pretty sure this is an unintentional side-effect of recursive-edit, > and now that you've pointed it out we need to decide whether there is > (a) any reason this shouldn't continue to work, or (b) whether it ought > to be necessary, i.e., why the handlers can't always have ZLE context. I don't remember any good reason why zle -F hooks shouldn't be treated as ZLE hooks rather than just function hooks. I know the context I had in mind when I implemented it was outside zle --- I was expecting the function to invalidate the display and do something outside ZLE in the way a job notification would --- but that simply says I wasn't thinking about ZLE context rather than giving any reason. It would seem natural to replace the callhookfunc() in raw_getbyte() with a zlecallhook(). However, that's incompatible so it probably needs augmenting with an additional option to zle -F to indicate the argument is a ZLE widget rather than a shell function (a ZLE widget is a different type of object and it would be silly to have two separate mechanisms for ZLE widget hooks). That may throw up some new problems (not sure if terminal state is sane enough to permit editing the line that deep inside the code for reading characters, for example), but they ought to be fixable --- particularly if the recursive-edit hack is basically working. pws