* emulate bash key bindings @ 2020-01-07 18:38 ` Andrey Butirsky 2020-01-08 2:26 ` Sebastian Gniazdowski 2020-01-08 10:00 ` Peter Stephenson 0 siblings, 2 replies; 35+ messages in thread From: Andrey Butirsky @ 2020-01-07 18:38 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 399 bytes --] Hello, after 25 years of bash, I'm doing my first steps with Zsh. I'm trying to reproduce main bash key bindings in Zsh, so I started with: autoload -U select-word-style select-word-style bash But sill, I need to have different word boundaries for some bindings, e.g Ctrl+W should kill space-delimeted word. What is the best way to achieve that? Can I avoid creating custom widgets? Thanks. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-07 18:38 ` emulate bash key bindings Andrey Butirsky @ 2020-01-08 2:26 ` Sebastian Gniazdowski 2020-01-08 2:37 ` Andrey Butirsky 2020-01-08 10:00 ` Peter Stephenson 1 sibling, 1 reply; 35+ messages in thread From: Sebastian Gniazdowski @ 2020-01-08 2:26 UTC (permalink / raw) To: Andrey Butirsky; +Cc: Zsh Users On Tue, 7 Jan 2020 at 19:40, Andrey Butirsky <butirsky@gmail.com> wrote: > > Hello, > > after 25 years of bash, I'm doing my first steps with Zsh. > > I'm trying to reproduce main bash key bindings in Zsh, so I started with: > > autoload -U select-word-style > select-word-style bash > > But sill, I need to have different word boundaries for some bindings, > e.g Ctrl+W should kill space-delimeted word. > > What is the best way to achieve that? Can I avoid creating custom widgets? The widget is backward-kill-word. I'd also suggest utilizing the ability of bindkey to process multiple arguments at once – it'll spare some space: bindkey "^A" beginning-of-line "^E" end-of-line bindkey "^?" backward-delete-char "^H" backward-delete-char bindkey "^W" backward-kill-word "\e[1~" beginning-of-line bindkey "\e[7~" beginning-of-line "\e[H" beginning-of-line bindkey "\e[4~" end-of-line "\e[8~" end-of-line bindkey "\e[F" end-of-line "\e[3~" delete-char bindkey "^J" self-insert "^M" accept-line bindkey "^R" history-incremental-search-backward -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 2:26 ` Sebastian Gniazdowski @ 2020-01-08 2:37 ` Andrey Butirsky 2020-01-08 4:26 ` dana 2020-01-08 9:06 ` Mikael Magnusson 0 siblings, 2 replies; 35+ messages in thread From: Andrey Butirsky @ 2020-01-08 2:37 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh Users On 08.01.2020 05:26, Sebastian Gniazdowski wrote: > On Tue, 7 Jan 2020 at 19:40, Andrey Butirsky <butirsky@gmail.com> wrote: >> Hello, >> >> after 25 years of bash, I'm doing my first steps with Zsh. >> >> I'm trying to reproduce main bash key bindings in Zsh, so I started with: >> >> autoload -U select-word-style >> select-word-style bash >> >> But sill, I need to have different word boundaries for some bindings, >> e.g Ctrl+W should kill space-delimeted word. >> >> What is the best way to achieve that? Can I avoid creating custom widgets? > The widget is backward-kill-word. I'd also suggest utilizing the > ability of bindkey to process multiple arguments at once – it'll spare > some space: > > bindkey "^A" beginning-of-line "^E" end-of-line > bindkey "^?" backward-delete-char "^H" backward-delete-char > bindkey "^W" backward-kill-word "\e[1~" beginning-of-line > bindkey "\e[7~" beginning-of-line "\e[H" beginning-of-line > bindkey "\e[4~" end-of-line "\e[8~" end-of-line > bindkey "\e[F" end-of-line "\e[3~" delete-char > bindkey "^J" self-insert "^M" accept-line > bindkey "^R" history-incremental-search-backward > Thanks, but 'backward-kill-word' widget changes it's behavior after issuing "select-word-style bash" command - it starts kill bash-like words (alphabet and numeric symbols). So I need bindings for both type of words, bash-like and space-delimited. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 2:37 ` Andrey Butirsky @ 2020-01-08 4:26 ` dana 2020-01-08 9:06 ` Mikael Magnusson 1 sibling, 0 replies; 35+ messages in thread From: dana @ 2020-01-08 4:26 UTC (permalink / raw) To: Andrey Butirsky; +Cc: Sebastian Gniazdowski, Zsh Users On 7 Jan 2020, at 20:37, Andrey Butirsky <butirsky@gmail.com> wrote: > Thanks, but 'backward-kill-word' widget changes it's behavior after issuing > "select-word-style bash" command - it starts kill bash-like words (alphabet > and numeric symbols). So I need bindings for both type of words, bash-like > and space-delimited. I've never used select-word-style, i just have a handful of wrapper widgets like this: dana-zle-backward-kill-word() { # or -backward-word or whatever local WORDCHARS=... zle .backward-kill-word } zle -N dana-zle-backward-kill-word You can set WORDCHARS to whatever you want to control the precise behaviour, and then bind those accordingly. Not sure if that'd work for you dana ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 2:37 ` Andrey Butirsky 2020-01-08 4:26 ` dana @ 2020-01-08 9:06 ` Mikael Magnusson 1 sibling, 0 replies; 35+ messages in thread From: Mikael Magnusson @ 2020-01-08 9:06 UTC (permalink / raw) To: Andrey Butirsky; +Cc: Zsh Users On 1/8/20, Andrey Butirsky <butirsky@gmail.com> wrote: > On 08.01.2020 05:26, Sebastian Gniazdowski wrote: >> On Tue, 7 Jan 2020 at 19:40, Andrey Butirsky <butirsky@gmail.com> wrote: >>> Hello, >>> >>> after 25 years of bash, I'm doing my first steps with Zsh. >>> >>> I'm trying to reproduce main bash key bindings in Zsh, so I started >>> with: >>> >>> autoload -U select-word-style >>> select-word-style bash >>> >>> But sill, I need to have different word boundaries for some bindings, >>> e.g Ctrl+W should kill space-delimeted word. >>> >>> What is the best way to achieve that? Can I avoid creating custom >>> widgets? >> The widget is backward-kill-word. I'd also suggest utilizing the >> ability of bindkey to process multiple arguments at once – it'll spare >> some space: >> >> bindkey "^A" beginning-of-line "^E" end-of-line >> bindkey "^?" backward-delete-char "^H" backward-delete-char >> bindkey "^W" backward-kill-word "\e[1~" beginning-of-line >> bindkey "\e[7~" beginning-of-line "\e[H" beginning-of-line >> bindkey "\e[4~" end-of-line "\e[8~" end-of-line >> bindkey "\e[F" end-of-line "\e[3~" delete-char >> bindkey "^J" self-insert "^M" accept-line >> bindkey "^R" history-incremental-search-backward >> > Thanks, but 'backward-kill-word' widget changes it's behavior after > issuing "select-word-style bash" command - it starts kill bash-like > words (alphabet and numeric symbols). So I need bindings for both type > of words, bash-like and space-delimited. You can bind those you want to be space-delimited to widgets with a . in front, it will override the custom widget function select-word-style sets up. bindkey "\e[4~" end-of-line "\e[8~" .end-of-line -- Mikael Magnusson ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-07 18:38 ` emulate bash key bindings Andrey Butirsky 2020-01-08 2:26 ` Sebastian Gniazdowski @ 2020-01-08 10:00 ` Peter Stephenson 2020-01-08 21:55 ` Andrey Butirsky 2020-01-09 14:18 ` emulate bash key bindings Andrey Butirsky 1 sibling, 2 replies; 35+ messages in thread From: Peter Stephenson @ 2020-01-08 10:00 UTC (permalink / raw) To: zsh-users On Tue, 2020-01-07 at 21:38 +0300, Andrey Butirsky wrote: > Hello, > > after 25 years of bash, I'm doing my first steps with Zsh. > > I'm trying to reproduce main bash key bindings in Zsh, so I started with: > > autoload -U select-word-style > select-word-style bash > > But sill, I need to have different word boundaries for some bindings, > e.g Ctrl+W should kill space-delimeted word. > > What is the best way to achieve that? Can I avoid creating custom widgets? The most configurable way is to use the special widget, the same one that you've now got bind to the usual backward-kill-word functions, but under a different name. Then you can set a special style for the behaviour. Then you have all the same possibilities as the widget functions at your fingertips, without having to redefine any functions. # Create widget backward-kill-space-word, using the generic # backward-kill-word widget function. zle -N backward-kill-space-word backward-kill-word-match # Tell it to use "space" style for words. zstyle ':zle:backward-kill-space-word:*' word-style space # Bind it. bindkey '^W' backward-kill-space-word The zshcontrib manual lists the various styles. pws ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 10:00 ` Peter Stephenson @ 2020-01-08 21:55 ` Andrey Butirsky 2020-01-08 22:03 ` Roman Perepelitsa 2020-01-09 14:18 ` emulate bash key bindings Andrey Butirsky 1 sibling, 1 reply; 35+ messages in thread From: Andrey Butirsky @ 2020-01-08 21:55 UTC (permalink / raw) To: zsh-users On 08.01.2020 13:00, Peter Stephenson wrote: > On Tue, 2020-01-07 at 21:38 +0300, Andrey Butirsky wrote: >> Hello, >> >> after 25 years of bash, I'm doing my first steps with Zsh. >> >> I'm trying to reproduce main bash key bindings in Zsh, so I started with: >> >> autoload -U select-word-style >> select-word-style bash >> >> But sill, I need to have different word boundaries for some bindings, >> e.g Ctrl+W should kill space-delimeted word. >> >> What is the best way to achieve that? Can I avoid creating custom widgets? > The most configurable way is to use the special widget, the same one > that you've now got bind to the usual backward-kill-word functions, but > under a different name. Then you can set a special style for the > behaviour. Then you have all the same possibilities as the widget > functions at your fingertips, without having to redefine any functions. > > > # Create widget backward-kill-space-word, using the generic > # backward-kill-word widget function. > zle -N backward-kill-space-word backward-kill-word-match > # Tell it to use "space" style for words. > zstyle ':zle:backward-kill-space-word:*' word-style space > # Bind it. > bindkey '^W' backward-kill-space-word > > > The zshcontrib manual lists the various styles. > > pws > Thanks to all for answering! Actually, the solution with styles is what I came to myself, just used aliases instead of creating new widgets (zle -A forward-word space-forward-word). But binding with dot-prefixed widget names seem the most compact solution for me: "bindkey '^w' .backward-kill-word", thanks! Still, both solutions do not seem very obvious, at least for new user. So maybe we should emphasize it in the documentation? I think a few extra examples in section introducing 'select-word-style' command would be enough. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 21:55 ` Andrey Butirsky @ 2020-01-08 22:03 ` Roman Perepelitsa 2020-01-08 22:23 ` Daniel Shahaf 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-08 22:03 UTC (permalink / raw) To: Andrey Butirsky; +Cc: Zsh Users On Wed, Jan 8, 2020 at 10:57 PM Andrey Butirsky <butirsky@gmail.com> wrote: > But binding with dot-prefixed widget names seem the most compact > solution for me: "bindkey '^w' .backward-kill-word", thanks! Keep in mind that binding dot-prefixed widget names breaks plugins that wrap widgets. Includes the most useful plugins out there such as zsh-syntax-highlighting and zsh-autosuggestions. It also breaks many themes including powerlevel10k. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 22:03 ` Roman Perepelitsa @ 2020-01-08 22:23 ` Daniel Shahaf 2020-01-09 0:05 ` Andrey Butirsky 2020-01-09 11:03 ` Roman Perepelitsa 0 siblings, 2 replies; 35+ messages in thread From: Daniel Shahaf @ 2020-01-08 22:23 UTC (permalink / raw) To: Zsh Users; +Cc: Andrey Butirsky Roman Perepelitsa wrote on Wed, 08 Jan 2020 22:03 +00:00: > On Wed, Jan 8, 2020 at 10:57 PM Andrey Butirsky <butirsky@gmail.com> wrote: > > But binding with dot-prefixed widget names seem the most compact > > solution for me: "bindkey '^w' .backward-kill-word", thanks! > > Keep in mind that binding dot-prefixed widget names breaks plugins > that wrap widgets. Includes the most useful plugins out there such as > zsh-syntax-highlighting and zsh-autosuggestions. It also breaks many > themes including powerlevel10k. That's true for z-sy-h's master branch, but with the feature/redrawhook branch (due to be merged after 0.7.0's release) highlighting will be refreshed even by invocations of dot-prefixed widgets. Cheers, Daniel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 22:23 ` Daniel Shahaf @ 2020-01-09 0:05 ` Andrey Butirsky 2020-01-09 8:45 ` Roman Perepelitsa 2020-01-09 11:03 ` Roman Perepelitsa 1 sibling, 1 reply; 35+ messages in thread From: Andrey Butirsky @ 2020-01-09 0:05 UTC (permalink / raw) To: Zsh Users On 09.01.2020 01:23, Daniel Shahaf wrote: > Roman Perepelitsa wrote on Wed, 08 Jan 2020 22:03 +00:00: >> On Wed, Jan 8, 2020 at 10:57 PM Andrey Butirsky <butirsky@gmail.com> wrote: >>> But binding with dot-prefixed widget names seem the most compact >>> solution for me: "bindkey '^w' .backward-kill-word", thanks! >> Keep in mind that binding dot-prefixed widget names breaks plugins >> that wrap widgets. Includes the most useful plugins out there such as >> zsh-syntax-highlighting and zsh-autosuggestions. It also breaks many >> themes including powerlevel10k. > That's true for z-sy-h's master branch, but with the feature/redrawhook > branch (due to be merged after 0.7.0's release) highlighting will be > refreshed even by invocations of dot-prefixed widgets. > > Cheers, > > Daniel Sorry I'm not using any plugins yet so can't try, could you explain how binding dot-prefixed widget in my case can break something? Is it mentioned in the documentation? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 0:05 ` Andrey Butirsky @ 2020-01-09 8:45 ` Roman Perepelitsa 2020-01-09 9:27 ` Andrey 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-09 8:45 UTC (permalink / raw) To: Andrey Butirsky; +Cc: Zsh Users On Thu, Jan 9, 2020 at 1:07 AM Andrey Butirsky <butirsky@gmail.com> wrote: > Sorry I'm not using any plugins yet so can't try, could you explain how > binding dot-prefixed widget in my case can break something? As long as nothing in your config files attempts to intercept zle widgets, binding dot-prefixed widget will work fine. > Is it mentioned in the documentation? There is this: > Each built-in widget has two names: its normal canonical name, and > the same name preceded by a ‘.’. The ‘.’ name is special: it can’t > be rebound to a different widget. If you bind '^W' to '.backward-kill-word', Ctrl+W will always invoke the built-in backward-kill-word widget. Plugins that attempt to install their hooks by redefining backward-kill-word will fail to do so in this case. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 8:45 ` Roman Perepelitsa @ 2020-01-09 9:27 ` Andrey 2020-01-09 10:44 ` Roman Perepelitsa 0 siblings, 1 reply; 35+ messages in thread From: Andrey @ 2020-01-09 9:27 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Zsh Users On January 9, 2020 11:45:21 AM GMT+03:00, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: >If you bind '^W' to '.backward-kill-word', Ctrl+W will always invoke >the built-in backward-kill-word widget. Plugins that attempt to >install their hooks by redefining backward-kill-word will fail to do >so in this case. OK thanks. Just wonder if any plugins need to intercept backward-kill-word or cursor movement widgets.. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 9:27 ` Andrey @ 2020-01-09 10:44 ` Roman Perepelitsa 0 siblings, 0 replies; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-09 10:44 UTC (permalink / raw) To: Andrey; +Cc: Zsh Users On Thu, Jan 9, 2020 at 10:27 AM Andrey <butirsky@gmail.com> wrote: > OK thanks. Just wonder if any plugins need to intercept backward-kill-word or cursor movement widgets. Two the most useful (in my opinion) plugins do this. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 22:23 ` Daniel Shahaf 2020-01-09 0:05 ` Andrey Butirsky @ 2020-01-09 11:03 ` Roman Perepelitsa 2020-01-10 17:06 ` Daniel Shahaf 1 sibling, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-09 11:03 UTC (permalink / raw) To: Zsh Users; +Cc: ericdfreese, Daniel Shahaf On Wed, Jan 8, 2020 at 11:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > That's true for z-sy-h's master branch, but with the feature/redrawhook > branch (due to be merged after 0.7.0's release) highlighting will be > refreshed even by invocations of dot-prefixed widgets. [cc:ericdfreese@gmail.com] That's useful to know. Thanks for the heads up. I took a look at the code and see that feature/redrawhook branch applies highlighting in zle-line-pre-redraw. Won't this cause issues when zsh-syntax-highlighting is used together with zsh-autosuggestions? zsh-autosuggestions doesn't wrap zle-line-pre-redraw by default, so it won't apply its own highlighting on top of zsh-syntax-highlighting. If zsh-autosuggestions starts wrapping zle-line-pre-redraw by default, there are still potential issues for users who upgrade their local zsh-syntax-highlighting before zsh-autosuggestions. There are also users who manually set ZSH_AUTOSUGGEST_IGNORE_WIDGETS. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 11:03 ` Roman Perepelitsa @ 2020-01-10 17:06 ` Daniel Shahaf 2020-01-10 17:35 ` Roman Perepelitsa 0 siblings, 1 reply; 35+ messages in thread From: Daniel Shahaf @ 2020-01-10 17:06 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Zsh Users, ericdfreese [sorry for the late answer] Roman Perepelitsa wrote on Thu, Jan 09, 2020 at 12:03:16 +0100: > On Wed, Jan 8, 2020 at 11:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > That's true for z-sy-h's master branch, but with the feature/redrawhook > > branch (due to be merged after 0.7.0's release) highlighting will be > > refreshed even by invocations of dot-prefixed widgets. > > [cc:ericdfreese@gmail.com] > > That's useful to know. Thanks for the heads up. > > I took a look at the code and see that feature/redrawhook branch > applies highlighting in zle-line-pre-redraw. Won't this cause issues > when zsh-syntax-highlighting is used together with > zsh-autosuggestions? Yes, such issues were reported, last confirmed 4 days ago: https://github.com/zsh-users/zsh-syntax-highlighting/issues/579 > zsh-autosuggestions doesn't wrap zle-line-pre-redraw by default, so it won't > apply its own highlighting on top of zsh-syntax-highlighting. Okay, and what could z-sy-h do about this? The redrawhook branch fixes a *lot* of bugs, so I'm not eager to make it optional. I suppose I could just tell people who use both plugins to stick to z-sy-h 0.7.0 (as opposed to master) until there's a z-asug release that uses «add-zle-hook-widget zle-line-pre-redraw» too — or is there a better solution that I'm overlooking? > If zsh-autosuggestions starts wrapping zle-line-pre-redraw by default, there > are still potential issues for users who upgrade their local > zsh-syntax-highlighting before zsh-autosuggestions. I'm not overly concerned about this. Anyone who uses z-sy-h from master should _expect_ to live on the bleeding edge. Anyone who's not ready to live on the bleeding edge should stick to tags (or, at least, follow master with an N days' delay, so any issues will be ironed out before they get to it). > There are also users who manually set ZSH_AUTOSUGGEST_IGNORE_WIDGETS. And how does this affect z-sy-h? Cheers, Daniel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 17:06 ` Daniel Shahaf @ 2020-01-10 17:35 ` Roman Perepelitsa 2020-01-10 18:09 ` z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) Daniel Shahaf 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-10 17:35 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users, ericdfreese On Fri, Jan 10, 2020 at 6:06 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > [sorry for the late answer] No worries. Thanks for replying. Let me try to describe what's going on. I've only skimmed through the implementations of these plugins, so please take it with a grain of salt. When zsh-syntax-highlighting is used together with zsh-autosuggestions, everything works correctly as long as every widget in which zsh-syntax-highlighting applies its highlighting is wrapped by zsh-autosuggestions. This is necessary because zsh-syntax-highlighting removes highlighting from POSTDISPLAY. There are two situations where the combination of zsh-syntax-highlighting and zsh-autosuggestions results in missing POSTDISPLAY highlighting: 1. zsh-syntax-highlighting is applying highlighting in a widget that zsh-autosuggestions does not wrap. 2. zsh-syntax-highlighting has wrapped a widget *after* zsh-autosuggestions wrapped it. https://github.com/zsh-users/zsh-syntax-highlighting/issues/579 happens because of (1). Specifically, zsh-syntax-highlighting is applying highlighting in zle-line-pre-redraw, which zsh-autosuggestions doesn't wrap. zsh-autosuggestions doesn't wrap widgets whose names match patterns from ZSH_AUTOSUGGEST_IGNORE_WIDGETS. The default value of this parameter includes pattern `zle-*`. In order to use zsh-autosuggestions together with feature/redrawhook branch of zsh-syntax-highlighting users need to override ZSH_AUTOSUGGEST_IGNORE_WIDGETS so that it does not contain a pattern against which `zle-line-pre-redraw` can match. This may be a viable course of action even though it'll likely have very high cost for the users of these plugins. If I may make a suggestion, perhaps zsh-syntax-highlighting shouldn't remove highlighting from POSTDISPLAY? zsh-autosuggestions owns POSTDISPLAY area while zsh-syntax-highlighting owns BUFFER. zsh-autosuggestions doesn't touch highlighting of BUFFER, which allows it to peacefully coexist with syntax highlighting plugins. If zsh-syntax-highlighting did the same w.r.t. POSTDISPLAY highlighting, there would be no widget-wrapping-order dependencies and feature/redrawhook wouldn't introduce breaking changes for users who rely on both of these great plugins. Just my 2 cents. I hope it makes at least some sense. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 17:35 ` Roman Perepelitsa @ 2020-01-10 18:09 ` Daniel Shahaf 2020-01-10 18:14 ` Roman Perepelitsa 0 siblings, 1 reply; 35+ messages in thread From: Daniel Shahaf @ 2020-01-10 18:09 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: zsh-users, ericdfreese Roman Perepelitsa wrote on Fri, 10 Jan 2020 17:35 +00:00: > If I may make a suggestion, perhaps zsh-syntax-highlighting shouldn't > remove highlighting from POSTDISPLAY? zsh-autosuggestions owns > POSTDISPLAY area while zsh-syntax-highlighting owns BUFFER. zsh- > autosuggestions doesn't touch highlighting of BUFFER, which allows it > to peacefully coexist with syntax highlighting plugins. If zsh-syntax- > highlighting did the same w.r.t. POSTDISPLAY highlighting, there would > be no widget-wrapping-order dependencies and feature/redrawhook > wouldn't introduce breaking changes for users who rely on both of > these great plugins. > > Just my 2 cents. I hope it makes at least some sense. It does make sense. Nothing in z-sy-h highlights $POSTDISPLAY, so z-sy-h should coexist with plugins that do. The catch is that making the change will make it difficult to write a z-sy-h highlighter that handles PREDISPLAY and/or POSTDISPLAY, should anyone ever want to do that. (But if I have to choose between support for hypothetical future highlighters and interoperability with z-asug today, I'll choose the latter.) Might you be interested in writing a PR? Cheers, Daniel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 18:09 ` z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) Daniel Shahaf @ 2020-01-10 18:14 ` Roman Perepelitsa 2020-01-10 18:29 ` Daniel Shahaf 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-10 18:14 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users, ericdfreese On Fri, Jan 10, 2020 at 7:09 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > It does make sense. Nothing in z-sy-h highlights $POSTDISPLAY, so z-sy-h > should coexist with plugins that do. The catch is that making the > change will make it difficult to write a z-sy-h highlighter that handles > PREDISPLAY and/or POSTDISPLAY, should anyone ever want to do that. > (But if I have to choose between support for hypothetical future highlighters > and interoperability with z-asug today, I'll choose the latter.) I'm sure users would love this. It's nice when staple plugins just work. > Might you be interested in writing a PR? I'm afraid I'm terribly over-committed :-/ I'm trying to finish a couple of large features for p10k (which incidentally includes writing a zsh parser in zsh) and I still have that italic support patch for zsh in half finished state. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 18:14 ` Roman Perepelitsa @ 2020-01-10 18:29 ` Daniel Shahaf 2020-01-10 18:43 ` Roman Perepelitsa 0 siblings, 1 reply; 35+ messages in thread From: Daniel Shahaf @ 2020-01-10 18:29 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Zsh Users, ericdfreese Roman Perepelitsa wrote on Fri, 10 Jan 2020 18:14 +00:00: > On Fri, Jan 10, 2020 at 7:09 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Might you be interested in writing a PR? > > I'm afraid I'm terribly over-committed :-/ No worries, and thanks for the info about POSTDISPLAY. I assume that a dummy widget that does «{ POSTDISPLAY=foo; region_highlight+=( "$#BUFFER $(($#BUFFER + 2)) bold" ) }» could be used to mock z-asug for the purposes of the coexistence issue? > I'm trying to finish a couple of large features for p10k (which > incidentally includes writing a zsh parser in zsh) Isn't that basically what z-sy-h's main highlighter does? https://github.com/zsh-users/zsh-syntax-highlighting/issues/327 Cheers, Daniel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 18:29 ` Daniel Shahaf @ 2020-01-10 18:43 ` Roman Perepelitsa 2020-01-10 19:14 ` Daniel Shahaf 2020-01-10 22:42 ` Sebastian Gniazdowski 0 siblings, 2 replies; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-10 18:43 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users, ericdfreese On Fri, Jan 10, 2020 at 7:29 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > I assume that a dummy widget that does «{ POSTDISPLAY=foo; > region_highlight+=( "$#BUFFER $(($#BUFFER + 2)) bold" ) }» > could be used to mock z-asug for the purposes of the coexistence > issue? Yeah, I think so. Perhaps use $#POSTDISPLAY instead of 2 to avoid mistakes there. > > I'm trying to finish a couple of large features for p10k (which > > incidentally includes writing a zsh parser in zsh) > > Isn't that basically what z-sy-h's main highlighter does? Yep. I wasn't able to find an existing library to do this. z-sy-h's main highlighter isn't factored out, so I cannot reuse it. I also want something a bit more precise and performant. On the plus side my goal is more modest than z-sy-h. I only need to extract "command" words. For example, given this zsh code: () { sudo foo bar && baz } I want to get "sudo" "foo" and "baz". I've written some code that works decently well but needs a bit more polish. It's more precise than z-sy-h but still doesn't handle some corner cases. For example, given this setup: setopt interactive_comments alias foo='bar #' My code incorrectly extracts "bar" and "baz" from "foo; baz". It should be just "bar" here. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 18:43 ` Roman Perepelitsa @ 2020-01-10 19:14 ` Daniel Shahaf 2020-01-10 22:42 ` Sebastian Gniazdowski 1 sibling, 0 replies; 35+ messages in thread From: Daniel Shahaf @ 2020-01-10 19:14 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Zsh Users, ericdfreese Roman Perepelitsa wrote on Fri, 10 Jan 2020 18:43 +00:00: > On Fri, Jan 10, 2020 at 7:29 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > I assume that a dummy widget that does «{ POSTDISPLAY=foo; > > region_highlight+=( "$#BUFFER $(($#BUFFER + 2)) bold" ) }» > > could be used to mock z-asug for the purposes of the coexistence > > issue? > > Yeah, I think so. Perhaps use $#POSTDISPLAY instead of 2 to avoid > mistakes there. Thanks for confirming, and ack. > For example, given this zsh code: > > () { sudo foo bar && baz } > > I want to get "sudo" "foo" and "baz". The '{' is in command position as well. Consider «() pwd». > I've written some code that works decently well but needs a bit more > polish. It's more precise than z-sy-h If you know if any cases z-sy-h doesn't handle, please let us know :) > but still doesn't handle some corner cases. For example, given > this setup: > > setopt interactive_comments > alias foo='bar #' > > My code incorrectly extracts "bar" and "baz" from "foo; baz". It > should be just "bar" here. *nod* Cheers, Daniel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 18:43 ` Roman Perepelitsa 2020-01-10 19:14 ` Daniel Shahaf @ 2020-01-10 22:42 ` Sebastian Gniazdowski 2020-01-10 22:54 ` Roman Perepelitsa 1 sibling, 1 reply; 35+ messages in thread From: Sebastian Gniazdowski @ 2020-01-10 22:42 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh Users, ericdfreese [-- Attachment #1: Type: text/plain, Size: 539 bytes --] pt., 10 sty 2020, 19:45 użytkownik Roman Perepelitsa < roman.perepelitsa@gmail.com> napisał: > > I wasn't able to find an existing library to do this. z-sy-h's main > highlighter isn't factored out, so I cannot reuse it. I also want > something a bit more precise and performant. On the plus side my goal > is more modest than z-sy-h. I only need to extract "command" words. > For example, given this zsh code: > > () { sudo foo bar && baz } > > I want to get "sudo" "foo" and "baz". > You might check out zshelldoc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 22:42 ` Sebastian Gniazdowski @ 2020-01-10 22:54 ` Roman Perepelitsa 2020-01-10 23:46 ` Sebastian Gniazdowski 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-10 22:54 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh Users, ericdfreese On Fri, Jan 10, 2020 at 11:42 PM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > You might check out zshelldoc. Can I use it to extract commands from zsh code? Could you provide an example or point me in the right direction? Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 22:54 ` Roman Perepelitsa @ 2020-01-10 23:46 ` Sebastian Gniazdowski 2020-01-11 14:30 ` Roman Perepelitsa 0 siblings, 1 reply; 35+ messages in thread From: Sebastian Gniazdowski @ 2020-01-10 23:46 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh Users, Eric Freese On Fri, 10 Jan 2020 at 23:54, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > On Fri, Jan 10, 2020 at 11:42 PM Sebastian Gniazdowski > <sgniazdowski@gmail.com> wrote: > > > > You might check out zshelldoc. > > Can I use it to extract commands from zsh code? Could you provide an > example or point me in the right direction? Yes, it contains the code to extract the commands and also function bodies from Zsh source. The code responsible for this starts at line 186 of src/zsd-detect.main. The place in code to get the command is line 325 of the file. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-10 23:46 ` Sebastian Gniazdowski @ 2020-01-11 14:30 ` Roman Perepelitsa 2020-01-12 2:42 ` Sebastian Gniazdowski 0 siblings, 1 reply; 35+ messages in thread From: Roman Perepelitsa @ 2020-01-11 14:30 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh Users [moving ericdfreese@gmail.com to bcc as this isn't related to zsh-autosuggestions] On Sat, Jan 11, 2020 at 12:46 AM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > Yes, it contains the code to extract the commands and also function > bodies from Zsh source. The code responsible for this starts at line > 186 of src/zsd-detect.main. The place in code to get the command is > line 325 of the file. Thanks, this is the hint I needed . $token at zsd-detect.main:325 is always a word in the command position, right? I'm looking for a parser that's a bit more precise. Here are a few examples of zsh code I want to be handled correctly: 2>&1 x x <<END y END for x ( ; ) y case x in a) y;; b) esac I also need alias expansion. For example, given this setup: alias a='1> ' # note the trailing space alias b='/dev/null x' alias x=y alias c=';' The parser should give me `x` when parsing `a b c d` because after alias expansion `a b c d` becomes this: 1> /dev/null y c d The parser needs to be fast as I'm going to be calling it from zle. It shouldn't perform I/O (no file globbing) and must not have side effects. These constraints mean that correct parsing is impossible to implement. For example, there is no way to figure out what `*` does . I'm OK with it. Given the choice between false positives (parser says something is a command when it isn't) and false negatives (parser misses a command), I would prefer false positives. I'm not asking you (or anyone else) to build this for me. Just sharing to provide context. Roman. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-11 14:30 ` Roman Perepelitsa @ 2020-01-12 2:42 ` Sebastian Gniazdowski 2020-01-12 2:47 ` Sebastian Gniazdowski 0 siblings, 1 reply; 35+ messages in thread From: Sebastian Gniazdowski @ 2020-01-12 2:42 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh Users On Sat, 11 Jan 2020 at 15:30, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > Thanks, this is the hint I needed . $token at zsd-detect.main:325 is > always a word in the command position, right? Yes. As I've added some commits recently I'll link the line of code so that the reference will be safe: https://github.com/zdharma/zshelldoc/blob/ccba867/src/zsd-detect.main#L318 > I'm looking for a parser that's a bit more precise. Here are a few > examples of zsh code I want to be handled correctly: > > 2>&1 x > > x <<END > y > END > > for x ( ; ) y > > case x in > a) y;; > b) > esac I would also add: array=( x y z ) > The parser needs to be fast as I'm going to be calling it from zle. It > shouldn't perform I/O (no file globbing) and must not have side > effects. These constraints mean that correct parsing is impossible to > implement. For example, there is no way to figure out what `*` does . > I'm OK with it. Given the choice between false positives (parser says > something is a command when it isn't) and false negatives (parser > misses a command), I would prefer false positives. > > I'm not asking you (or anyone else) to build this for me. Just sharing > to provide context. I hope that I've could help. I think that what's practically useful is the TOKEN_TYPES array that's taken from z-sy-h/f-sy-h and extended, and its way of use to decide on the state change that the parser should undergo. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) 2020-01-12 2:42 ` Sebastian Gniazdowski @ 2020-01-12 2:47 ` Sebastian Gniazdowski 0 siblings, 0 replies; 35+ messages in thread From: Sebastian Gniazdowski @ 2020-01-12 2:47 UTC (permalink / raw) To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh Users On Sun, 12 Jan 2020 at 03:42, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > On Sat, 11 Jan 2020 at 15:30, Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > Thanks, this is the hint I needed . $token at zsd-detect.main:325 is > > always a word in the command position, right? > > Yes. As I've added some commits recently I'll link the line of code so > that the reference will be safe: > > https://github.com/zdharma/zshelldoc/blob/ccba867/src/zsd-detect.main#L318 PS. The $fun_stack_depths[-1] -le 0 condition isn't needed from one point of view – it verifies if the call is being done in the foremost function and not in a nested function. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-08 10:00 ` Peter Stephenson 2020-01-08 21:55 ` Andrey Butirsky @ 2020-01-09 14:18 ` Andrey Butirsky 2020-01-09 14:29 ` Peter Stephenson 1 sibling, 1 reply; 35+ messages in thread From: Andrey Butirsky @ 2020-01-09 14:18 UTC (permalink / raw) To: zsh-users On 08.01.2020 13:00, Peter Stephenson wrote: > # Create widget backward-kill-space-word, using the generic > # backward-kill-word widget function. > zle -N backward-kill-space-word backward-kill-word-match > # Tell it to use "space" style for words. > zstyle ':zle:backward-kill-space-word:*' word-style space Is the asterisk here '...:*' needed for something? > # Bind it. > bindkey '^W' backward-kill-space-word ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 14:18 ` emulate bash key bindings Andrey Butirsky @ 2020-01-09 14:29 ` Peter Stephenson 2020-01-10 0:46 ` Andrey Butirsky 0 siblings, 1 reply; 35+ messages in thread From: Peter Stephenson @ 2020-01-09 14:29 UTC (permalink / raw) To: zsh-users On Thu, 2020-01-09 at 17:18 +0300, Andrey Butirsky wrote: > On 08.01.2020 13:00, Peter Stephenson wrote: > > > > # Create widget backward-kill-space-word, using the generic > > # backward-kill-word widget function. > > zle -N backward-kill-space-word backward-kill-word-match > > # Tell it to use "space" style for words. > > zstyle ':zle:backward-kill-space-word:*' word-style space > Is the asterisk here '...:*' needed for something? Safety. Contexts get added to with more specific information. Some examples are given later in the zshcontrib manual. Even if you never use them, this will still work. pws ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-09 14:29 ` Peter Stephenson @ 2020-01-10 0:46 ` Andrey Butirsky 2020-01-10 9:51 ` Peter Stephenson 0 siblings, 1 reply; 35+ messages in thread From: Andrey Butirsky @ 2020-01-10 0:46 UTC (permalink / raw) To: zsh-users On 09.01.2020 17:29, Peter Stephenson wrote: > On Thu, 2020-01-09 at 17:18 +0300, Andrey Butirsky wrote: >> On 08.01.2020 13:00, Peter Stephenson wrote: >>> zstyle ':zle:backward-kill-space-word:*' word-style space >> Is the asterisk here '...:*' needed for something? > Safety. Contexts get added to with more specific information. > Some examples are given later in the zshcontrib manual. Even > if you never use them, this will still work. Is it me who intended to add to that context for my widgets, or it can be changed implicitly somehow? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 0:46 ` Andrey Butirsky @ 2020-01-10 9:51 ` Peter Stephenson 2020-01-10 10:58 ` Peter Stephenson 0 siblings, 1 reply; 35+ messages in thread From: Peter Stephenson @ 2020-01-10 9:51 UTC (permalink / raw) To: zsh-users On Fri, 2020-01-10 at 03:46 +0300, Andrey Butirsky wrote: > On 09.01.2020 17:29, Peter Stephenson wrote: > > > > On Thu, 2020-01-09 at 17:18 +0300, Andrey Butirsky wrote: > > > > > > On 08.01.2020 13:00, Peter Stephenson wrote: > > > > > > > > zstyle ':zle:backward-kill-space-word:*' word-style space > > > Is the asterisk here '...:*' needed for something? > > Safety. Contexts get added to with more specific information. > > Some examples are given later in the zshcontrib manual. Even > > if you never use them, this will still work. > Is it me who intended to add to that context for my widgets, or it can > be changed implicitly somehow? The point is there are contributed widgets that test with a context ":zle:name-of-widget:some-other-stuff". I haven't looked to see if you're likely to encounter them in what you're doing, but it's easy to be sure you're not going to fall foul of that. It's possible word-style is never looked up like that --- but it's a good habit just to be careful. The point was actually to try *not* to need a long discussion about behaviour :-). pws ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 9:51 ` Peter Stephenson @ 2020-01-10 10:58 ` Peter Stephenson 2020-01-10 11:07 ` Peter Stephenson ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Peter Stephenson @ 2020-01-10 10:58 UTC (permalink / raw) To: zsh-users On Fri, 2020-01-10 at 09:51 +0000, Peter Stephenson wrote: > On Fri, 2020-01-10 at 03:46 +0300, Andrey Butirsky wrote: > > > > On 09.01.2020 17:29, Peter Stephenson wrote: > > > > > > > > > On Thu, 2020-01-09 at 17:18 +0300, Andrey Butirsky wrote: > > > > > > > > > > > > On 08.01.2020 13:00, Peter Stephenson wrote: > > > > > > > > > > > > > > > zstyle ':zle:backward-kill-space-word:*' word-style space > > > > Is the asterisk here '...:*' needed for something? > > > Safety. Contexts get added to with more specific information. > > > Some examples are given later in the zshcontrib manual. Even > > > if you never use them, this will still work. > > Is it me who intended to add to that context for my widgets, or it can > > be changed implicitly somehow? > > The point is there are contributed widgets that test with a context > ":zle:name-of-widget:some-other-stuff". I haven't looked to see > if you're likely to encounter them in what you're doing, but it's > easy to be sure you're not going to fall foul of that. I just looked at the code... Actually, I'm wrong and in generally you *don't* want that stuff. I need it in my case because I'm using the ridiculously over the top word-context style (which I suspect no one else has ever used). *This* gives you a subcontext. Otherwise, you *don't* get an extra subcomponent, so you need to leave out the ":*". There is documentation on word-context indicating this extra behaviour, but it isn't relevant in your case, so I've just been confusing you, sorry. Here's an example of the re-using a match widget for a specific style. pws diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo index d51fd518b..1e335d29d 100644 --- a/Doc/Zsh/contrib.yo +++ b/Doc/Zsh/contrib.yo @@ -2227,7 +2227,20 @@ is set in the context tt(:zle:*) to tt(true) if the word style is tt(bash) and tt(false) otherwise. It may be overridden by setting it in the more specific context tt(:zle:forward-word*). -Here are some examples of use of the styles, actually taken from the +It is possible to create widgets with specific behaviour by defining +a new widget implemented by the appropriate generic function, then +setting a style for the context of the specific widget. For example, +the following defines a widget tt(backward-kill-space-word) using +tt(backward-kill-word-match), the generic widget implmenting +tt(backward-kill-word) behaviour, and ensures that the new widget +always implements space-delimited behaviour. + +example(zle -N backward-kill-space-word backward-kill-word-match +zstyle :zle:backward-kill-space-word word-style space) + +The widget tt(backward-kill-space-word) can now be bound to a + +Here are some further examples of use of the styles, actually taken from the simplified interface in tt(select-word-style): example(zstyle ':zle:*' word-style standard @@ -2251,7 +2264,7 @@ zstyle ':zle:transpose-words:whitespace' word-style shell zstyle ':zle:transpose-words:filename' word-style normal zstyle ':zle:transpose-words:filename' word-chars '') -This provides two different ways of using tt(transpose-words) depending on +This provides two different ways of using tt(transporse-words) depending on whether the cursor is on whitespace between words or on a filename, here any word containing a tt(/). On whitespace, complete arguments as defined by standard shell rules will be transposed. In a filename, only ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 10:58 ` Peter Stephenson @ 2020-01-10 11:07 ` Peter Stephenson 2020-01-10 11:47 ` Mikael Magnusson 2020-01-10 14:00 ` Andrey Butirsky 2 siblings, 0 replies; 35+ messages in thread From: Peter Stephenson @ 2020-01-10 11:07 UTC (permalink / raw) To: zsh-users On Fri, 2020-01-10 at 10:58 +0000, Peter Stephenson wrote: > Here's an example of the re-using a match widget for a specific style. >... > @@ -2251,7 +2264,7 @@ zstyle ':zle:transpose-words:whitespace' word-style shell > zstyle ':zle:transpose-words:filename' word-style normal > zstyle ':zle:transpose-words:filename' word-chars '') > > -This provides two different ways of using tt(transpose-words) depending on > +This provides two different ways of using tt(transporse-words) depending on > whether the cursor is on whitespace between words or on a filename, here > any word containing a tt(/). On whitespace, complete arguments as defined > by standard shell rules will be transposed. In a filename, only ... and obviously I will not be submitting this bit. pws ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 10:58 ` Peter Stephenson 2020-01-10 11:07 ` Peter Stephenson @ 2020-01-10 11:47 ` Mikael Magnusson 2020-01-10 14:00 ` Andrey Butirsky 2 siblings, 0 replies; 35+ messages in thread From: Mikael Magnusson @ 2020-01-10 11:47 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 1/10/20, Peter Stephenson <p.stephenson@samsung.com> wrote: > Here's an example of the re-using a match widget for a specific style. > > pws > > diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo > index d51fd518b..1e335d29d 100644 > --- a/Doc/Zsh/contrib.yo > +++ b/Doc/Zsh/contrib.yo > @@ -2227,7 +2227,20 @@ is set in the context tt(:zle:*) to tt(true) if the > word style is > tt(bash) and tt(false) otherwise. It may be overridden by setting it in > the more specific context tt(:zle:forward-word*). > > -Here are some examples of use of the styles, actually taken from the > +It is possible to create widgets with specific behaviour by defining > +a new widget implemented by the appropriate generic function, then > +setting a style for the context of the specific widget. For example, > +the following defines a widget tt(backward-kill-space-word) using > +tt(backward-kill-word-match), the generic widget implmenting implementing > +tt(backward-kill-word) behaviour, and ensures that the new widget > +always implements space-delimited behaviour. > + > +example(zle -N backward-kill-space-word backward-kill-word-match > +zstyle :zle:backward-kill-space-word word-style space) > + > +The widget tt(backward-kill-space-word) can now be bound to a unfinished sentence, presumably "key" is missing? > + > +Here are some further examples of use of the styles, actually taken from > the > simplified interface in tt(select-word-style): -- Mikael Magnusson ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: emulate bash key bindings 2020-01-10 10:58 ` Peter Stephenson 2020-01-10 11:07 ` Peter Stephenson 2020-01-10 11:47 ` Mikael Magnusson @ 2020-01-10 14:00 ` Andrey Butirsky 2 siblings, 0 replies; 35+ messages in thread From: Andrey Butirsky @ 2020-01-10 14:00 UTC (permalink / raw) To: zsh-users, Peter Stephenson On 10.01.2020 13:58, Peter Stephenson wrote: > I just looked at the code... > > Actually, I'm wrong and in generally you *don't* want that stuff. > > I need it in my case because I'm using the ridiculously over the top > word-context style (which I suspect no one else has ever used). *This* > gives you a subcontext. Otherwise, you *don't* get an extra > subcomponent, so you need to leave out the ":*". There is documentation > on word-context indicating this extra behaviour, but it isn't relevant > in your case, so I've just been confusing you, sorry. > > Here's an example of the re-using a match widget for a specific style. > > ... Thank you Peter for the clarification and documentation update! ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2020-01-12 2:47 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20200107184011eucas1p241073778b2cdd5bf7e94b43851273d49@eucas1p2.samsung.com> 2020-01-07 18:38 ` emulate bash key bindings Andrey Butirsky 2020-01-08 2:26 ` Sebastian Gniazdowski 2020-01-08 2:37 ` Andrey Butirsky 2020-01-08 4:26 ` dana 2020-01-08 9:06 ` Mikael Magnusson 2020-01-08 10:00 ` Peter Stephenson 2020-01-08 21:55 ` Andrey Butirsky 2020-01-08 22:03 ` Roman Perepelitsa 2020-01-08 22:23 ` Daniel Shahaf 2020-01-09 0:05 ` Andrey Butirsky 2020-01-09 8:45 ` Roman Perepelitsa 2020-01-09 9:27 ` Andrey 2020-01-09 10:44 ` Roman Perepelitsa 2020-01-09 11:03 ` Roman Perepelitsa 2020-01-10 17:06 ` Daniel Shahaf 2020-01-10 17:35 ` Roman Perepelitsa 2020-01-10 18:09 ` z-sy-h and z-asug: zle-line-pre-redraw, POSTDISPLAY, coexistence (was: Re: emulate bash key bindings) Daniel Shahaf 2020-01-10 18:14 ` Roman Perepelitsa 2020-01-10 18:29 ` Daniel Shahaf 2020-01-10 18:43 ` Roman Perepelitsa 2020-01-10 19:14 ` Daniel Shahaf 2020-01-10 22:42 ` Sebastian Gniazdowski 2020-01-10 22:54 ` Roman Perepelitsa 2020-01-10 23:46 ` Sebastian Gniazdowski 2020-01-11 14:30 ` Roman Perepelitsa 2020-01-12 2:42 ` Sebastian Gniazdowski 2020-01-12 2:47 ` Sebastian Gniazdowski 2020-01-09 14:18 ` emulate bash key bindings Andrey Butirsky 2020-01-09 14:29 ` Peter Stephenson 2020-01-10 0:46 ` Andrey Butirsky 2020-01-10 9:51 ` Peter Stephenson 2020-01-10 10:58 ` Peter Stephenson 2020-01-10 11:07 ` Peter Stephenson 2020-01-10 11:47 ` Mikael Magnusson 2020-01-10 14:00 ` Andrey Butirsky
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).