zsh-users
 help / color / mirror / code / Atom feed
* 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-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

* 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

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).