(backward-)kill-argument

(backward-)kill-argument

[Michal Maruška]

i want to:
  * kill filenames w/  spaces: e.g.    this\ is\ file.txt

  * maybe even the bracketed part:
        find  { -name '*.h' }

Is it possible in Zsh?

Re: (backward-)kill-argument

[John Beppu]

[  date  ] 2002/03/13 | Wednesday | 05:42 PM
[ author ] Michal Maru?ka <mmc@maruska.dyndns.org> 

Finally, something I can answer.  ;-)

> i want to:
>   * kill filenames w/  spaces: e.g.    this\ is\ file.txt

    rm *[\ ]*

    This uses a character class with a space in it '[\ ]'
    surrounded by whatever '*' which zsh understands as
    any file with a space in its name.
 
>   * maybe even the bracketed part:
>         find  { -name '*.h' }

    print **/*.h
 
    This uses the '**/' to tell zsh to glob recursively,
    and the '*.h' says to look for '*.h' while it's at it.
    If you study zsh's globbing, you'll find that it can
    do a lot of the same things the find(1) program can
    do.  
    
    To learn about some of zsh's find-like abilities,
    $(man zshexpn) and search for "Glob Qualifiers".
    Glob qualifiers allow you to put an expression in
    parentheses after a glob pattern to make the glob
    more specific.

    For example:

        find . -type d      # find directories only

    can be expressed in zsh as:

        print -l **/*(/)    # (/) means directories only

    I only suggest starting with glob qualifiers, because
    I found it the most interesting (and least intimidating)
    place to start.  To get the whole picture, $(man zshexpn)
    and search for the "FILENAME EXPANSION" section.


-- 
package wuv'apqvjgt;($_=join('',(*PgtnHcemgt))) # print map "beppu\@$_\n", qw(
=~ s/([HaP])(?!e)/ \U>$1/g;s/^.|:| (?=A)|>//g;y # cpan.org  lbox.org  binq.org
/c-z/a-u/;print"J$_\n";#$^%$^X@.^ <!-- japh --> # oss.lineo.com codepoet.org);

Re: (backward-)kill-argument -- reformulation of the problem

[Michal Maruška]

John Beppu <beppu@Ax9.org> writes:

> > i want to: * kill filenames w/ spaces: e.g.  this\ is\ file.txt
>     rm *[\ ]*

Hi John,

i feel very sorry, that i expressed myself very bad. My problem is
completely different from what i, unfortunately, described, and you answered.


I don't want to operate on my filesystem. I want to have a command in the ZLE
(Zsh' interactive line editor), which resembles backward-kill-word, but kills a whole
argument.  So imagine, i write ( _ is the cursor position):

$ cat this\ is\ file.txt_
and now i want:
$ cat just\ another\ document.html

Currently i have to backward-kill-word 3 times (and write the new argument).

> >   * maybe even the bracketed part: find { -name '*.h' }

Here i assume, that Zsh (in its completion system) "knows" that -name option of
find(1) takes 1 argument. So i could delete all this constraint.
In other words, from   (and the cursor could be under the text "-name '*.h'")
$  find  -name '*.h'_
i want to obtain 
$  find

If i was writing it in lisp/scheme, i could be typing
$ (find  (-name '*.h') ....)

and just delete the inner-most sexp.

TIA

Re: (backward-)kill-argument

[Sven Wischnowsky]

Michal =?iso-8859-2?q?Maru=B9ka?= wrote:

> i want to:
>   * kill filenames w/  spaces: e.g.    this\ is\ file.txt

Write yourself a little widget. As a starting point:

  zle -N kill-with-spaces
  kill-with-spaces() {
    local words
    words="${(z)BUFFER}"
    BUFFER="${BUFFER%${words[-1]}[ 	]#}"
  }
  bindkey <key> kill-with-spaces

(There's a space and a TAB inside that [ ].)


>   * maybe even the bracketed part:
>         find  { -name '*.h' }
> 
> Is it possible in Zsh?

Using the above you could check if $words[-1] is one of the closing
braces and if it is, search back in the array for the matching opening
brace. When found, you can delete the end of $BUFFER up to that
matching brace by using a pattern of the form:

  ${words[-n]}[ 	]##...[ 	]##${words[-1]}[ 	]#


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: (backward-)kill-argument

[Bart Schaefer]

On Mar 15,  9:55am, Sven Wischnowsky wrote:
}
} > i want to:
} >   * kill filenames w/  spaces: e.g.    this\ is\ file.txt
} 
} Write yourself a little widget. As a starting point:
} 
}   kill-with-spaces() {
}     local words
}     words="${(z)BUFFER}"
}     BUFFER="${BUFFER%${words[-1]}[ 	]#}"
}   }

That's a nice function, Sven, but I think I'd call it something like
`backward-kill-shell-word', and it ought to test $LBUFFER, not $BUFFER.
If you throw in `setopt localoptions extendedglob', we could even put
it in the distribution,

} (There's a space and a TAB inside that [ ].)

You can write that as [[:space:]] now, I think?

} >   * maybe even the bracketed part:
} >         find  { -name '*.h' }
} > 
} > Is it possible in Zsh?
} 
} Using the above you could check if $words[-1] is one of the closing
} braces and if it is, search back in the array for the matching opening
} brace. When found, you can delete the end of $BUFFER up to that
} matching brace by using a pattern of the form:
} 
}   ${words[-n]}[ 	]##...[ 	]##${words[-1]}[ 	]#

Hmm, I think I'd just do a loop killing words until the open-brace was
missing from $LBUFFER.  So, putting it all together,

    backward-kill-shell-expression() {
        setopt localoptions extendedglob
        local words
        words="${(z)LBUFFER}"
        LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
        if [[ "$words[-1]" == '}' ]]
        then
            words="${(z)LBUFFER}"
            while [[ "${${(@M)words:#[\{\}]}[-1]}" == '{' ]]
            do
                LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
                words="${(z)LBUFFER}"
            done
        fi
    }

This could be extended to handle `( ... )', `[[ ... ]]', etc., and we
could of course also write a forward- version.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: (backward-)kill-argument

[Bart Schaefer]

On Mar 15,  3:31pm, I wrote:
}
}             words="${(z)LBUFFER}"
}             while [[ "${${(@M)words:#[\{\}]}[-1]}" == '{' ]]
}             do
}                 LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
}                 words="${(z)LBUFFER}"
}             done

I suppose that could be done slightly faster as

            words[-1]=()
            while [[ "${${(@M)words:#[\{\}]}[-1]}" == '{' ]]
            do
                LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
                words[-1]=()
            done

if it really is the case that deleting from the end of the string won't
change the (z) parse?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement)

[Michal Maruška]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> On Mar 15, 9:55am, Sven Wischnowsky wrote:
> }
> } > i want to: * kill filenames w/ spaces: e.g.  this\ is\ file.txt
> }  Write yourself a little widget. As a starting point:
> } 
> }   kill-with-spaces() { local words words="${(z)BUFFER}"
> }BUFFER="${BUFFER%${words[-1]}[ ]#}" }
> 
> That's a nice function, Sven, but I think I'd call it something like
> `backward-kill-shell-word', and it ought to test $LBUFFER, not $BUFFER.  If you
> throw in `setopt localoptions extendedglob', we could even put it in the
> distribution,
> 
> } (There's a space and a TAB inside that [ ].)
> 
> You can write that as [[:space:]] now, I think?
> 

Thanks to both of you. I am arriving to what i wanted.


> } >   * maybe even the bracketed part: find { -name '*.h' }
> } > 
> } > Is it possible in Zsh?
> }  Using the above you could check if $words[-1] is one of the closing braces
> }and if it is, search back in the array for the matching opening brace. When
> }found, you can delete the end of $BUFFER up to that matching brace by using a
> }pattern of the form:
> } 
> }   ${words[-n]}[ ]##...[ ]##${words[-1]}[ ]#
> 
> Hmm, I think I'd just do a loop killing words until the open-brace was missing
> from $LBUFFER.  So, putting it all together,
> 
>     backward-kill-shell-expression() {
>         setopt localoptions extendedglob
>         local words
>         words="${(z)LBUFFER}"
>         LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
>         if [[ "$words[-1]" == '}' ]]
>         then
>             words="${(z)LBUFFER}"
>             while [[ "${${(@M)words:#[\{\}]}[-1]}" == '{' ]]
>             do
>                 LBUFFER="${LBUFFER%${words[-1]}[[:space:]]#}"
>                 words="${(z)LBUFFER}"
>             done
>         fi
>     }
> 
> This could be extended to handle `( ... )', `[[ ... ]]', etc., and we could of
> course also write a forward- version.


But here i again explained wrongly what i intended.

[
I must admit, i would like to migrate from Zsh, sh etc.  to SCSH (scheme
shell). Just Zsh has these unique and elaborated completion & other systems. But
these remain cryptic to me, and i (still) prefer to improve my understanding of scheme
rather that of Zsh (module system of ?) completion system.
]

I immagine Zsh keeps a database (roughly) like:
                        [and i am interested in how it works]

commands| minus-arguments|sort-of-type| completion action for the type (widget?)
--------------------------------------------------------------------------
find       -name           wants 1 text


now these brakets:
        find { -name '*.h' }
i used only to delimit what i would like to remove. I have got in
the  ZLE buffer (on the line) simply:
        find  -name '*.h' 

And now i want to delete all "-name '*.h' "  which is  product of some grammar
rule, or simply the minus-argument with its argument(s).

Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement)

[Bart Schaefer]

On Mar 15,  4:49pm, Michal Marus<ka wrote:
}
} I immagine Zsh keeps a database (roughly) like:

No, zsh keeps no database.  The syntax of every command is described by
a "completion function" which is written for that specific command.
There are a few other functions that describe generic types of syntax
that can be shared by many commands, but ultimately the only "database"
that zsh uses is a hash mapping a context (either a command name, or
something like -redirect- for what follows a redirection operator) to
a function that computes the completions for that context.

There is nothing that describes the syntax to the editor for purposes of
reversing this mapping, so the editor can't use the "knowledge" that the
completion system has of individual command contexts to perform syntactic
analysis of the edited text.  It only has access to the generic parsing
rules of the (extended) Bourne shell scripting language used by the shell
itself.

Something like what you describe could be created in the same way that
the completion system itself was created -- built up one function at a time
for all the possible contexts that you want to recognize and operate on --
but it does not currently exist.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: (backward-)kill-argument

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> } (There's a space and a TAB inside that [ ].)
> 
> You can write that as [[:space:]] now, I think?

Yes, I was lazy.


In another message:

> if it really is the case that deleting from the end of the string won't
> change the (z) parse?

It shouldn't.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement)

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> Something like what you describe could be created in the same way that
> the completion system itself was created -- built up one function at a time
> for all the possible contexts that you want to recognize and operate on --
> but it does not currently exist.

If I'm not completely mistaken, we even once talked about this (at
least I remember me thinking about something similar). But the problem
is that this would be very complicated to describe (statically) with
all the different ways commands handle their arguments, plus run-time
and operating system dependencies.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de