* disable substring match on command name @ 2014-03-02 17:08 Amm 2014-03-02 20:18 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Amm @ 2014-03-02 17:08 UTC (permalink / raw) To: zsh-users Hello, I have following line in .zsh (via zsh-newuser-install) zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' This does substring match on command and filenames. i.e. if there is command in system say /usr/bin/foobar and I type $> oob<TAB> it changes to foobar. This can cause accidental running of some different command if there is spelling mistake. (Especially when you are in a hurry). As with spelling mistake there is high chance of matching a random command. What I would like is substring match to work only on file and directory names. (i.e. arguments to command) I do not want substring match on command. Please suggest how to do it? I searched on Google but could not find anything. (Either I dont know right keyword to search or not many want this feature) Amm. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-02 17:08 disable substring match on command name Amm @ 2014-03-02 20:18 ` Bart Schaefer 2014-03-03 7:13 ` Amm 2014-03-03 17:25 ` Oliver Kiddle 0 siblings, 2 replies; 20+ messages in thread From: Bart Schaefer @ 2014-03-02 20:18 UTC (permalink / raw) To: zsh-users On Mar 3, 1:08am, Amm wrote: } } zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' } } This can cause accidental running of some different command if there is } spelling mistake. } } What I would like is substring match to work only on file and } directory names. (i.e. arguments to command) Hmm. The matcher-list style is looked up very early by _main_complete so details of the context (like whether you are in command position or in the argument list) are not available. However, you could use "zstyle -e" to examine a bit more state and set the matcher-list accordingly. For (incomplete) example: zstyle -e ':completion:*' matcher-list '(( CURRENT > 1 )) && ...' The difficulty with this is that the quoting to assign to the $reply array (in the part I elided with "...") gets really complicated. Fortunately, I thought of a way to make that a little easier, by the somewhat non-obvious trick of chaining zstyles together. The format of the zstyle context is freeform (compsys meerly imposes a standard set of colon-separated components) so we can put some extra stuff at the front to create a new "style namespace". In this case I suggest prefixing with "word-N" where N is the value of $CURRENT. So first we modify your matcher-list context like so: zstyle 'word-*:completion:*' matcher-list \ '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' Then we introduce a new matcher for word-1, which will be preferred to the generic word-* context when looked up: zstyle 'word-1:completion:*' matcher-list '' This just says not to use any matcher for the first word. If you want to do *some* kinds of matching on the command name (case-insensitivity, for example) just add those to this style. Finally we tweak the style that compsys is actually going to look up, to have it prefix the context with the word position and then look up the new style: zstyle -e ':completion:*' matcher-list \ 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' By stuffing the result of the chained zstyle -a into the $reply parameter, we satisfy the requirement of "zstyle -e" to pass this back to whatever actual lookup was done. And presto, we have different matcher-list styles for the first word and the rest of the words. A few remarks for zsh-workers (please follow up there if interested): It would be useful for "zstyle -e" if the lookup context and style name were available in parameters. E.g. the above trick could be made more generic if one could do zstyle -e ':completion:*' matcher-list \ 'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply' The example names LOOKUP and STYLE are probably not the best choices. Additionally, the line number for xtrace is messed up while evaluating the "zstyle -e" command. I *think* it ends up being the line number in the init file (or interpreter line) where the zstyle was declared, but it is labeled with the name of the calling function. E.g. output from _complete_debug: +_main_complete:160> zstyle -a :completion::complete::: matcher-list _matchers +_main_complete:5> zstyle -a word-2:completion::complete:: matcher-list reply Not sure whether anything can be done about that. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-02 20:18 ` Bart Schaefer @ 2014-03-03 7:13 ` Amm 2014-03-03 16:48 ` Bart Schaefer 2014-03-03 17:25 ` Oliver Kiddle 1 sibling, 1 reply; 20+ messages in thread From: Amm @ 2014-03-03 7:13 UTC (permalink / raw) To: zsh-users > On Mar 3, Bart Schaefer wrote: >> On Mar 3, 1:08am, Amm wrote: >> zstyle ':completion:*' matcher-list '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' >> >> This can cause accidental running of some different command if there is >> spelling mistake. >> >> What I would like is substring match to work only on file and >> directory names. (i.e. arguments to command) (Snippets Bart Schaefer solution:) > first we modify your matcher-list context like so: > zstyle 'word-*:completion:*' matcher-list \ > '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' > Then we introduce a new matcher for word-1, which will be preferred to > zstyle 'word-1:completion:*' matcher-list '' > Finally we tweak the style that compsys is actually going to look up, > zstyle -e ':completion:*' matcher-list \ > 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' Hi, Thanks a lot for putting a lot of effort here. I appreciate it. But your solution possible would not work if command is entered after pipe symbol. echo 1 2 | sort In that example sort would NOT be the first word but 4th or 5th. I have not tried your solution though. And I also find it little bit hackish. However I found a better solution after a lot of reading (this is just my 2nd day learning zsh, so took lots of time) TIP: I got hint from man page for zstyle tag-order I removed matcher-list line. And added the following: zstyle ':completion:*' tag-order '*' '*:-afrr' '*:-aflr' zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**' zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*' First line tells to first run 'normal' tag-order. If a match is not found run same tags but with -afrr appended to tag and if match is still not found then run same with -aflr appended. If zsh is expecting a command then all-files tag does not exist. Hence matcher style is also not executed. (only normal match is tried). So it will work even if command is like (echo 1 2 | sort). zsh knows that after pipe it should be a command. If zsh is expecting a filename then first it will try normal match, if no match is found afrr and aflr (tag) matcher. Hope this helps others who are looking for similar solutions. (TIP: when zsh is expecting a directory [if its 'cd' command], all-files tag is not checked. In that case you can use local-directories tag in same way as all-files tag as above) Amm ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-03 7:13 ` Amm @ 2014-03-03 16:48 ` Bart Schaefer 2014-03-04 3:45 ` Amm 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-03 16:48 UTC (permalink / raw) To: zsh-users On Mar 3, 3:13pm, Amm wrote: } } Thanks a lot for putting a lot of effort here. I appreciate it. You're welcome! } > On Mar 3, Bart Schaefer wrote: } > Finally we tweak the style that compsys is actually going to look up, } > zstyle -e ':completion:*' matcher-list \ } > 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' } } But your solution possible would not work if command is entered } after pipe symbol. } } echo 1 2 | sort } } In that example sort would NOT be the first word but 4th or 5th. Just to clear this up: It would still be the 1st word. By the time the $words array has been populated, the completion internals have figured out that "|" separates two commands and you are presumably finished completing the one that does not encompass $CURSOR, so it removes the "|" and everything before it. In fact, if you had echo 2 1 | sort | tr 12 34 and were completing after "sort", it would also remove "| tr ..." so that $words contains only the relevant command. None of compsys would work if every completer had to figure out for itself what to use for $CURRENT in a pipeline or complex command. } I have not tried your solution though. And I also find it little } bit hackish. Admittedly it is, and in fact I had forgotten that individual "matcher" zstyles were looked up by tag. The key bit to your solution is ... } I removed matcher-list line. ... because matcher-list is applied ALONG WITH the "matcher" style if both are specified. There have often been questions in the past about how to limit the application of matcher-list given how little context is used, and I found the chaining idea interesting. } zstyle ':completion:*' tag-order '*' '*:-afrr' '*:-aflr' } zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**' } zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*' It might be worthwhile to note in the docs that matcher-list is in effect a shorthand for something like this, but I can't find a good place that doesn't confuse the flow of the existing examples ... Here, though, is some related clarification of the docs. diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo index c304461..7dacbcf 100644 --- a/Doc/Zsh/compsys.yo +++ b/Doc/Zsh/compsys.yo @@ -1995,11 +1995,11 @@ only be performed with the `tt(*)' inserted. kindex(matcher, completion style) item(tt(matcher))( This style is tested separately for each tag valid in the current -context. Its value is added to any match specifications given by the +context. Its value is tried before any match specifications given by the tt(matcher-list) style. It should be in the form described in ifzman(the section `Completion Matching Control' in zmanref(zshcompwid))\ ifnzman(noderef(Completion Matching Control))\ -. +. For examples of this, see the description of the tt(tag-order) style. ) kindex(matcher-list, completion style) item(tt(matcher-list))( @@ -2022,9 +2022,11 @@ without repetition: example(zstyle ':completion:*' matcher-list '' '+m:{a-z}={A-Z}' '+m:{A-Z}={a-z}') It is possible to create match specifications valid for particular -completers by using the third field of the context. For example, to -use the completers tt(_complete) and tt(_prefix) but only allow -case-insensitive completion with tt(_complete): +completers by using the third field of the context. This applies only +to completers that override the global matcher-list, which as of this +writing includes only tt(_prefix) and tt(_ignored). For example, to +use the completers tt(_complete) and tt(_prefix) but allow +case-insensitive completion only with tt(_complete): example(zstyle ':completion:*' completer _complete _prefix zstyle ':completion:*:complete:*' matcher-list \ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-03 16:48 ` Bart Schaefer @ 2014-03-04 3:45 ` Amm 2014-03-04 5:30 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Amm @ 2014-03-04 3:45 UTC (permalink / raw) To: zsh-users ----- Original Message ----- From: Bart Schaefer <schaefer@brasslantern.com> >> But your solution possible would not work if command is entered >> after pipe symbol. >> >> echo 1 2 | sort >> >> In that example sort would NOT be the first word but 4th or 5th. > Just to clear this up: It would still be the 1st word. Oh that's great. Thanks for clarification. >> I removed matcher-list line. > ... because matcher-list is applied ALONG WITH the "matcher" style Actually it works even with empty matcher-list but then I suppose no point in keeping it. > Here, though, is some related clarification of the docs. > diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo Is that a proposed diff to doc or you have already added it? (Dont know if you are one of the developers) Thanks again, AMM. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-04 3:45 ` Amm @ 2014-03-04 5:30 ` Bart Schaefer 0 siblings, 0 replies; 20+ messages in thread From: Bart Schaefer @ 2014-03-04 5:30 UTC (permalink / raw) To: zsh-users On Mar 4, 11:45am, Amm wrote: } } > Here, though, is some related clarification of the docs. } > diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo } } Is that a proposed diff to doc or you have already added } it? (Dont know if you are one of the developers) I haven't added it *yet*, but I am one of the developers. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-02 20:18 ` Bart Schaefer 2014-03-03 7:13 ` Amm @ 2014-03-03 17:25 ` Oliver Kiddle 2014-03-04 8:34 ` Amm 2014-03-09 5:37 ` disable substring match on command name Bart Schaefer 1 sibling, 2 replies; 20+ messages in thread From: Oliver Kiddle @ 2014-03-03 17:25 UTC (permalink / raw) To: zsh-users Bart wrote: > zstyle -e ':completion:*' matcher-list \ > 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' That's very nifty. I wouldn't even call "hackish". You're just allowing pattern matching to extend to fields that aren't in the standard list. My only comment is that I'd be inclined to add the custom context component at the end rather than the beginning. > zstyle -e ':completion:*' matcher-list \ > 'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply' > > The example names LOOKUP and STYLE are probably not the best choices. How about simply adding an option for chained styles so you might have: zstyle -c ':completion:*' matcher-list "word-$CURRENT" Admittedly, it'd be slightly less flexible. Oliver ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-03 17:25 ` Oliver Kiddle @ 2014-03-04 8:34 ` Amm 2014-03-04 17:13 ` Bart Schaefer 2014-03-09 5:37 ` disable substring match on command name Bart Schaefer 1 sibling, 1 reply; 20+ messages in thread From: Amm @ 2014-03-04 8:34 UTC (permalink / raw) To: zsh-users ----- Original Message ----- From: Oliver Kiddle <okiddle@yahoo.co.uk> > Bart wrote: >> zstyle -e ':completion:*' matcher-list \ >> 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' > That's very nifty. I wouldn't even call "hackish". You're just allowing > pattern matching to extend to fields that aren't in the standard list. Umm, actually I am evaluating which solution would be faster? Mine OR Bart's? Then I will switch to one which is faster. (and efficient) I am not sure how zstyle internally works but let me try. (Also not sure if this belongs to users maillist or workers) Case 1: ------- a) zstyle 'word-*:completion:*' matcher-list \ '' 'r:|[._-]=** r:|=**' 'l:|=* r:|=*' b) zstyle 'word-1:completion:*' matcher-list '' c) zstyle -e ':completion:*' matcher-list \ 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' zstyle pattern matching order, is based on most specific to least specific. So I think here specific-ness order in this case is b, a, c. So for each context (not just :completion:) it will: 1) First pattern match with b (which will always fail) 2) Second pattern match with a (again will always fail) 3) Third pattern match with c i) Continue to 4) if its :completion: context ii) Stop matching 4) Evalute another zstyle (word-1, word-2, ...) 5) When CURRENT is 1, b matches (so just 1 lookup) i) Return matcher-list b) arguments 6) When CURRENT is >1, b fails and a matches (so 2 lookups) i) Return matcher-list a) arguments 7) Do matcher-list matching as per what is returned by 5 OR 6 Points to note: Each matcher-list possibly calls matcher internally. For step 1, 2 pattern match fail on first character (w) itself. So 1, 2 almost takes not time. 4 = I dont know how expensive evaluate is, it is called every time. 7 = I dont know how expensive reply back is? One disadvantage is that you can not match context just for files and directories. Partial match may apply to command arguments, which may not be what you want. For e.g ls --li<TAB> will show you --literal --dereference-command-line Possibly there is no way to restrict this. Case-2: ------- (Note: I have modified tag-order line a bit to avoid re-checking all tags) a) zstyle ':completion:*' tag-order '*' 'all-files*:-afrr' 'all-files*:-aflr' b) zstyle ':completion:*:all-files-afrr' matcher 'r:|[._-]=** r:|=**' c) zstyle ':completion:*:all-files-aflr' matcher 'l:|=* r:|=*'Here order of checking would be b,c (for matcher style) So for each context (not just :completion:) it will: 1) Pattern match with a, if :completion: remember tag-order 2) Pattern match with b (will always fail) 3) Pattern match with c (will always fail) 4) Try normal command line completion, if succeeded stop 5) If 1) had matched and tag all-files exist? i) NO, then stop ii) YES then try tag all-files-afrr (goto 6) 6) Pattern match with b (will always succeed) 7) Check matcher b) arguments, if matched stop, else goto 8 8) Try tag with all-files-aflr 9) Pattern match with b (will always fail) 10) Pattern match with c (will always succeed) 11) Check matcher c) arguments So steps in this case are higher but its more or less just string comparison. There is no zstyle evaluation. One advantage over case 1) is you can match on any tag (files / directory etc) so you get more flexibility. You can block matching on aliases / command options etc. (Unlike in case 1) So now I am interested in knowing what would actually be faster? Can there be cases when 1 is faster other is slower and reverse in some other cases? Please give your inputs. Amm. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-04 8:34 ` Amm @ 2014-03-04 17:13 ` Bart Schaefer 2014-03-04 18:04 ` how to truncate an array Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-04 17:13 UTC (permalink / raw) To: zsh-users On Mar 4, 4:34pm, Amm wrote: } } Umm, actually I am evaluating which solution would be faster? Yours will probably be somewhat faster but not for the reasons you worked out. Looping over the completer list for each element of matcher-list is going to far outweigh anything else in the process. Removing the matcher-list style means that _main_complete calls each function in the completer zstyle only once, then _description takes just one shot at the matcher style during that iteration. The advantage of the matcher-list is that you get to try each of the listed matchers separately. With the matcher style all combinations are tried "at once"; in your example you have only one pattern in the matcher style so this doesn't apply, but in general it may matter. Hmm, my doc change said the matcher style is "tried before" the matcher-list if both are used, but that's not quite right; it's tried "at once" combined with each of the separate matcher-list patterns. I believe it takes effect first, which may alter the result of the later patterns but it doesn't stop them being applied. Hmm. } I am not sure how zstyle internally works but let me try. The internal workings of zstyle don't make a lot of difference here, unless you mean the internal workings of the matcher patterns, which would depend on what you're completing rather than on which of these methods you employed. } (Also not sure if this belongs to users maillist or workers) Users works fine. We're not *that* picky unless a long thread about C programming develops, or something like that. } 4 = I dont know how expensive evaluate is, it is called every time. There's a tiny bit of parsing overhead because the string to be eval'd can't be pre-compiled, but unless you're going to iterate a very large number of times that won't be signifcant. Executing the command after parsing is no more expensive than executing anything else. } 7 = I dont know how expensive reply back is? Same as any array assignment, it'll depend on how many elements are being added to the array. There's probably one extra array copy in the case of the "nested" zstyles. -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 20+ messages in thread
* how to truncate an array 2014-03-04 17:13 ` Bart Schaefer @ 2014-03-04 18:04 ` Ray Andrews 2014-03-04 18:44 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2014-03-04 18:04 UTC (permalink / raw) To: zsh-users This should be dead simple, but I can't figure out how to do it. I have an array that can be arbitrarily long, and I want to truncate it at 20 elements. setopt POSIX_STRINGS string[20]='\0' echo "string is now truncated: $string" ... I've tried every variation on the above theme that I can think of with no luck. I know that zsh likes to not truncate strings on 'null' but 'POSIX_STRINGS' is supposta force that, no? There must be a simple way to do this. I guess I still have C on the brain but it seems to me that it is God's will that a null terminates a string ... > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-04 18:04 ` how to truncate an array Ray Andrews @ 2014-03-04 18:44 ` Bart Schaefer 2014-03-04 20:02 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-04 18:44 UTC (permalink / raw) To: zsh-users On Mar 4, 10:04am, Ray Andrews wrote: } } This should be dead simple, but I can't figure out how to do it. I have } an array that can be } arbitrarily long, and I want to truncate it at 20 elements. Really an array? Or a string you want to index by character? array[21,-1]=() string[21,-1]='' } setopt POSIX_STRINGS } string[20]='\0' No, that inserted a literal backslash zero into the string. You meant string[21]=$'\0' # Zsh array indices start at 1, not at 0 but even that doesn't do what you intended because it doesn't actually insert a NUL into the array, it just deletes the 21st character. Assigning to string slices with subscript syntax causes the string to act like an array. Also, POSIX_STRINGS means that the string $'...' ends at the NUL, so $'\0' and $'' and $'\0stuff' are all the same. (Yes, you have C on the brain. A shell array and a C array are only loosely related; shell arrays behave more like linked lists.) Even if it did insert a NUL into the array, the array would't really be truncated, it's just that this: } echo "string is now truncated: $string" would truncate the quoted portion at the NUL and not show you the rest of the value of $string. A side-effect of POSIX_STRINGS is that practically speaking the only way to generate a NUL byte is to read one from an external program. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-04 18:44 ` Bart Schaefer @ 2014-03-04 20:02 ` Ray Andrews 2014-03-05 3:05 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2014-03-04 20:02 UTC (permalink / raw) To: zsh-users On 03/04/2014 10:44 AM, Bart Schaefer wrote: Bart, Really an array? Or a string you want to index by character? Ahright ... I forgot the rapturous string transubstantiation step: array=(${=input_string}) array[21,-1]=() ... and all is well. I despair of ever understanding this stuff :-( God knows what " =() " really does, and I'm smart enough to not even ask ;-) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-04 20:02 ` Ray Andrews @ 2014-03-05 3:05 ` Bart Schaefer 2014-03-05 5:09 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-05 3:05 UTC (permalink / raw) To: zsh-users On Mar 4, 12:02pm, Ray Andrews wrote: } } God knows what " =() " really does, and I'm smart enough to not even ask ;-) Heh. () in an assignment is just an array with no elements. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-05 3:05 ` Bart Schaefer @ 2014-03-05 5:09 ` Ray Andrews 2014-03-05 11:02 ` J. Darel Henman 2014-03-05 16:02 ` Bart Schaefer 0 siblings, 2 replies; 20+ messages in thread From: Ray Andrews @ 2014-03-05 5:09 UTC (permalink / raw) To: zsh-users On 03/04/2014 07:05 PM, Bart Schaefer wrote: > On Mar 4, 12:02pm, Ray Andrews wrote: > } > } God knows what " =() " really does, and I'm smart enough to not even ask ;-) > > Heh. () in an assignment is just an array with no elements. That's easy for you to say. ;-) What I mean is how the underlying C code knows to terminate the array. Come to think of it, there must be a null inserted, cuz that's how C does things even if zsh wants to be different. I wish we could just do the same thing up front and in yo' face. Nevermind, I hafta try to think like a zsheller. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-05 5:09 ` Ray Andrews @ 2014-03-05 11:02 ` J. Darel Henman 2014-03-05 15:34 ` Ray Andrews 2014-03-05 16:02 ` Bart Schaefer 1 sibling, 1 reply; 20+ messages in thread From: J. Darel Henman @ 2014-03-05 11:02 UTC (permalink / raw) To: zsh-users; +Cc: Ray Andrews Ray Andrews <rayandrews@eastlink.ca> wrote: > On 03/04/2014 07:05 PM, Bart Schaefer wrote: > > On Mar 4, 12:02pm, Ray Andrews wrote: > > } > > } God knows what " =() " really does, and I'm smart enough to not even ask ;-) > > > > Heh. () in an assignment is just an array with no elements. > That's easy for you to say. ;-) What I mean is how the underlying C > code knows to terminate > the array. Come to think of it, there must be a null inserted, cuz > that's how C does things > even if zsh wants to be different. I wish we could just do the same > thing up front and in yo' face. > Nevermind, I hafta try to think like a zsheller. Ray, I agree with the recommendation that you stop making assumptions that a shell's method of handilng a particular data structure, is the same as how one of the C language library functions does. The source code is availabe for you to read and study. If you come up with a better algorithm I'm sure it would be adopted. Thanks ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-05 11:02 ` J. Darel Henman @ 2014-03-05 15:34 ` Ray Andrews 0 siblings, 0 replies; 20+ messages in thread From: Ray Andrews @ 2014-03-05 15:34 UTC (permalink / raw) To: zsh-users On 03/05/2014 03:02 AM, J. Darel Henman wrote: > Ray, I agree with the recommendation that you stop making assumptions > that a shell's method of handilng a particular data structure, is the > same as how one of the C language library functions does. The source > code is availabe for you to read and study. If you come up with a > better algorithm I'm sure it would be adopted. Thanks Pardon. Just musing/speculating out loud. Actually, I am trying to remind myself not to think C while at the same time remembering that zsh is written in C. It will be a whole long time before I feel competent to make any serious suggestions. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-05 5:09 ` Ray Andrews 2014-03-05 11:02 ` J. Darel Henman @ 2014-03-05 16:02 ` Bart Schaefer 2014-03-05 16:48 ` Ray Andrews 1 sibling, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-05 16:02 UTC (permalink / raw) To: zsh-users On Mar 4, 9:09pm, Ray Andrews wrote: } Subject: Re: how to truncate an array } } What I mean is how the underlying C code knows to terminate } the array. Come to think of it, there must be a null inserted, cuz } that's how C does things Zsh does happen to manage shell arrays as C array-of-pointers but as I said before, in the shell syntax/semantics they function more like linked lists. Because the shell language is "higher level" than C, the internals have to deal with all sorts of other stuff like memory management. Bash, for example, does use linked lists internally to represent arrays. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: how to truncate an array 2014-03-05 16:02 ` Bart Schaefer @ 2014-03-05 16:48 ` Ray Andrews 0 siblings, 0 replies; 20+ messages in thread From: Ray Andrews @ 2014-03-05 16:48 UTC (permalink / raw) To: zsh-users On 03/05/2014 08:02 AM, Bart Schaefer wrote: > On Mar 4, 9:09pm, Ray Andrews wrote: > } Subject: Re: how to truncate an array > } > } What I mean is how the underlying C code knows to terminate > } the array. Come to think of it, there must be a null inserted, cuz > } that's how C does things > > Zsh does happen to manage shell arrays as C array-of-pointers but as > I said before, in the shell syntax/semantics they function more like > linked lists. Because the shell language is "higher level" than C, > the internals have to deal with all sorts of other stuff like memory > management. Bash, for example, does use linked lists internally to > represent arrays. > My talk is just me psyching myself up to build zsh from source and then start poking around in the code. Don't take my ruminations seriously Bart, you have better things to do. I'll stop making such remarks they make me sound bitchy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-03 17:25 ` Oliver Kiddle 2014-03-04 8:34 ` Amm @ 2014-03-09 5:37 ` Bart Schaefer 2014-03-09 6:14 ` Bart Schaefer 1 sibling, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2014-03-09 5:37 UTC (permalink / raw) To: zsh-users On Mar 3, 6:25pm, Oliver Kiddle wrote: } Subject: Re: disable substring match on command name } } Bart wrote: } > zstyle -e ':completion:*' matcher-list \ } > 'zstyle -a "word-${CURRENT}:completion:$curcontext" matcher-list reply' } } My only comment is that I'd be inclined to add the custom context } component at the end rather than the beginning. I thought about that, but the tag is already appended with no additional trailing colon in cases where it is known, and all current zstyle forms use a leading colon so that seemed the best place to put it. Also I was a bit worried that :completion:${curcontext}:word-N could match again the ':completion:*' pattern and put the whole thing into an loop. If you stick the word-N on the front, patterns that begin with ':completion' can't possibly match. } > zstyle -e ':completion:*' matcher-list \ } > 'zstyle -a "word-${CURRENT}$LOOKUP" "$STYLE" reply' } > } > The example names LOOKUP and STYLE are probably not the best choices. Thinking about this further, there's no reason for the style to be in a parameter; it's not a pattern, so by definition it must be the same as in the previous link in the chain (e.g., must be matcher-list above). Only the lookup pattern is unknown during the "zstye -e" evaluation. } How about simply adding an option for chained styles [...] } Admittedly, it'd be slightly less flexible. Trouble with this is that the ":"-separated context bits are not a feature of zstyle, they're a feature of the chosen use of zstyle in compsys. To add a chaining option we'd have to standardize on a syntax for gluing sub-patterns together, which zstyle would know about internally. That seems a bad idea. However, I came up with a solution to the "unknown lookup" problem as well -- compsys always has extendedglob set, so: zstyle -e '(#b)(:completion:*)' matcher-list \ 'zstyle -a "word-$CURRENT$match" matcher-list reply' A bit of a glitch with this is that zstyle does not save and restore $match et al. around its pattern lookups, but that's easily fixable because zregexparse already provides the necessary machinery right there in zutils.c where zstyle is also defined. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: disable substring match on command name 2014-03-09 5:37 ` disable substring match on command name Bart Schaefer @ 2014-03-09 6:14 ` Bart Schaefer 0 siblings, 0 replies; 20+ messages in thread From: Bart Schaefer @ 2014-03-09 6:14 UTC (permalink / raw) To: zsh-users On Mar 8, 9:37pm, Bart Schaefer wrote: } } zstyle -e '(#b)(:completion:*)' matcher-list \ } 'zstyle -a "word-$CURRENT$match" matcher-list reply' Turns out there are two other minor gotchas with this: (1) The pattern is compiled at the time the style is defined, so you must have extendedglob set for this to work; it's not sufficient that compsys has it set at the time of lookup. (2) However, the zstyles are stored by the literal pattern string, so if you accidentally define one like this with extendedglob NOT set, you have to explicitly delete it with 'zstyle -d' and then re-create it; it does not work to simply execute exactly the same zstyle command again after toggling extendedglob. I'm surprised the latter hasn't mysteriously bitten someone else in a different situation, but I guess zstyles aren't something that one frobs at the command line very often. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-03-09 6:15 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-02 17:08 disable substring match on command name Amm 2014-03-02 20:18 ` Bart Schaefer 2014-03-03 7:13 ` Amm 2014-03-03 16:48 ` Bart Schaefer 2014-03-04 3:45 ` Amm 2014-03-04 5:30 ` Bart Schaefer 2014-03-03 17:25 ` Oliver Kiddle 2014-03-04 8:34 ` Amm 2014-03-04 17:13 ` Bart Schaefer 2014-03-04 18:04 ` how to truncate an array Ray Andrews 2014-03-04 18:44 ` Bart Schaefer 2014-03-04 20:02 ` Ray Andrews 2014-03-05 3:05 ` Bart Schaefer 2014-03-05 5:09 ` Ray Andrews 2014-03-05 11:02 ` J. Darel Henman 2014-03-05 15:34 ` Ray Andrews 2014-03-05 16:02 ` Bart Schaefer 2014-03-05 16:48 ` Ray Andrews 2014-03-09 5:37 ` disable substring match on command name Bart Schaefer 2014-03-09 6:14 ` Bart Schaefer
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).