* Re: vi editting troubles @ 2001-05-23 3:04 Paul Ackersviller 2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer 2001-05-23 6:28 ` vi editting troubles Bart Schaefer 0 siblings, 2 replies; 17+ messages in thread From: Paul Ackersviller @ 2001-05-23 3:04 UTC (permalink / raw) To: Peter Stephenson, Bart Schaefer; +Cc: zsh-workers Bart Schaefer wrote: > > } > Does a command such as `echo =(echo foo)' work? That should use the same > > } > temp file mechanism as fc. > > } > > } % echo =(echo foo) > > } Segmentation fault (core dumped) > > > > Looks like you've got some sort of serious memory allocation problem > > going on -- probably some kind of word-alignment issue -- with the heap > > allocation code. You're going to have to give us details of your OS and > > build environment. Did you configure with --enable-zsh-mem? No, I didn't configure with --enable-zsh-mem, but it turns out not to make a difference. What does make a difference is simply generating default 32-bit sparc instructions. I'd negelected to mention that I was using Sun's compiler and 64-bit code. I suppose it's fair to blame this one on Sun. Peter Stephenson wrote: > > Another strange thing I notice when I turn on shell tracing is that my > > TRAPZERR function runs in the middle of _history_complete_word -- is > > there something I should be doing to avoid this? > > Oh, yuk. We really need some way of getting the effect of `setopt > localtraps; unfunction TRAPZERR' in all completion functions. I suppose > that means adding it everywhere we already have `setopt localoptions' > or `emulate -L zsh' (the latter already sets localtraps). If anybody sees > this as their mission in life... Are you saying this is still a potential problem in a general sense? If it helps to know, _history_complete_word no longer shows me any errors and this behaviour goes away with Bart's suggestion of moving `bindkey -v' after `compinit'. You could document this as a bug, but how can you ensure people always use this ordering? -- Paul Ackersviller ^ permalink raw reply [flat|nested] 17+ messages in thread
* 64-bit sparc instructions 2001-05-23 3:04 vi editting troubles Paul Ackersviller @ 2001-05-23 4:41 ` Bart Schaefer 2001-05-23 9:38 ` Andrej Borsenkow 2001-05-23 12:29 ` Clint Adams 2001-05-23 6:28 ` vi editting troubles Bart Schaefer 1 sibling, 2 replies; 17+ messages in thread From: Bart Schaefer @ 2001-05-23 4:41 UTC (permalink / raw) To: Paul Ackersviller; +Cc: zsh-workers On May 22, 8:04pm, Paul Ackersviller wrote: } } [...] What does make a difference is simply generating default 32-bit } sparc instructions. I'd negelected to mention that I was using Sun's } compiler and 64-bit code. I suppose it's fair to blame this one on Sun. Is that problem solved by the following? On May 22, 2:32pm, Clint Adams wrote: } Subject: Re: 4.0.1-pre-5 (solaris issues) } } > the 64-bit Forte compiler. Can you figure out what we need to be passing } > as a compiler argument that we aren't, or whatever? } } LFS64_CFLAGS: -D_LARGEFILE64_SOURCE } LFS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 } } By replacing the latter with the former, the test [succeeds]. If so, can you identify a configure test we can use to decide when to use LFS64_CFLAGS instead of LFS_CFLAGS ? (The existing test is in the definition of zsh_LARGE_FILE_SUPPORT in aczsh.m4.) -- 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] 17+ messages in thread
* Re: 64-bit sparc instructions 2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer @ 2001-05-23 9:38 ` Andrej Borsenkow 2001-05-23 16:42 ` Clint Adams 2001-05-23 12:29 ` Clint Adams 1 sibling, 1 reply; 17+ messages in thread From: Andrej Borsenkow @ 2001-05-23 9:38 UTC (permalink / raw) To: zsh-workers; +Cc: Paul Ackersviller On Wed, 23 May 2001, Bart Schaefer wrote: > On May 22, 8:04pm, Paul Ackersviller wrote: > } > } [...] What does make a difference is simply generating default 32-bit > } sparc instructions. I'd negelected to mention that I was using Sun's > } compiler and 64-bit code. I suppose it's fair to blame this one on Sun. > > Is that problem solved by the following? > > On May 22, 2:32pm, Clint Adams wrote: > } Subject: Re: 4.0.1-pre-5 (solaris issues) > } > } > the 64-bit Forte compiler. Can you figure out what we need to be passing > } > as a compiler argument that we aren't, or whatever? > } > } LFS64_CFLAGS: -D_LARGEFILE64_SOURCE > } LFS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > } > } By replacing the latter with the former, the test [succeeds]. > > If so, can you identify a configure test we can use to decide when to > use LFS64_CFLAGS instead of LFS_CFLAGS ? (The existing test is in the > definition of zsh_LARGE_FILE_SUPPORT in aczsh.m4.) > > Hmm ... they both have very different semantic. LFS means, use existing interfaces but assume some parameters are 64 bit (off_t, size_t, ino_t to name some). LFS64 means - you are explicitly using special 64-bit version of these interfaces (open64 vs. open, stat64 vs. stat etc) that are using special types (off64_t, ino64_t etc). Zsh is not designed to do it. So, if the above change really helped, it was just because zsh was actually compiled in 32-bit mode :-) We simply need better detection if LFS really works. Could you provide testcase suitable for putting in configure? -andrej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 64-bit sparc instructions 2001-05-23 9:38 ` Andrej Borsenkow @ 2001-05-23 16:42 ` Clint Adams 0 siblings, 0 replies; 17+ messages in thread From: Clint Adams @ 2001-05-23 16:42 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: zsh-workers, Paul Ackersviller > So, if the above change really helped, it was just because zsh was > actually compiled in 32-bit mode :-) We simply need better detection if > LFS really works. Could you provide testcase suitable for putting in > configure? Incidentally, I have the same problems with --disable-lfs. I'd be more inclined to blame this on the compiler, but trying 64-bit compilation on an UltraSPARC III running Debian and gcc version 3.0 20010426 (Debian prerelease), and statically-linking: cd Test ; make check make[1]: Entering directory `/tmp/obj/Test' if test -n "gcc-3.0 -mcpu=ultrasparc -m64"; then \ cd .. && \ make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \ fi for f in ../../zsh-4.0.1-pre-5/Test/*.ztst; do \ ../Src/zsh +Z -f ../../zsh-4.0.1-pre-5/Test/ztst.zsh $f; \ done ../../zsh-4.0.1-pre-5/Test/A01grammar.ztst: starting. This test hangs the shell when it fails... ../../zsh-4.0.1-pre-5/Test/A01grammar.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/A02alias.ztst: starting. ../../zsh-4.0.1-pre-5/Test/A02alias.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/A03quoting.ztst: starting. ../../zsh-4.0.1-pre-5/Test/A03quoting.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/A04redirect.ztst: starting. ../../zsh-4.0.1-pre-5/Test/A04redirect.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/A05execution.ztst: starting. ../../zsh-4.0.1-pre-5/Test/A05execution.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/B01cd.ztst: starting. ../../zsh-4.0.1-pre-5/Test/B01cd.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/C01arith.ztst: starting. ../../zsh-4.0.1-pre-5/Test/C01arith.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/C02cond.ztst: starting. ../../zsh-4.0.1-pre-5/Test/C02cond.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/C03traps.ztst: starting. This test takes at least three seconds... This test, too, takes at least three seconds... ../../zsh-4.0.1-pre-5/Test/C03traps.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/C04funcdef.ztst: starting. ../../zsh-4.0.1-pre-5/Test/C04funcdef.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/D01prompt.ztst: starting. ../../zsh-4.0.1-pre-5/Test/D01prompt.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/D02glob.ztst: starting. *** /tmp/zsh.ztst.out.10870 Wed May 23 16:32:13 2001 --- /tmp/zsh.ztst.tout.10870 Wed May 23 16:32:13 2001 *************** *** 101,107 **** 1: [[ BAR = (bar|(#i)foo) ]] 0: [[ FOO = (bar|(#i)foo) ]] 0: [[ Modules = (#i)*m* ]] ! 0: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]] 1: [[ FOOGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]] 0: [[ readme = (#i)readme~README|readme ]] 0: [[ readme = (#i)readme~README|readme~README ]] --- 101,108 ---- 1: [[ BAR = (bar|(#i)foo) ]] 0: [[ FOO = (bar|(#i)foo) ]] 0: [[ Modules = (#i)*m* ]] ! 1: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]] ! Test failed: [[ fooGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]] 1: [[ FOOGRUD = (#i)(bar|(#I)foo|(#i)rod)grud ]] 0: [[ readme = (#i)readme~README|readme ]] 0: [[ readme = (#i)readme~README|readme~README ]] *************** *** 151,154 **** 1: [[ path/testy = *((#s)|/)test((#e)|/)* ]] 1: [[ path/testy/ohyes = *((#s)|/)test((#e)|/)* ]] 1: [[ path/atest/ohyes = *((#s)|/)test((#e)|/)* ]] ! 0 tests failed. --- 152,155 ---- 1: [[ path/testy = *((#s)|/)test((#e)|/)* ]] 1: [[ path/testy/ohyes = *((#s)|/)test((#e)|/)* ]] 1: [[ path/atest/ohyes = *((#s)|/)test((#e)|/)* ]] ! 1 tests failed. Test ../../zsh-4.0.1-pre-5/Test/D02glob.ztst failed: output differs from expected as shown above for: globtest globtests Was testing: zsh globbing ../../zsh-4.0.1-pre-5/Test/D02glob.ztst: test failed. ../../zsh-4.0.1-pre-5/Test/D03procsubst.ztst: starting. ../../zsh-4.0.1-pre-5/Test/D03procsubst.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/D04parameter.ztst: starting. ../../zsh-4.0.1-pre-5/Test/D04parameter.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/D05array.ztst: starting. ../../zsh-4.0.1-pre-5/Test/D05array.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/D06subscript.ztst: starting. ../../zsh-4.0.1-pre-5/Test/D06subscript.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/E01options.ztst: starting. ../../zsh-4.0.1-pre-5/Test/E01options.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/E02xtrace.ztst: starting. ../../zsh-4.0.1-pre-5/Test/E02xtrace.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/V01zmodload.ztst: starting. Warning: zsh/example not linked: not checking autoloading ../../zsh-4.0.1-pre-5/Test/V01zmodload.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/V02zregexparse.ztst: starting. ../../zsh-4.0.1-pre-5/Test/V02zregexparse.ztst: all tests successful. ../../zsh-4.0.1-pre-5/Test/Y01completion.ztst: starting. Test ../../zsh-4.0.1-pre-5/Test/Y01completion.ztst failed: non-zero status from preparation code: comptestinit -z $ZTST_testdir/../Src/zsh ../../zsh-4.0.1-pre-5/Test/Y01completion.ztst: test failed. ../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst: starting. Test ../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst failed: non-zero status from preparation code: comptestinit -z $ZTST_testdir/../Src/zsh ../../zsh-4.0.1-pre-5/Test/Y02compmatch.ztst: test failed. ../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst: starting. Test ../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst failed: bad status 1, expected 0 from: tst_arguments ':desc1:(arg1)' comptest $'tst \t\C-wa\t\C-war\t\C-warg\t\C-warg1\t\C-wr\t\C-wx\t \ty \t' Error output: comptesteval:4: command not found: zpty comptesteval:5: command not found: zpty comptest:2: command not found: zpty comptest:3: command not found: zpty Was testing: one non-option argument ../../zsh-4.0.1-pre-5/Test/Y03arguments.ztst: test failed. rm -rf Modules .zcompdump make[1]: Leaving directory `/tmp/obj/Test' ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: 64-bit sparc instructions 2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer 2001-05-23 9:38 ` Andrej Borsenkow @ 2001-05-23 12:29 ` Clint Adams 1 sibling, 0 replies; 17+ messages in thread From: Clint Adams @ 2001-05-23 12:29 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers > } By replacing the latter with the former, the test [succeeds]. Did I imply that? What I meant was that it didn't help. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 3:04 vi editting troubles Paul Ackersviller 2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer @ 2001-05-23 6:28 ` Bart Schaefer 2001-05-23 7:08 ` Sven Wischnowsky 1 sibling, 1 reply; 17+ messages in thread From: Bart Schaefer @ 2001-05-23 6:28 UTC (permalink / raw) To: Paul Ackersviller; +Cc: zsh-workers On May 22, 8:04pm, Paul Ackersviller wrote: } Subject: Re: vi editting troubles } } Peter Stephenson wrote: } > > Another strange thing I notice when I turn on shell tracing is that my } > > TRAPZERR function runs in the middle of _history_complete_word -- is } > > there something I should be doing to avoid this? } > } > Oh, yuk. We really need some way of getting the effect of `setopt } > localtraps; unfunction TRAPZERR' in all completion functions. } } Are you saying this is still a potential problem in a general sense? Yes. The completion functions use a non-zero return value to report various conditions (often as simple as that no completions were found). The ZERR trap triggers on every such "failure". In _main_complete, which is called e.g. when you press TAB, there is code to fix up three different potential problems: (1) The completion functions assume a particular collection of setopts, so a call is made to initialize them properly. (2) ZLE closes stdin when running a widget. This confuses some external commands, so _main_complete redirects from /dev/null. (3) Turn off ZERR trapping. However, there are several functions that are called as completion widgets without passing through _main_complete; _history_complete_word is one. We did a sweep through them and took care of item (1) everywhere, but items (2) and (3) were not always caught. It isn't always necessary to do anything about (2), but it appears it is always necessary to handle (3). The only question is whether to sweep the functions again, or figure out some centralized way to fix it for good. } If it helps to know, _history_complete_word no longer shows me any } errors That's only because you aren't actually invoking _history_complete_word any more. } and this behaviour goes away with Bart's suggestion of moving } `bindkey -v' after `compinit'. You could document this as a bug, but } how can you ensure people always use this ordering? We can't ensure it, which is why I directed a question to zsh-workers about the reason for the choice of keybindings. I'm a bit surprised that no one spoke up. -- 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] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 6:28 ` vi editting troubles Bart Schaefer @ 2001-05-23 7:08 ` Sven Wischnowsky 2001-05-23 9:42 ` Peter Stephenson 2001-05-23 18:18 ` Wayne Davison 0 siblings, 2 replies; 17+ messages in thread From: Sven Wischnowsky @ 2001-05-23 7:08 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > ... > > We can't ensure it, which is why I directed a question to zsh-workers > about the reason for the choice of keybindings. I'm a bit surprised that > no one spoke up. It wasn't me this time, but I think Adam modelled it after some Emacs key bindings? About the init code stuff: I could do that, I'm just not sure which way we should go. Repeating everything in every function is just too ugly. Putting it into the C-code is the opposite of what I wanted to achieve -- and I want to try to keep the basic C-code independent of the way the completion system shell code is written. So, I would prefer a solution that allows us to add just a bit of code to the top level shell functions which sets everything up. Be it an array (so that we would add a line like `$_init_comp' to the functions) or an alias or -- somewhat uglier because the setopt localoptions has to be called separately -- a initialisation function to call. I think we had a bit of discussion about this before when we added the _comp_options array. But I have been very busy this week and didn't find the time to look it up (and I'll be away from tomorrow till (not including) monday, so everybody will have the possibility to be faster in solving this than me). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 7:08 ` Sven Wischnowsky @ 2001-05-23 9:42 ` Peter Stephenson 2001-05-23 18:18 ` Wayne Davison 1 sibling, 0 replies; 17+ messages in thread From: Peter Stephenson @ 2001-05-23 9:42 UTC (permalink / raw) To: zsh-workers Sven Wischnowsky wrote: > Bart Schaefer wrote: > > > ... > > > > We can't ensure it, which is why I directed a question to zsh-workers > > about the reason for the choice of keybindings. I'm a bit surprised that > > no one spoke up. > > It wasn't me this time, but I think Adam modelled it after some Emacs > key bindings? Esc-/ is based on dabbrev-expand in Emacs. It's obviously not a very useful binding in vi mode. Either we need to change to default binding or make it possible to pick different default bindings for different modes. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 7:08 ` Sven Wischnowsky 2001-05-23 9:42 ` Peter Stephenson @ 2001-05-23 18:18 ` Wayne Davison 2001-05-23 19:31 ` Bart Schaefer 1 sibling, 1 reply; 17+ messages in thread From: Wayne Davison @ 2001-05-23 18:18 UTC (permalink / raw) To: Sven Wischnowsky; +Cc: zsh-workers On Wed, 23 May 2001, Sven Wischnowsky wrote: > Repeating everything in every function is just too ugly. > Putting it into the C-code is the opposite of what I wanted to achieve -- > and I want to try to keep the basic C-code independent of the way the > completion system shell code is written. An off-the-cuff suggestion: Would it be possible to have the C code call a "set completion defaults" shell function, store these default values, and then automatically restore them before any call out to the completion system? Would that accomplish your desired goal of keeping the C-code independent? ..wayne.. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 18:18 ` Wayne Davison @ 2001-05-23 19:31 ` Bart Schaefer 2001-05-29 6:59 ` Sven Wischnowsky 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 2001-05-23 19:31 UTC (permalink / raw) To: zsh-workers On May 23, 11:18am, Wayne Davison wrote: > > An off-the-cuff suggestion: Would it be possible to have the C code > call a "set completion defaults" shell function The problem with any shell-function-based solution is that it requires a special case for the `localoptions' setting. Better, perhaps, would be to augment the _comp_options variable with a _comp_setup variable, which would look something like this: _comp_setup='setopt ${_comp_options[@]} localtraps; exec </dev/null; trap - ZERR' and then `eval' that variable in any function that is an entry point into the completion system. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-23 19:31 ` Bart Schaefer @ 2001-05-29 6:59 ` Sven Wischnowsky 2001-05-29 11:57 ` PATCH: " Sven Wischnowsky 0 siblings, 1 reply; 17+ messages in thread From: Sven Wischnowsky @ 2001-05-29 6:59 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > On May 23, 11:18am, Wayne Davison wrote: > > > > An off-the-cuff suggestion: Would it be possible to have the C code > > call a "set completion defaults" shell function > > The problem with any shell-function-based solution is that it requires a > special case for the `localoptions' setting. > > Better, perhaps, would be to augment the _comp_options variable with a > _comp_setup variable, which would look something like this: > > _comp_setup='setopt ${_comp_options[@]} localtraps; > exec </dev/null; > trap - ZERR' > > and then `eval' that variable in any function that is an entry point into > the completion system. Hm, not one reply so far (unless I've missed something). This is of course better than what I suggested in 14449 because I always forget about eval. I'd even volunteer to make that change... or is anyone really against it? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: Re: vi editting troubles 2001-05-29 6:59 ` Sven Wischnowsky @ 2001-05-29 11:57 ` Sven Wischnowsky 2001-05-29 14:58 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Sven Wischnowsky @ 2001-05-29 11:57 UTC (permalink / raw) To: zsh-workers I wrote: > Bart Schaefer wrote: > > > On May 23, 11:18am, Wayne Davison wrote: > > > > > > An off-the-cuff suggestion: Would it be possible to have the C code > > > call a "set completion defaults" shell function > > > > The problem with any shell-function-based solution is that it requires a > > special case for the `localoptions' setting. > > > > Better, perhaps, would be to augment the _comp_options variable with a > > _comp_setup variable, which would look something like this: > > > > _comp_setup='setopt ${_comp_options[@]} localtraps; > > exec </dev/null; > > trap - ZERR' > > > > and then `eval' that variable in any function that is an entry point into > > the completion system. > > Hm, not one reply so far (unless I've missed something). > > This is of course better than what I suggested in 14449 because I always > forget about eval. I'd even volunteer to make that change... or is > anyone really against it? Here it is. There are still some functions in Base/Widget that don't eval $_comp_setup but they either call _main_complete later or something entirely different anyway (and use emulate -L or some such), so I wasn't sure if we should use it there, too. Some part of my brain says yes, other parts say no or `for some...'. Bye Sven Index: Completion/compinit =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/compinit,v retrieving revision 1.4 diff -u -r1.4 compinit --- Completion/compinit 2001/04/29 19:12:14 1.4 +++ Completion/compinit 2001/05/29 11:54:54 @@ -139,7 +139,18 @@ NO_cshnullglob NO_allexport NO_aliases + NO_errexit ) + +# And this one should be `eval'ed at the beginning of every entry point +# to the completion system. It sets up what we currently consider a +# sane environment. That means we set the options above, make sure we +# have a valid stdin descriptor (zle closes it before calling widgets) +# and don't get confused by user's ZERR trap handlers. + +_comp_setup='setopt localoptions localtraps ${_comp_options[@]}; + exec </dev/null; + trap - ZERR' # These can hold names of functions that are to be called before/after all # matches have been generated. Index: Completion/Base/Completer/_expand_alias =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_expand_alias,v retrieving revision 1.1 diff -u -r1.1 _expand_alias --- Completion/Base/Completer/_expand_alias 2001/04/02 11:06:52 1.1 +++ Completion/Base/Completer/_expand_alias 2001/05/29 11:54:54 @@ -2,7 +2,7 @@ local word expl tmp pre sel what -setopt localoptions ${_comp_options[@]} +eval "$_comp_setup" if [[ -n $funcstack[2] ]]; then if [[ "$funcstack[2]" = _prefix ]]; then Index: Completion/Base/Core/_main_complete =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_main_complete,v retrieving revision 1.1 diff -u -r1.1 _main_complete --- Completion/Base/Core/_main_complete 2001/04/02 11:03:18 1.1 +++ Completion/Base/Core/_main_complete 2001/05/29 11:54:54 @@ -16,12 +16,7 @@ # which makes the output of setopt and unsetopt reflect a different # state than the global one for which you are completing. -setopt localoptions ${_comp_options[@]} - -exec </dev/null # ZLE closes stdin, which can cause errors - -# Failed returns from this code are not real errors -setopt localtraps noerrexit ; trap - ZERR +eval "$_comp_setup" local func funcs ret=1 tmp _compskip format nm call match min max i num\ _completers _completer _completer_num curtag _comp_force_list \ Index: Completion/Base/Widget/_bash_completions =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_bash_completions,v retrieving revision 1.1 diff -u -r1.1 _bash_completions --- Completion/Base/Widget/_bash_completions 2001/04/02 11:14:07 1.1 +++ Completion/Base/Widget/_bash_completions 2001/05/29 11:54:54 @@ -25,7 +25,7 @@ # that will not have been overridden, so you should add '~' to the # list of keys at the top of the for-loop. -setopt localoptions ${_comp_options[@]} +eval "$_comp_setup" local key=$KEYS[-1] expl Index: Completion/Base/Widget/_complete_debug =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_complete_debug,v retrieving revision 1.1 diff -u -r1.1 _complete_debug --- Completion/Base/Widget/_complete_debug 2001/04/02 11:14:23 1.1 +++ Completion/Base/Widget/_complete_debug 2001/05/29 11:54:54 @@ -1,8 +1,6 @@ #compdef -k complete-word \C-x? -setopt localoptions ${_comp_options[@]} - -setopt localtraps noerrexit ; trap - ZERR +eval "$_comp_setup" (( $+_debug_count )) || integer -g _debug_count local tmp=${TMPPREFIX}${$}${words[1]:t}$[++_debug_count] Index: Completion/Base/Widget/_complete_help =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_complete_help,v retrieving revision 1.1 diff -u -r1.1 _complete_help --- Completion/Base/Widget/_complete_help 2001/04/02 11:14:40 1.1 +++ Completion/Base/Widget/_complete_help 2001/05/29 11:54:54 @@ -1,9 +1,7 @@ #compdef -k complete-word \C-xh _complete_help() { - setopt localoptions ${_comp_options[@]} - - exec </dev/null # ZLE closes stdin, which can cause errors + eval "$_comp_setup" local _sort_tags=_help_sort_tags text i j k tmp typeset -A help_funcs help_tags help_sfuncs help_styles Index: Completion/Base/Widget/_correct_word =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_correct_word,v retrieving revision 1.1 diff -u -r1.1 _correct_word --- Completion/Base/Widget/_correct_word 2001/04/02 11:15:29 1.1 +++ Completion/Base/Widget/_correct_word 2001/05/29 11:54:54 @@ -7,7 +7,7 @@ # If configurations keys with the prefix `correctword_' are # given they override those starting with `correct_'. -setopt localoptions ${_comp_options[@]} +eval "$_comp_setup" local curcontext="$curcontext" Index: Completion/Base/Widget/_expand_word =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_expand_word,v retrieving revision 1.1 diff -u -r1.1 _expand_word --- Completion/Base/Widget/_expand_word 2001/04/02 11:15:46 1.1 +++ Completion/Base/Widget/_expand_word 2001/05/29 11:54:54 @@ -2,7 +2,7 @@ # Simple completion front-end implementing expansion. -setopt localoptions ${_comp_options[@]} +eval "$_comp_setup" local curcontext="$curcontext" Index: Completion/Base/Widget/_history_complete_word =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_history_complete_word,v retrieving revision 1.1 diff -u -r1.1 _history_complete_word --- Completion/Base/Widget/_history_complete_word 2001/04/02 11:16:19 1.1 +++ Completion/Base/Widget/_history_complete_word 2001/05/29 11:54:54 @@ -15,7 +15,7 @@ # range -- range of history words to complete _history_complete_word () { - setopt localoptions ${_comp_options[@]} + eval "$_comp_setup" local expl direction stop curcontext="$curcontext" Index: Completion/Base/Widget/_next_tags =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_next_tags,v retrieving revision 1.1 diff -u -r1.1 _next_tags --- Completion/Base/Widget/_next_tags 2001/04/02 11:16:51 1.1 +++ Completion/Base/Widget/_next_tags 2001/05/29 11:54:54 @@ -3,7 +3,7 @@ # Main widget. _next_tags() { - setopt localoptions ${_comp_options[@]} + eval "$_comp_setup" local ins ops="$PREFIX$SUFFIX" -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-29 11:57 ` PATCH: " Sven Wischnowsky @ 2001-05-29 14:58 ` Bart Schaefer 2001-05-30 7:19 ` Sven Wischnowsky 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 2001-05-29 14:58 UTC (permalink / raw) To: zsh-workers On May 29, 1:57pm, Sven Wischnowsky wrote: } Subject: PATCH: Re: vi editting troubles } } > Bart Schaefer wrote: } > } > > _comp_setup='setopt ${_comp_options[@]} localtraps; } > > exec </dev/null; } > > trap - ZERR' } > > } > > and then `eval' that variable in any function that is an entry point into } > > the completion system. } } Here it is. There are still some functions in Base/Widget that don't } eval $_comp_setup but they either call _main_complete later or something } entirely different anyway (and use emulate -L or some such), so I wasn't } sure if we should use it there, too. Some part of my brain says yes, } other parts say no or `for some...'. I think anything that eventually calls _main_complete can be left alone as long as the surrounding code deals properly with ksh_arrays and the set of globbing options. -- 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] 17+ messages in thread
* Re: vi editting troubles 2001-05-29 14:58 ` Bart Schaefer @ 2001-05-30 7:19 ` Sven Wischnowsky 0 siblings, 0 replies; 17+ messages in thread From: Sven Wischnowsky @ 2001-05-30 7:19 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > ... > > I think anything that eventually calls _main_complete can be left alone as > long as the surrounding code deals properly with ksh_arrays and the set of > globbing options. Yes. While looking again, I found the things in the patch below. That comment was serverely out of date and in these functions we don't need to eval _comp_setup (we didn't need to set the options there either which was what I replaced with the `eval's), because they only set up $curcontext and call _main_complete. Bye Sven Index: Completion/Base/Widget/_correct_word =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_correct_word,v retrieving revision 1.2 diff -u -r1.2 _correct_word --- Completion/Base/Widget/_correct_word 2001/05/29 11:59:51 1.2 +++ Completion/Base/Widget/_correct_word 2001/05/30 07:15:44 @@ -3,11 +3,6 @@ # Simple completion front-end implementing spelling correction. # The maximum number of errors is set quite high, and # the numeric prefix can be used to specify a different value. -# -# If configurations keys with the prefix `correctword_' are -# given they override those starting with `correct_'. - -eval "$_comp_setup" local curcontext="$curcontext" Index: Completion/Base/Widget/_expand_word =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Base/Widget/_expand_word,v retrieving revision 1.2 diff -u -r1.2 _expand_word --- Completion/Base/Widget/_expand_word 2001/05/29 11:59:51 1.2 +++ Completion/Base/Widget/_expand_word 2001/05/30 07:15:44 @@ -2,8 +2,6 @@ # Simple completion front-end implementing expansion. -eval "$_comp_setup" - local curcontext="$curcontext" if [[ -z "$curcontext" ]]; then -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20010521121334.A24931@flora01.SLAC.Stanford.EDU>]
* Re: vi editting troubles [not found] <20010521121334.A24931@flora01.SLAC.Stanford.EDU> @ 2001-05-21 19:43 ` Peter Stephenson [not found] ` <010521132805.ZM11030@candle.brasslantern.com> 1 sibling, 0 replies; 17+ messages in thread From: Peter Stephenson @ 2001-05-21 19:43 UTC (permalink / raw) To: Paul Ackersviller, Zsh hackers list > Neither `r' or `fc -e -' work, and give me this error. > fc: can't open temp file: bad address Do you have TMPPREFIX set to something invalid? The chunk of code in question is this. The questions are whether we need to make gettempname() more robust about this, and why to goodness the system has decided to set errno to EFAULT instead of ENOENT, which would make the error message rather more understandable. fil = gettempname(); if (((tempfd = open(fil, O_WRONLY | O_CREAT | O_EXCL | O_NOCTTY, 0600)) == -1) || ((out = fdopen(tempfd, "w")) == NULL)) { unqueue_signals(); zwarnnam("fc", "can't open temp file: %e", NULL, errno); } > Another strange thing I notice when I turn on shell tracing is that my > TRAPZERR function runs in the middle of _history_complete_word -- is > there something I should be doing to avoid this? Oh, yuk. We really need some way of getting the effect of `setopt localtraps; unfunction TRAPZERR' in all completion functions. I suppose that means adding it everywhere we already have `setopt localoptions' or `emulate -L zsh' (the latter already sets localtraps). If anybody sees this as their mission in life... -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <010521132805.ZM11030@candle.brasslantern.com>]
* Re: vi editting troubles [not found] ` <010521132805.ZM11030@candle.brasslantern.com> @ 2001-05-22 1:53 ` nce 2001-05-22 2:31 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: nce @ 2001-05-22 1:53 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On Mon, May 21, 2001 at 01:28:05PM -0700, Bart Schaefer wrote: > > Neither `r' or `fc -e -' work, and give me this error. > > fc: can't open temp file: bad address > > What's the value of $TMPPREFIX ? This error means either that zsh is > really not able to open a file, or that it opened the file [with open(2)] > but then failed to create a FILE* object for it [fdopen(3)]. TMPPREFIX=/tmp/zsh -- I don't think I've ever touched it. > Does a command such as `echo =(echo foo)' work? That should use the same > temp file mechanism as fc. % echo =(echo foo) Segmentation fault (core dumped) (dbx) where [1] strlen(0x0, 0x201388, 0x74c200000, 0x7efefeff, 0x81010100, 0x6), at 0xffffffff7ed4027c =>[2] ztrdup(s = 2102152 ""), line 52 in "string.c" [3] getoutputfile(cmd = 4297069232 "\x8b\x88echo foo"), line 2816 in "exec.c" [4] prefork(list = 4297069160, flags = 1), line 64 in "subst.c" [5] execcmd(state = 18446744071562065736, input = 0, output = 0, how = 18, last1 = 2), line 1742 in "exec.c" [6] execpline2(state = 18446744071562065736, pcode = 259U, how = 18, input = 0, output = 0, last1 = 0), line 1189 in "exec.c" [7] execpline(state = 18446744071562065736, slcode = 4098U, how = 18, last1 = 0), line 982 in "exec.c" [8] execlist(state = 18446744071562065736, dont_change_job = 0, exiting = 0), line 826 in "exec.c" [9] execode(p = 4297069056, dont_change_job = 0, exiting = 0), line 729 in "exec.c" [10] loop(toplevel = 1, justonce = 0), line 160 in "init.c" [11] zsh_main(argc = 1, argv = 18446744071562066680), line 1209 in "init.c" [12] main(argc = 1, argv = 18446744071562066680), line 37 in "main.c" > > Secondly, searching through my history fails as well. This one's a > > bit hard to describe, but it seems to be picking a work from the last > > command without even waiting for me to input something to search for. > > Anyway, the workaround is to initialize the completion system (compinit) > in your startup files before you set up vi key bindings (bindkey -v). Thanks Bart, you're right, that does work for me. -- Paul Ackersviller ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vi editting troubles 2001-05-22 1:53 ` nce @ 2001-05-22 2:31 ` Bart Schaefer 0 siblings, 0 replies; 17+ messages in thread From: Bart Schaefer @ 2001-05-22 2:31 UTC (permalink / raw) To: paulda; +Cc: zsh-workers On May 21, 6:53pm, nce@SLAC.Stanford.EDU wrote: } Subject: Re: vi editting troubles } } > Does a command such as `echo =(echo foo)' work? That should use the same } > temp file mechanism as fc. } } % echo =(echo foo) } Segmentation fault (core dumped) Looks like you've got some sort of serious memory allocation problem going on -- probably some kind of word-alignment issue -- with the heap allocation code. You're going to have to give us details of your OS and build environment. Did you configure with --enable-zsh-mem? -- 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] 17+ messages in thread
end of thread, other threads:[~2001-05-30 7:20 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-05-23 3:04 vi editting troubles Paul Ackersviller 2001-05-23 4:41 ` 64-bit sparc instructions Bart Schaefer 2001-05-23 9:38 ` Andrej Borsenkow 2001-05-23 16:42 ` Clint Adams 2001-05-23 12:29 ` Clint Adams 2001-05-23 6:28 ` vi editting troubles Bart Schaefer 2001-05-23 7:08 ` Sven Wischnowsky 2001-05-23 9:42 ` Peter Stephenson 2001-05-23 18:18 ` Wayne Davison 2001-05-23 19:31 ` Bart Schaefer 2001-05-29 6:59 ` Sven Wischnowsky 2001-05-29 11:57 ` PATCH: " Sven Wischnowsky 2001-05-29 14:58 ` Bart Schaefer 2001-05-30 7:19 ` Sven Wischnowsky [not found] <20010521121334.A24931@flora01.SLAC.Stanford.EDU> 2001-05-21 19:43 ` Peter Stephenson [not found] ` <010521132805.ZM11030@candle.brasslantern.com> 2001-05-22 1:53 ` nce 2001-05-22 2:31 ` 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).