Re: New behaviour for HIST_IGNORE_SPACE option

Re: New behaviour for HIST_IGNORE_SPACE option

[Bart Schaefer]

[Moved to -workers]

On Jun 19, 11:52pm, Vincent Lefevre wrote:
} Subject: New behaviour for HIST_IGNORE_SPACE option
}
} It seems that the behaviour of HIST_IGNORE_SPACE has changed in
} zsh 4.0.1, and I don't like the new one.

Sorry to have let this languish so long without a reply.  We did think
about putting an option in for the old behavior and it's mostly my fault
that there isn't one.

In the course of considering possible workarounds, I discovered that the
new behavior has in fact introduced a few bugs.  If you use `print -s'
between commands -- e.g., from precmd, or from completion as happens
with _complete_debug -- while there is a history entry pending space-
deletion, the history becomes garbled:  The entry that was added with
`print -s' appears twice, once on either side of the one that should
have been deleted, and the deletion never happens.

It seems to me that `print -s' should simply perform the deletion at
once, replacing the pending entry with the new one.

On a prossibly-unrelated note, `print -s' with no arguments results in
"BUG: attempt to free storage at invalid address" when the next command
is executed:

schaefer[514] print -s
schaefer[517] echo foo
BUG: attempt to free storage at invalid address
foo
schaefer[519] allopt hist
appendhistory         on
banghist              on
cshjunkiehistory      off
extendedhistory       off
histallowclobber      off
histbeep              on
histexpiredupsfirst   on
histfindnodups        on
histignorealldups     off
histignoredups        on
histignorespace       off
histnofunctions       off
histnostore           off
histreduceblanks      on
histsavenodups        off
histverify            off
incappendhistory      off
sharehistory          off


Wayne, are you out there?

-- 
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: New behaviour for HIST_IGNORE_SPACE option

[Wayne Davison]

On Tue, 26 Jun 2001, Bart Schaefer wrote:
> It seems to me that `print -s' should simply perform the deletion at
> once, replacing the pending entry with the new one.

Yes, it should.  Here's a patch.

..wayne..

---8<------8<------8<------8<---cut here--->8------>8------>8------>8---
Index: Src/hist.c
--- Src/hist.c	2001/06/08 00:15:18	1.29
+++ Src/hist.c	2001/06/28 18:05:47
@@ -922,6 +922,10 @@

     if (curline_in_ring)
 	unlinkcurline();
+    if (hist_ring && hist_ring->flags & HIST_TMPSTORE) {
+	curhist--;
+	freehistnode((HashNode)hist_ring);
+    }

     if (histlinect < histsiz) {
 	he = (Histent)zcalloc(sizeof *he);
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---

print -s ''

[Bart Schaefer]

On Jun 26,  I wrote:
}
} It seems to me that `print -s' should simply perform the deletion at
} once, replacing the pending entry with the new one.

Wayne's patch for this appears (after a lot of experimentation in which
I confused myself several times) to have done the right thing.  Thanks,
Wayne.
 
} On a prossibly-unrelated note, `print -s' with no arguments results in
} "BUG: attempt to free storage at invalid address" when the next command
} is executed

This bug is also gone.

However, `print -s' with no arguments or an empty argument still inserts an
empty entry in the history list.  Does this seem like useful behavior to
anyone?  I would think that empty entries should always be ignored.

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