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-Qmail-Scanner-Diagnostics: from hermes.apache.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.211.11.3):SA:0(-1.3/5.0):. Processed in 0.15978 secs); 24 Jul 2016 21:30:52 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at apache.org does not designate permitted sender hosts) Date: Sun, 24 Jul 2016 21:30:46 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] add-zle-hook-widget zle-line-pre-redraw issue Message-ID: <20160724213046.GA27932@tarsus.local2> References: <20160723212335.GA20872@tarsus.local2> <160723181445.ZM20105@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <160723181445.ZM20105@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Seq: zsh-workers 38940 Bart Schaefer wrote on Sat, Jul 23, 2016 at 18:14:45 -0700: > On Jul 23, 9:23pm, Daniel Shahaf wrote: > } > } The reason appears to be that, while in azhw:zle-line-init $WIDGET is > } "zle-line-init", in azhw:zle-line-pre-redraw $WIDGET is the name of the > } widget the user invoked (e.g., "self-insert"), so the 'zstyle -a' does > } not find the registered hooks. > > If zsh-syntax-highlighting doesn't depend on that behavior, it's probably > unlikely that anything else does. z-sy-h assumes that zle-line-finish sets $WIDGET, but doesn't assume anything else about $WIDGET. > } Each of the following alternative patches solves the issue: > > The "second option" obviously isn't finished / leaves a lot of dead > code behind. Indeed it isn't: the unidiff I'd sent was not the unidiff I would commit if that option is chosen. Its purpose was not to be committed as is, only to unambiguously explain what the second alternative was. Sorry if that wasn't clear. > However, I think the first option is the correct one, > unless there's a good reason to leave $WIDGET alone; the context > that's being saved/restored by redrawhook() is important, because > we're in the middle of an arbitrary other widget > > This is actually related to what I was saying about it not being > appropriate to stick a list of callbacks on any widget. > > We can easily special-case add-zle-hook-widget to find the name another > way for this particular hook. $funcstack[1] for example. Okay, so let's wait for Mikael to weigh in, then we can choose between making pre-redraw set $WIDGET or making a-z-h-w handle pre-redraw's not doing so. > Incidentally, I tried making ALL the possible hooks be > > zle -M "$WIDGET $funcstack[1]" > > and learned two things. (1) pre-redraw is in fact the only hook that > doesn't change $WIDGET, and (2) having all the hooks call "zle -M" > garbles the output quite thoroughly, especially in vi mode. Thanks for checking (1). I can reproduce (2), the prompt character doesn't render and doesn't move down the screen. Cheers, Daniel