zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: Re: History bug (Re: Completion debugging)
@ 2000-05-04 15:34 Sven Wischnowsky
  2000-05-04 17:39 ` Bart Schaefer
  0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-04 15:34 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> Bart Schaefer wrote:
>
> ...
>
> > 
> > So there are still two 113s in the history list, but the prompt has the
> > right history number.  I'm expecting that particular shell to crash any
> > time now ...
> 
> I get a SEGV reproducibly after C-p C-n. If I take out my patch for
> this, I get it after the C-p.
> 
> Hm, maybe someone more knowledgeable with history stuff...?

After playing some more and a couple of SEGVs later...

There is so much mucking around curhist (and histline) in zle that I
wonder if there is a clean way (other than changing the meaning of
curhist in the core and then adapting zle).

Maybe we should just make `print -s' put the strings added while zle
is active into some list and then add those strings only after zle is
left? I.e. in a toplevel-loop() or somewhere around that.


Bye
 Sven


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


^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: PATCH: Re: History bug (Re: Completion debugging)
@ 2000-05-04 11:40 Sven Wischnowsky
  0 siblings, 0 replies; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-04 11:40 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> On May 3,  9:07am, Sven Wischnowsky wrote:
> } Subject: PATCH: Re: History bug (Re: Completion debugging)
> }
> } > Why are there two of numbers 24, 29 and 32?  In each case, the first of the
> } > two was inserted by calling "print -s ..." during completion.  Apparently
> } > that doesn't work very well.
> } 
> } Of course this isn't only in completion, but in every widget.
> } 
> } The problem is that the history number for the currently edited line
> } is `reserved' and the `print -s' makes it be used. The patch below is
> } the simplest solution I can think of.
> 
> OOOooh, this is fun.
> 
> Change the "print -zR" in _complete_debug to "print -sR", and then:
> 
> zagzig[112] ls <C-x?>
> Debugging output left in /tmp/zsh13117ls3
> (listing omitted)
> zagzig[112] ls <C-n>
> zagzig[112] emacs /tmp/zsh13117ls3 ;: "ls -CF "<C-p>
> zagzig[112] ls <wait a few minutes, then RET>
> (listing omitted)
> zagzig[114] history -d
>   113  09:48  emacs /tmp/zsh13117ls3 ;: "ls -CF "
>   113  09:51  ls
> zagzig[115] 
> 
> So there are still two 113s in the history list, but the prompt has the
> right history number.  I'm expecting that particular shell to crash any
> time now ...

I get a SEGV reproducibly after C-p C-n. If I take out my patch for
this, I get it after the C-p.

Hm, maybe someone more knowledgeable with history stuff...?

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 7+ messages in thread
* PATCH: Re: History bug (Re: Completion debugging)
@ 2000-05-03  7:07 Sven Wischnowsky
  2000-05-03 16:57 ` Bart Schaefer
  0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-03  7:07 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> Look at this snippet of "history" output:
> 
>    21  cd zsh-3.1.6
>    22  setup_compinit
>    24  emacs /tmp/zsh149find1 ;: find\ -
>    24  history
>    25  emacs /tmp/zsh149find1 ;: find\ -
>    26  history
>    28  emacs /tmp/zsh149find2 ;: find\ 
>    29  emacs /tmp/zsh149echo3 ;: echo\ foo\ 
>    29  history
>    30  reload _complete_debug
>    32  emacs /tmp/zsh149find4 ;: 'find -'
>    32  history
> 
> Why are there two of numbers 24, 29 and 32?  In each case, the first of the
> two was inserted by calling "print -s ..." during completion.  Apparently
> that doesn't work very well.

Of course this isn't only in completion, but in every widget.

The problem is that the history number for the currently edited line
is `reserved' and the `print -s' makes it be used. The patch below is
the simplest solution I can think of.

Bye
 Sven

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.12
diff -u -r1.12 builtin.c
--- Src/builtin.c	2000/05/02 15:52:44	1.12
+++ Src/builtin.c	2000/05/03 07:07:17
@@ -2777,7 +2777,7 @@
 	int nwords = 0, nlen, iwords;
 	char **pargs = args;
 
-	ent = prepnexthistent(++curhist);
+	ent = prepnexthistent(zleactive ? curhist++ : ++curhist);
 	while (*pargs++)
 	    nwords++;
 	if ((ent->nwords = nwords)) {

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2000-05-05  7:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04 15:34 PATCH: Re: History bug (Re: Completion debugging) Sven Wischnowsky
2000-05-04 17:39 ` Bart Schaefer
2000-05-04 20:55   ` Wayne Davison
2000-05-05  7:25   ` PATCH: History bug with "print -s" Wayne Davison
  -- strict thread matches above, loose matches on Subject: below --
2000-05-04 11:40 PATCH: Re: History bug (Re: Completion debugging) Sven Wischnowsky
2000-05-03  7:07 Sven Wischnowsky
2000-05-03 16:57 ` 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).