Re: vi editting troubles

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

[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

[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 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:

> 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

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

[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

[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: 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: 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

[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

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