zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Weird bug with approximate completion
Date: Thu, 4 Mar 1999 11:18:13 +0100 (MET)	[thread overview]
Message-ID: <199903041018.LAA02437@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Thu, 04 Mar 1999 10:35:05 +0100


Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> >   sticking it after the first slash will make the completion code use
> >   `/users/foo/(#a...)bin/comp' as the expanded prefix and make it
> >   search in that directory -- which doesn't exists, so it will
> >   generate no matches; should we have some special casing in the
> >   C-code or in the shell code here?
> 
> I don't really understand this since I don't know at what point it hasn't
> been treated as a pattern when it should have been.

When doing pattern completion with a pathname the completion code
still looks only at the pathname component the cursor is in. So it
will split the word into `~/(#a...)/bin/comp' and the prefix
`set'. The it tries to get the real path for the first one and that
gets expanded to `/users/foo/(#a...)/bin/comp', with the `(#a...)'
still in place. Later it uses this path to generate possible matches
by trying to open the directory and reading it. But since there is no
directory with a weird name like `...(#a..)...' it can't open it and
produces no matches.

> > I couldn't reproduce your bug, though (and for me the line you quoted
> > is line number 6239).
> 
> It's now moved to line 6238.  I've fixed the symptoms by turning the
> ncalloc() into a zhalloc(), which I shouldn't have to do, but can't hurt
> since the memory is never freed so it should be using zhalloc() anyway.
> This suggests something fairly sinister is going on.  ncalloc() appears to
> be pointing to the right thing, but the wrong argument appears when it's
> called.

Maybe we should put the test below into tricky.c. One of the things on 
my list is sticking several calls to `DPUTS' in there anyway...

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Mar  4 10:59:54 1999
+++ Src/Zle/zle_tricky.c	Thu Mar  4 11:15:13 1999
@@ -5930,6 +5930,8 @@
     if (incompfunc != 1 && findnode(ccstack, cc))
 	return;
 
+    MUSTUSEHEAP("complistflags");
+
     addlinknode(ccstack, cc);
 
     if (incompfunc != 1 && allccs) {

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


             reply	other threads:[~1999-03-04 10:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-04 10:18 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-03-03 16:19 Sven Wischnowsky
1999-03-04  9:35 ` Peter Stephenson
1999-03-03 14:54 Peter Stephenson

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=199903041018.LAA02437@beta.informatik.hu-berlin.de \
    --to=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).