* (backward-)kill-argument @ 2002-03-13 16:42 Michal Maruška 2002-03-13 19:09 ` (backward-)kill-argument John Beppu 2002-03-15 8:55 ` (backward-)kill-argument Sven Wischnowsky 0 siblings, 2 replies; 10+ messages in thread From: Michal Maruška @ 2002-03-13 16:42 UTC (permalink / raw) To: zsh-workers 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument 2002-03-13 16:42 (backward-)kill-argument Michal Maruška @ 2002-03-13 19:09 ` John Beppu 2002-03-13 20:23 ` (backward-)kill-argument -- reformulation of the problem Michal Maruška 2002-03-15 8:55 ` (backward-)kill-argument Sven Wischnowsky 1 sibling, 1 reply; 10+ messages in thread From: John Beppu @ 2002-03-13 19:09 UTC (permalink / raw) To: Michal Maru?ka; +Cc: zsh-workers [ 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); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument -- reformulation of the problem 2002-03-13 19:09 ` (backward-)kill-argument John Beppu @ 2002-03-13 20:23 ` Michal Maruška 0 siblings, 0 replies; 10+ messages in thread From: Michal Maruška @ 2002-03-13 20:23 UTC (permalink / raw) To: John Beppu; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument 2002-03-13 16:42 (backward-)kill-argument Michal Maruška 2002-03-13 19:09 ` (backward-)kill-argument John Beppu @ 2002-03-15 8:55 ` Sven Wischnowsky 2002-03-15 15:31 ` (backward-)kill-argument Bart Schaefer 1 sibling, 1 reply; 10+ messages in thread From: Sven Wischnowsky @ 2002-03-15 8:55 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument 2002-03-15 8:55 ` (backward-)kill-argument Sven Wischnowsky @ 2002-03-15 15:31 ` Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument Bart Schaefer ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Bart Schaefer @ 2002-03-15 15:31 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument 2002-03-15 15:31 ` (backward-)kill-argument Bart Schaefer @ 2002-03-15 15:49 ` Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) Michal Maruška 2002-03-18 8:36 ` (backward-)kill-argument Sven Wischnowsky 2 siblings, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2002-03-15 15:49 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) 2002-03-15 15:31 ` (backward-)kill-argument Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument Bart Schaefer @ 2002-03-15 15:49 ` Michal Maruška 2002-03-15 16:39 ` Bart Schaefer 2002-03-18 8:36 ` (backward-)kill-argument Sven Wischnowsky 2 siblings, 1 reply; 10+ messages in thread From: Michal Maruška @ 2002-03-15 15:49 UTC (permalink / raw) To: zsh-workers "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). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) 2002-03-15 15:49 ` (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) Michal Maruška @ 2002-03-15 16:39 ` Bart Schaefer 2002-03-18 8:41 ` Sven Wischnowsky 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2002-03-15 16:39 UTC (permalink / raw) To: Michal Marus<ka, zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) 2002-03-15 16:39 ` Bart Schaefer @ 2002-03-18 8:41 ` Sven Wischnowsky 0 siblings, 0 replies; 10+ messages in thread From: Sven Wischnowsky @ 2002-03-18 8:41 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: (backward-)kill-argument 2002-03-15 15:31 ` (backward-)kill-argument Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) Michal Maruška @ 2002-03-18 8:36 ` Sven Wischnowsky 2 siblings, 0 replies; 10+ messages in thread From: Sven Wischnowsky @ 2002-03-18 8:36 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-03-18 8:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-13 16:42 (backward-)kill-argument Michal Maruška 2002-03-13 19:09 ` (backward-)kill-argument John Beppu 2002-03-13 20:23 ` (backward-)kill-argument -- reformulation of the problem Michal Maruška 2002-03-15 8:55 ` (backward-)kill-argument Sven Wischnowsky 2002-03-15 15:31 ` (backward-)kill-argument Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument Bart Schaefer 2002-03-15 15:49 ` (backward-)kill-argument (1/2 thanks 1/2 problem re-statement) Michal Maruška 2002-03-15 16:39 ` Bart Schaefer 2002-03-18 8:41 ` Sven Wischnowsky 2002-03-18 8:36 ` (backward-)kill-argument Sven Wischnowsky
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).