From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id KAA20161 for ; Thu, 11 Jul 1996 10:10:47 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA12393; Wed, 10 Jul 1996 20:04:50 -0400 (EDT) Resent-Date: Wed, 10 Jul 1996 20:04:50 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960710170410.ZM5312@candle.brasslantern.com> Date: Wed, 10 Jul 1996 17:04:08 -0700 In-Reply-To: Zoltan Hidvegi "Re: Remaining zsh3.0-pre2 bugs" (Jul 10, 9:48pm) References: <199607101948.VAA29276@bolyai.cs.elte.hu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.702 02jul96) To: Zoltan Hidvegi Subject: Re: Remaining zsh3.0-pre2 bugs Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"LkCEC1.0.W13.TK4vn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1602 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jul 10, 9:48pm, Zoltan Hidvegi wrote: } Subject: Re: Remaining zsh3.0-pre2 bugs } } > } The problem is that that: } > } } > } % echo 'z'\ } > } > l } > } } > } Here get_comp_string removes the quotes around 'z' but it does not work } > } since the already entered part cannot be modified. The quotes have to be } > } removed for completing filenames. This later causes a SEGV. } > } > Well, then, why not catch that special case (backslash-newline) and let } > other cases of embedded newlines keep working? Patch below. } } It did not study your patch too much so perhaps I just do not see something } obvious but I do not understand what is this wb < (oll - ll) check? get_comp_string() computes a "wrong" value for wb, we, and cs when the completed form of a word contains fewer characters than the original. That happens with backslash-newline, because "a\\\nb" becomes "ab" when parsed. I may be following this wrong -- I'm not very familiar with the completion code -- but I think the seg fault results when wb or one of the others is decremented not just past the embedded newline (wb < 0), but back farther than the beginning of the previous line. } But not only backslash-newline is the problem. It was just an example. } Try completing after } } % echo '*** } > ***' } } Does it work with your patch? Here makecomplist() wants to modify the } line. Define "work". If I type tab immediately after the closing quote, it feeps and the line is not changed. I believe that's because of the hunk at the end of my patch, `if (ol && !nmatches && (wb < 0 ...))', which restores the old line after discovering that the completion failed. However, I now see that I didn't consider the case of completion after something unusual like: % *\ > * This can still end up writing to (*(line - 3)) in makecomplist(). I'm beginning to think the problem is not with completion per se, but with expansion (and therefore with compctls that use -U). Also, nmatches is never set with expansions, so my `if (ol && !nmatches ...)' test isn't accurate if expansion is all that occurs. } And even in that case completion is possible after } executing push-line-or-edit. It is seems that it's not easy to correctly } handle this special and it does not worth it since it occurs very rarely. OK; I give up, for now. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"