Re: vi editting troubles

Re: vi editting troubles

[Paul Ackersviller]

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

64-bit sparc instructions

[Bart Schaefer]

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   

Re: vi editting troubles

[Bart Schaefer]

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   

Re: vi editting troubles

[Sven Wischnowsky]

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

Re: 64-bit sparc instructions

[Andrej Borsenkow]

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

Re: vi editting troubles

[Peter Stephenson]

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.
**********************************************************************

Re: 64-bit sparc instructions

[Clint Adams]

> } By replacing the latter with the former, the test [succeeds].

Did I imply that?  What I meant was that it didn't help.

Re: 64-bit sparc instructions

[Clint Adams]

> 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'

Re: vi editting troubles

[Wayne Davison]

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..

Re: vi editting troubles

[Bart Schaefer]

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.

Re: vi editting troubles

[Sven Wischnowsky]

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

PATCH: Re: vi editting troubles

[Sven Wischnowsky]

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

Re: vi editting troubles

[Bart Schaefer]

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   

Re: vi editting troubles

[Sven Wischnowsky]

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

Re: vi editting troubles

[Bart Schaefer]

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   

Re: vi editting troubles

[nce]

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

Re: vi editting troubles

[Peter Stephenson]

> 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.
**********************************************************************