PATCH: Re: Why does ^X? behave differently than TAB?

PATCH: Re: Why does ^X? behave differently than TAB?

[Sven Wischnowsky]

Still no solution for the problem, but it made me notice that compcall 
is not defined as a auto-builtin.

And then there is a small fix for Peter's doc fixes (thanks, Peter).


Bye
 Sven

Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.49
diff -u -r1.49 compsys.yo
--- Doc/Zsh/compsys.yo	2000/05/17 21:28:30	1.49
+++ Doc/Zsh/compsys.yo	2000/05/18 09:19:29
@@ -1486,7 +1486,7 @@
 
 In addition to (or instead of) the above possibilities, the value may
 contain the string `tt(select)', optionally followed by an equal sign and a
-number.  In this case menu-selection (as defined by the tt(zsh/computil)
+number.  In this case menu-selection (as defined by the tt(zsh/complist)
 module) will be started.  Without the optional number, it will be started
 unconditionally and with a number it will be started only if at least that
 many matches are generated; if the values for more than one tag provide a
Index: Src/Zle/compctl.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compctl.mdd,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 compctl.mdd
--- Src/Zle/compctl.mdd	1999/12/16 14:26:38	1.1.1.10
+++ Src/Zle/compctl.mdd	2000/05/18 09:19:29
@@ -2,7 +2,7 @@
 
 moddeps="zsh/complete zsh/zle"
 
-autobins="compctl"
+autobins="compctl compcall"
 
 headers="compctl.h"
 objects="compctl.o"

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

PATCH: Re: Why does ^X? behave differently than TAB?

[Bart Schaefer]

On May 19,  3:24pm, Sven Wischnowsky wrote:
} Subject: Re: Why does ^X? behave differently than TAB?
}
} You wrote:
} 
} > Here's the actual script.  Run it as an autoloaded function.  At the
} > "ftpupdate command: " prompt, type ^X? twice.
} > 
} > ...
} > 
} > trap "$r ; trap - 0 2 3 15 ZERR ; return 1" 0 2 3 15 ZERR
} 
} The `compadd -x' in _message returns non-zero and makes this trap be
} called. And of course, the next time round, there is no `compctl -T'
} anymore.
} 
} Hm. I don't want to change the return value of compadd and it wouldn't 
} solve the problem anyway. Do we have to temporarily unset/default all
} traps in completion? Urgh.

Not all traps, just ZERR.  We should handle the errexit option, too.

Index: Completion/Commands/_complete_debug
===================================================================
@@ -3,6 +3,8 @@
 setopt localoptions nullglob rcexpandparam extendedglob
 unsetopt markdirs globsubst shwordsplit nounset ksharrays
 
+setopt localtraps noerrexit ; trap - ZERR
+
 (( $+_debug_count )) || integer -g _debug_count
 local tmp=${TMPPREFIX}${$}${words[1]:t}$[++_debug_count]
 local w="${(qq)words}"
Index: Completion/Core/_main_complete
===================================================================
@@ -20,6 +20,9 @@
 unsetopt markdirs globsubst shwordsplit nounset ksharrays
 exec </dev/null	# ZLE closes stdin, which can cause errors
 
+# Failed returns from this code are not real errors
+setopt localtraps noerrexit ; trap - ZERR
+
 local func funcs ret=1 tmp _compskip format nm call \
       _completers _completer _completer_num curtag _comp_force_list \
       _matchers _matcher _matcher_num _comp_tags _comp_mesg \

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