* Re: PATCH: Re: History bug (Re: Completion debugging)
@ 2000-05-04 11:40 Sven Wischnowsky
0 siblings, 0 replies; 6+ 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] 6+ messages in thread
* 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; 6+ 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] 6+ messages in thread
* Re: PATCH: Re: History bug (Re: Completion debugging)
2000-05-04 15:34 Sven Wischnowsky
@ 2000-05-04 17:39 ` Bart Schaefer
2000-05-04 20:55 ` Wayne Davison
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2000-05-04 17:39 UTC (permalink / raw)
To: zsh-workers
On May 4, 5:34pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: History bug (Re: Completion debugging)
}
} 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).
Cf. "The one icky bit" in my "Dear old literal history" message.
} 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.
That's approximately what "print -z" does. At least for _complete_debug,
the whole point is to get them into the history while you can still scroll
around and look at them.
Unfortunately that means either putting them into the future history or
changing the event number of the current command. Neither works, at
least not easily, because the history is now stored as a ring rather
than as a simple linked list. Wayne, are you out there?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Re: History bug (Re: Completion debugging)
2000-05-04 17:39 ` Bart Schaefer
@ 2000-05-04 20:55 ` Wayne Davison
0 siblings, 0 replies; 6+ messages in thread
From: Wayne Davison @ 2000-05-04 20:55 UTC (permalink / raw)
To: Bart Schaefer, zsh-workers
> Neither works, at
> least not easily, because the history is now stored as a ring rather
> than as a simple linked list. Wayne, are you out there?
It was always (that I know of) a ring. I just changed it from being an
array (of pointers) into being a linked list (so that it was easy to remove
items from the middle).
I'd be glad to check into this sometime tonight (unless someone beats me to
it).
..wayne..
^ permalink raw reply [flat|nested] 6+ 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; 6+ 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] 6+ messages in thread* Re: PATCH: Re: History bug (Re: Completion debugging)
2000-05-03 7:07 Sven Wischnowsky
@ 2000-05-03 16:57 ` Bart Schaefer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2000-05-03 16:57 UTC (permalink / raw)
To: zsh-workers
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 ...
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-05-04 20:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04 11:40 PATCH: Re: History bug (Re: Completion debugging) Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
2000-05-04 15:34 Sven Wischnowsky
2000-05-04 17:39 ` Bart Schaefer
2000-05-04 20:55 ` Wayne Davison
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).