[-- 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.
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
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.
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
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
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
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.
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.
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
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?
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.
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..
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.
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.
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
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
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?
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
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
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
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
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!
[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
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.
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
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.
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
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.
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
[-- 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.
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.
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
[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.
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
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