* Strange _values completion on accept-and-menu-complete and menu selection @ 2004-12-11 10:11 Andrey Borzenkov 2004-12-11 21:05 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Andrey Borzenkov @ 2004-12-11 10:11 UTC (permalink / raw) To: zsh-workers For a long time I have the following bindings: {pts/1}% bindkey -M menuselect ... "," accept-and-menu-complete "/" accept-and-infer-next-history Apparently it does not work any more for _values; I presume it did work once because _urpmi completion includes _values usage in question. Consider: function _foo () { _values -s , "test completion" 'foo: :(1 2 3)' bar baz } compdef _foo foo now start completion: {pts/2}% foo bar, Completing test completion bar baz foo ^^^ highlighted so far so good. But if I press ',' now (assuming complete current value and go on) I get {pts/2}% foo bar baz, Completing test completion bar baz foo ^^^ highlighted so auto-suffix is removed while it apparently should not to be? OTOH doing pts/2}% foo bar, Completing test completion bar baz foo ^^^ highlighted now press "b" TAB gives you (as expected) pts/2}% foo bar,baz, Completing test completion bar baz foo Even more interesting with subvalue: {pts/2}% foo foo= Completing test completion bar baz foo press '/' {pts/2}% foo foo=1, 1 2 3 OK so ENTER (to accept it) TAB you get {pts/2}% foo foo=1,bar, Completing test completion bar baz and pressing ',' now results in {pts/2}% foo foo=1,bar foo=1,baz, Completing test completion bar baz so something strange goes on when menu selection is used. non default settings: bindkey -e bindkey '^I' complete-word bindkey '^[q' push-line-or-edit bindkey -M menuselect , accept-and-menu-complete bindkey -M menuselect / accept-and-infer-next-history setopt autopushd setopt cdablevars setopt extendedhistory setopt extendedglob setopt histexpiredupsfirst setopt histignorealldups setopt histignoredups setopt histreduceblanks setopt histsavenodups setopt ignoreeof setopt menucomplete setopt nobanghist setopt nolistambiguous setopt nolistbeep setopt pushdminus # The following lines were added by compinstall autoload -U compinit compinit zstyle ':completion:*' auto-description ''''specify: %d'''' zstyle ':completion:*' completer _oldlist _complete _match zstyle ':completion:*' format ''''Completing %d'''' zstyle ':completion:*' group-name '' zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS} zstyle ':completion:*' list-prompt '%SAt %p: Hit TAB for more, or the character to insert%s' zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}' 'm:{a-z}={A-Z} r:| [._-]=* * r:|=**' zstyle ':completion:*' match-original both zstyle ':completion:*' menu select=0 zstyle ':completion:*' verbose true zstyle :compinstall filename '/home/bor/.zshrc' # End of lines added by compinstall zstyle ':completion:*' list-rows-first true zstyle ':completion:*:paths' accept-exact true regards -andrey ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-11 10:11 Strange _values completion on accept-and-menu-complete and menu selection Andrey Borzenkov @ 2004-12-11 21:05 ` Bart Schaefer 2004-12-12 16:15 ` Andrey Borzenkov 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2004-12-11 21:05 UTC (permalink / raw) To: Andrey Borzenkov; +Cc: zsh-workers On Sat, 11 Dec 2004, Andrey Borzenkov wrote: > Apparently it does not work any more for _values; I presume it did work > once because _urpmi completion includes _values usage in question. Looking at the code, I can't see any way it ever worked. There's been no interesting change anywhere near or beyond (in the function call sense) the point where complist.c handles accept-and-menu-complete. The problem is that accept_last() is called, which eventually always calls iremovesuffix(' ', 1). If "compadd -R" had been used, the suffix function would be called and could subvert the behavior of iremovesuffix(), but as it stands the suffix is always zapped. The deeper problem seems to be that the complist module doesn't really know anything about compvalues; e.g., as far as complist is concerned it's selecting among shell words, not from a set of values that are part of a word. That it comes as close as it does to working is serendipitous. A fix seems to be something in the direction of this pseudo-patch (do NOT apply it as-is) to compresult.c, but I don't know how to get the boolean value for "we are not completing values from compvalues" at this location. @@ -1241,16 +1241,19 @@ lastbrbeg->str[l + 1] = '\0'; } else { int l; + int rem = /* We are not completing values from compvalues */; cs = minfo.pos + minfo.len + minfo.insc; - iremovesuffix(' ', 1); + if (rem) + iremovesuffix(' ', 1); l = cs; cs = minfo.pos + minfo.len + minfo.insc - (*(minfo.cur))->qisl; if (cs < l) foredel(l - cs); else if (cs > ll) cs = ll; - inststrlen(" ", 1, 1); + if (rem) + inststrlen(" ", 1, 1); minfo.insc = minfo.len = 0; minfo.pos = cs; minfo.we = 1; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-11 21:05 ` Bart Schaefer @ 2004-12-12 16:15 ` Andrey Borzenkov 2004-12-12 17:51 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Andrey Borzenkov @ 2004-12-12 16:15 UTC (permalink / raw) To: zsh-workers On Sunday 12 December 2004 00:05, Bart Schaefer wrote: > A fix seems to be something in the direction of this pseudo-patch (do NOT > apply it as-is) to compresult.c, but I don't know how to get the boolean > value for "we are not completing values from compvalues" at this location. > I already got a prototype patch for it when I accidentally hit a-a-i-n-h and voila - it did what I expected from a-a-m-c (except that a-a-m-c stays on the same word while a-a-i-n-h starts from scratch - because with a-a-i-n-h it actually starts new completion every time). I attach prototype patch - it adds compstate element that tells accept_last to skip suffix removal. It can be used in more general case than just _values - what I am not sure how and when this is to be set. I.e. using this patch following function now "correctly" works for a-a m-c: function _foo () { compstate[stayinword]=1 compset -P '*,' compadd -qS , ${(k)compstate} } compdef _foo foo regards -andrey Index: Src/Zle/complete.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v retrieving revision 1.27 diff -u -p -r1.27 complete.c --- Src/Zle/complete.c 7 Dec 2004 16:55:11 -0000 1.27 +++ Src/Zle/complete.c 12 Dec 2004 16:13:03 -0000 @@ -38,7 +38,8 @@ zlong compcurrent, complistmax; /**/ zlong complistlines, - compignored; + compignored, + compstayinword; /**/ mod_export @@ -1018,6 +1019,7 @@ static struct compparam compkparams[] = { "list_lines", PM_INTEGER | PM_READONLY, NULL, GSU(listlines_gsu) }, { "all_quotes", PM_SCALAR | PM_READONLY, VAL(compqstack), NULL }, { "ignored", PM_INTEGER | PM_READONLY, VAL(compignored), NULL }, + { "stayinword", PM_INTEGER, VAL(compstayinword), NULL }, { NULL, 0, NULL, NULL } }; Index: Src/Zle/compresult.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v retrieving revision 1.52 diff -u -p -r1.52 compresult.c --- Src/Zle/compresult.c 12 Jul 2004 10:05:52 -0000 1.52 +++ Src/Zle/compresult.c 12 Dec 2004 16:13:04 -0000 @@ -1243,14 +1243,16 @@ accept_last(void) int l; cs = minfo.pos + minfo.len + minfo.insc; - iremovesuffix(' ', 1); + if (!compstayinword) + iremovesuffix(' ', 1); l = cs; cs = minfo.pos + minfo.len + minfo.insc - (*(minfo.cur))->qisl; if (cs < l) foredel(l - cs); else if (cs > ll) cs = ll; - inststrlen(" ", 1, 1); + if (!compstayinword) + inststrlen(" ", 1, 1); minfo.insc = minfo.len = 0; minfo.pos = cs; minfo.we = 1; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-12 16:15 ` Andrey Borzenkov @ 2004-12-12 17:51 ` Bart Schaefer 2004-12-12 21:06 ` Andrey Borzenkov 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2004-12-12 17:51 UTC (permalink / raw) To: zsh-workers On Sun, 12 Dec 2004, Andrey Borzenkov wrote: > I attach prototype patch - it adds compstate element that tells > accept_last to skip suffix removal. It can be used in more general case > than just _values - what I am not sure how and when this is to be set. I wonder if perhaps another state name would be better. "Stay in word" is a directive, whereas everything else in compstate is, well, state data. What if it were compstate[compound_word] and the value is the separator character to insert? (Or perhaps two characters, corresponding to "compvalues -s" and "compvalues -S" in that order.) Normally compstate[compound_word] would be unset, but "compvalues -i" would set it based on the parse. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-12 17:51 ` Bart Schaefer @ 2004-12-12 21:06 ` Andrey Borzenkov 2004-12-12 21:44 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Andrey Borzenkov @ 2004-12-12 21:06 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 1638 bytes --] On Sunday 12 December 2004 20:51, Bart Schaefer wrote: > On Sun, 12 Dec 2004, Andrey Borzenkov wrote: > > I attach prototype patch - it adds compstate element that tells > > accept_last to skip suffix removal. It can be used in more general case > > than just _values - what I am not sure how and when this is to be set. > > I wonder if perhaps another state name would be better. "Stay in word" is > a directive, whereas everything else in compstate is, well, state data. > > What if it were compstate[compound_word] and the value is the separator > character to insert? (Or perhaps two characters, corresponding to > "compvalues -s" and "compvalues -S" in that order.) > > Normally compstate[compound_word] would be unset, but "compvalues -i" > would set it based on the parse. I still believe this is more general and should not be limited to _values only. Also -S does not seem to be needed here. Here is updated patch (which also fixes initialization problem). It makes parameter compound_word as scalar but currently tests only for empty value (is it correct way to test for it BTW?) Setting compstate[compound_word] to any string in completion function will stop accept_last from removing suffix (actually, altering string in any way). This also changes _values to set it as appropriate. This still has problems in completing nested calls to _values (should it work?) Try this example: function _foo_val () { _values -s : "subvalues" baz bad bam } function _foo () { _values -s , -S = "test values" \ foo \ "bar:bar values:_foo_val" } compdef _foo foo regards -andrey [-- Attachment #2: compound_word.diff --] [-- Type: text/x-diff, Size: 4531 bytes --] Index: Completion/Base/Utility/_values =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_values,v retrieving revision 1.8 diff -u -p -r1.8 _values --- Completion/Base/Utility/_values 16 Apr 2002 07:55:49 -0000 1.8 +++ Completion/Base/Utility/_values 12 Dec 2004 20:44:45 -0000 @@ -10,10 +10,13 @@ zparseopts -D -E -a garbage C=usecc O:=s if compvalues -i "$@"; then local noargs args opts descr action expl sep argsep subc test='*' - local oldcontext="$curcontext" + local oldcontext="$curcontext" compound=$compstate[compound] compvalues -S argsep - compvalues -s sep && [[ -n "$sep" ]] && test="[^${(q)sep}]#" + compvalues -s sep && [[ -n "$sep" ]] && { + test="[^${(q)sep}]#" + compstate[compound_word]=yes + } if ! compvalues -D descr action; then @@ -148,6 +151,7 @@ if compvalues -i "$@"; then fi fi + compstate[compound]=$compound curcontext="$oldcontext" [[ nm -ne "$compstate[nmatches]" ]] Index: Src/Zle/comp.h =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/comp.h,v retrieving revision 1.14 diff -u -p -r1.14 comp.h --- Src/Zle/comp.h 21 May 2002 08:07:51 -0000 1.14 +++ Src/Zle/comp.h 12 Dec 2004 20:44:46 -0000 @@ -375,9 +375,11 @@ typedef void (*CLPrintFunc)(Cmgroup, Cma #define CP_QUOTES (1 << CPN_QUOTES) #define CPN_IGNORED 25 #define CP_IGNORED (1 << CPN_IGNORED) +#define CPN_COMPOUND 26 +#define CP_COMPOUND (1 << CPN_COMPOUND) -#define CP_KEYPARAMS 26 -#define CP_ALLKEYS ((unsigned int) 0x3ffffff) +#define CP_KEYPARAMS 27 +#define CP_ALLKEYS ((unsigned int) 0x7ffffff) /* Hooks. */ Index: Src/Zle/compcore.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v retrieving revision 1.68 diff -u -p -r1.68 compcore.c --- Src/Zle/compcore.c 5 Nov 2004 16:20:24 -0000 1.68 +++ Src/Zle/compcore.c 12 Dec 2004 20:44:49 -0000 @@ -764,6 +764,8 @@ callcompfunc(char *s, char *fn) compoldlist = compoldins = ""; compoldlist = ztrdup(compoldlist); compoldins = ztrdup(compoldins); + zsfree(compcompound); + compcompound = ztrdup(""); incompfunc = 1; startparamscope(); Index: Src/Zle/complete.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v retrieving revision 1.27 diff -u -p -r1.27 complete.c --- Src/Zle/complete.c 7 Dec 2004 16:55:11 -0000 1.27 +++ Src/Zle/complete.c 12 Dec 2004 20:44:49 -0000 @@ -70,7 +70,8 @@ char *compiprefix, *comptoend, *compoldlist, *compoldins, - *compvared; + *compvared, + *compcompound; /**/ Param *comprpms, *compkpms; @@ -1018,6 +1019,7 @@ static struct compparam compkparams[] = { "list_lines", PM_INTEGER | PM_READONLY, NULL, GSU(listlines_gsu) }, { "all_quotes", PM_SCALAR | PM_READONLY, VAL(compqstack), NULL }, { "ignored", PM_INTEGER | PM_READONLY, VAL(compignored), NULL }, + { "compound_word", PM_SCALAR, VAL(compcompound), NULL }, { NULL, 0, NULL, NULL } }; @@ -1428,7 +1430,7 @@ setup_(UNUSED(Module m)) compquoting = comprestore = complist = compinsert = compexact = compexactstr = comppatmatch = comppatinsert = complastprompt = comptoend = compoldlist = compoldins = - compvared = compqstack = NULL; + compvared = compqstack = compcompound = NULL; complastprefix = ztrdup(""); complastsuffix = ztrdup(""); complistmax = 0; @@ -1508,6 +1510,7 @@ finish_(UNUSED(Module m)) zsfree(compoldlist); zsfree(compoldins); zsfree(compvared); + zsfree(compcompound); hascompmod = 0; Index: Src/Zle/compresult.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v retrieving revision 1.52 diff -u -p -r1.52 compresult.c --- Src/Zle/compresult.c 12 Jul 2004 10:05:52 -0000 1.52 +++ Src/Zle/compresult.c 12 Dec 2004 20:44:49 -0000 @@ -1243,14 +1243,16 @@ accept_last(void) int l; cs = minfo.pos + minfo.len + minfo.insc; - iremovesuffix(' ', 1); + if (!compcompound || strlen(compcompound) == 0) + iremovesuffix(' ', 1); l = cs; cs = minfo.pos + minfo.len + minfo.insc - (*(minfo.cur))->qisl; if (cs < l) foredel(l - cs); else if (cs > ll) cs = ll; - inststrlen(" ", 1, 1); + if (!compcompound || strlen(compcompound) == 0) + inststrlen(" ", 1, 1); minfo.insc = minfo.len = 0; minfo.pos = cs; minfo.we = 1; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-12 21:06 ` Andrey Borzenkov @ 2004-12-12 21:44 ` Bart Schaefer 2004-12-13 10:43 ` Peter Stephenson 2004-12-25 17:32 ` Andrey Borzenkov 0 siblings, 2 replies; 8+ messages in thread From: Bart Schaefer @ 2004-12-12 21:44 UTC (permalink / raw) To: zsh-workers On Mon, 13 Dec 2004, Andrey Borzenkov wrote: > > Normally compstate[compound_word] would be unset, but "compvalues -i" > > would set it based on the parse. > > I still believe this is more general and should not be limited to _values Sure; compstate[compound_word] doesn't have to be read-only, any function that needs it could set it. It just seems correct and convenient to have compvalues set it automatically. > Here is updated patch (which also fixes initialization problem). There's one line of shell code where you have compstate[compound] but want compstate[compound_word]. No need to repost, but fix before commit. > This still has problems in completing nested calls to _values (should it > work?) I don't have time to debug carefully just now, but I suspect without any real evidence that compstate[compound_word] is becoming unset on return from the nested call and therefore is wrong for the subsequent selections for the outer call. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-12 21:44 ` Bart Schaefer @ 2004-12-13 10:43 ` Peter Stephenson 2004-12-25 17:32 ` Andrey Borzenkov 1 sibling, 0 replies; 8+ messages in thread From: Peter Stephenson @ 2004-12-13 10:43 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > > This still has problems in completing nested calls to _values (should it > > work?) > > I don't have time to debug carefully just now, but I suspect without any > real evidence that compstate[compound_word] is becoming unset on return > from the nested call and therefore is wrong for the subsequent selections > for the outer call. I'm not looking at the particular problem in any detail, but I believe this is standard behaviour for completion variables to make it easier to chain completions without saving and restoring inconvenient amounts of state. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Strange _values completion on accept-and-menu-complete and menu selection 2004-12-12 21:44 ` Bart Schaefer 2004-12-13 10:43 ` Peter Stephenson @ 2004-12-25 17:32 ` Andrey Borzenkov 1 sibling, 0 replies; 8+ messages in thread From: Andrey Borzenkov @ 2004-12-25 17:32 UTC (permalink / raw) To: zsh-workers On Monday 13 December 2004 00:44, Bart Schaefer wrote: > On Mon, 13 Dec 2004, Andrey Borzenkov wrote: > > > Normally compstate[compound_word] would be unset, but "compvalues -i" > > > would set it based on the parse. > > > > I still believe this is more general and should not be limited to _values > > Sure; compstate[compound_word] doesn't have to be read-only, any function > that needs it could set it. It just seems correct and convenient to have > compvalues set it automatically. > > > Here is updated patch (which also fixes initialization problem). > > There's one line of shell code where you have compstate[compound] but want > compstate[compound_word]. No need to repost, but fix before commit. > it is far from being suitable for commit (and I was off most of the time). > > This still has problems in completing nested calls to _values (should it > > work?) > > I don't have time to debug carefully just now, but I suspect without any > real evidence that compstate[compound_word] is becoming unset on return > from the nested call and therefore is wrong for the subsequent selections > for the outer call. it is more general problem. When match is inserted it has all parts - ignored prefix, prefix, etc insterted. In our case we actually have as iprefix everything up to separator - and get everything up to separator reinserted. It happens without any nested calls too: {pts/0}% foo foo,TAB {pts/0}% foo foo,bazzz, Completing test values barr bazzz and hitting a-a-m-c {pts/0}% foo foo,bazzz,foo,barr It is the same problem as completion in braces. Braces are treated as special case inside completion code unfortunately. Hopefully it is possile to generalize it. -andrey ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-12-25 17:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-11 10:11 Strange _values completion on accept-and-menu-complete and menu selection Andrey Borzenkov 2004-12-11 21:05 ` Bart Schaefer 2004-12-12 16:15 ` Andrey Borzenkov 2004-12-12 17:51 ` Bart Schaefer 2004-12-12 21:06 ` Andrey Borzenkov 2004-12-12 21:44 ` Bart Schaefer 2004-12-13 10:43 ` Peter Stephenson 2004-12-25 17:32 ` Andrey Borzenkov
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).