zsh-workers
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayne@clari.net>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: segv with :_correct or :_correct:_approximate
Date: Sun, 6 Jun 1999 19:48:50 -0700 (PDT)	[thread overview]
Message-ID: <Pine.GSO.4.10.9906061913430.29955-100000@house.clari.net> (raw)
In-Reply-To: <199906020637.IAA27444@beta.informatik.hu-berlin.de>

On Wed, 2 Jun 1999, Sven Wischnowsky wrote:
> Wayne, this happens when freehistdata() calls removehashnode()
> with a histent with he->text==NULL.

It's actually slightly worse than that, it would have tried to free
the static "curline" structure if it had successfully free'd the
structure's data.

> (All this with HIST_NO_FUNCTIONS, it tries to remove a function
> definition from the history at that time.)

Yes, this is the meat of the problem -- remhist() is being called to
remove a history line when the function definition did not come from
the history -- ouch.  (Before my history changes, the code would have
successfully lost the last history line from the internal history as
a side-effect of completing the current history line.)

So, I've got a simple fix for this particular problem (I'll post a
patch in a moment), but I think in the long run we need to redesign
the "remhist()" stuff.  In addition to the problems of when the
remhist() function should be called and when it shouldn't, the new
SHARE_HISTORY code writes out a history line to the history file
right after you type it, and it cannot easily remove the line post
facto if the code later decides to call remhist().

I'm thinking that it would be best if we could identify the lines
that shouldn't be added to the history file before we save them,
rather than removing them afterwards.  I see two possible ways to do
this.  Either come up with a way to identify the non-saved commands
earlier, or move the history-saving later.

One solution might be to implement a pattern-matching system (an
array of regular expressions?) that would identify the lines that
should not be remembered.  The existing history-removing options
(including HIST_IGNORE_SPACE) would be implemented using this
system.  This would allow the current history-saving code to avoid
ever adding these lines to the history in the first place, and would
not be affected by things like the defining of functions in
completion scripts.  (This would also allow someone to easily add a
pattern to ignore short commands -- e.g.  /^..?$/).

..wayne..


  reply	other threads:[~1999-06-07  2:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-02  6:37 Sven Wischnowsky
1999-06-07  2:48 ` Wayne Davison [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-06-02  5:02 F. G. Marx

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.10.9906061913430.29955-100000@house.clari.net \
    --to=wayne@clari.net \
    --cc=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).