zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zoltan Hidvegi <hzoli@cs.elte.hu>
Cc: A.Main@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu
Subject: Re: Remaining zsh3.0-pre2 bugs
Date: Tue, 9 Jul 1996 02:08:11 -0700	[thread overview]
Message-ID: <960709020813.ZM30009@candle.brasslantern.com> (raw)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "Re: Remaining zsh3.0-pre2 bugs" (Jul  9,  3:32am)

On Jul 9,  3:32am, Zoltan Hidvegi wrote:
} Subject: Re: Remaining zsh3.0-pre2 bugs
}
} Bart and Zefram discussing a loop in get_comp_string:
} > } >Anyway, cs decrements down to 8 because of the two \230 in qword; but
} > } >"echo 'a;b'" of course has 10 characters.
} > } 
} > } Bingo.  That loop has special code for handling backslashes, but not
} > } quotes.  I think it needs to handle quotes too.
} 
} There is nothing wrong with get_comp_string here.  It works well if there
} is just one line containing embeded newlines and quotes etc.  The problem
} starts when we are in a multi-line command structure.

Er, yeah, but that seems like an odd definition of "works".

} > But that doesn't work for completions with embedded newlines, even when
} > a successful completion is possible:
} 
} It fails because zsh sees that the current word starts in the previous
} already entered line.

Where's that happening?  Not in get_comp_string() ...

} In that case zsh simply gives up the completion
} attempt, restores the original line and returns.

Why is that necessary?  Maybe it's necessary if the word *ends* in the
previous line for some reason, but ...

} Unfortunately the cursor
} position is not always restored correctly.  The patch below fixes that.

Hmm.  Your patch does a couple of things.  One, it removes the loop that
folds embedded newlines into semicolons; two, it attempts to save and
restore the cursor position.  There's one bogus compiler warning:

zle_tricky.c: In function `docomplete':
zle_tricky.c:500: warning: `ocs' might be used uninitialized in this function

I cleared this by initializing ocs = 0 in the declaration.

*** Src/zle_tricky.c.orig	1996/07/09 00:50:55 1996
--- Src/zle_tricky.c	1996/07/09 01:00:32 1996
***************
*** 497,503 ****
  docomplete(int lst)
  {
      char *s, *ol;
!     int olst = lst, chl = 0, ne = noerrs, ocs;
  
      /* If we are doing a menu-completion... */
  
--- 497,503 ----
  docomplete(int lst)
  {
      char *s, *ol;
!     int olst = lst, chl = 0, ne = noerrs, ocs = 0;
  
      /* If we are doing a menu-completion... */
  
***************

By the way, there are block-locals named ocs and ol used in various
places in docomplete(), which could lead to confusion.  I didn't try
to fix that, though.

Anyway, after the newlines-to-semicolons thing is removed, it doesn't
seem to make any difference whether (wb < 0 || we < 0 || cs < 0).  I
commented out that entire if(){} block, and was then able to complete
file names containing embedded newlines just fine.  So do you see any
problem with the following patch, which moves that block to after the
completion is attempted (thus fixing up failure cases)?

*** Src/zle_tricky.c.orig	Tue Jul  9 00:50:55 1996
--- Src/zle_tricky.c	Tue Jul  9 01:58:06 1996
***************
*** 573,592 ****
  	viinsbegin = ztrsub((char *) line + wb, (char *) line);
      /* If we added chline to the line buffer, reset the original contents. */
      if (ol) {
! 	cs -= chl;
  	wb -= chl;
  	we -= chl;
- 	if (wb < 0 || we < 0 || cs < 0) {
- 	    strcpy((char *) line, ol);
- 	    ll = strlen((char *) line);
- 	    cs = ocs;
- 	    unmetafy_line();
- 	    return;
- 	}
- 	ocs = cs;
  	cs = 0;
  	foredel(chl);
! 	cs = ocs;
      }
      freeheap();
      /* Save the lexer state, in case the completion code uses the lexer *
--- 573,584 ----
  	viinsbegin = ztrsub((char *) line + wb, (char *) line);
      /* If we added chline to the line buffer, reset the original contents. */
      if (ol) {
! 	int tcs = (cs -= chl);
  	wb -= chl;
  	we -= chl;
  	cs = 0;
  	foredel(chl);
! 	cs = tcs;
      }
      freeheap();
      /* Save the lexer state, in case the completion code uses the lexer *
***************
*** 740,745 ****
--- 732,742 ----
  	    /* Just do completion. */
  	    docompletion(s, lst, lincmd);
  	zsfree(s);
+     }
+     if (ol && !nmatches && (wb < 0 || we < 0 || cs < 0)) {
+ 	strcpy((char *) line, ol);
+ 	ll = strlen((char *) line);
+ 	cs = ocs;
      }
      /* Reset the lexer state, pop the heap. */
      lexrestore();

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



  reply	other threads:[~1996-07-09  9:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-06 22:59 Huy Le
1996-07-07  5:29 ` Bart Schaefer
1996-07-07  5:53 ` Bart Schaefer
1996-07-07  7:07   ` Bart Schaefer
1996-07-07  6:08 ` Bart Schaefer
1996-07-07  9:06   ` Zefram
1996-07-08  0:48 ` Zoltan Hidvegi
1996-07-08  4:22   ` Bart Schaefer
1996-07-08  6:21     ` Bart Schaefer
1996-07-08  7:57       ` Zefram
1996-07-08  8:48         ` Bart Schaefer
1996-07-09  1:32           ` Zoltan Hidvegi
1996-07-09  9:08             ` Bart Schaefer [this message]
1996-07-09 14:06               ` Zoltan Hidvegi
1996-07-10 19:11                 ` Bart Schaefer
1996-07-10 19:48                   ` Zoltan Hidvegi
1996-07-11  0:04                     ` Bart Schaefer
1996-07-11 12:16                       ` Zoltan Hidvegi
1996-07-11 16:45                         ` Bart Schaefer
1996-07-08 14:28     ` Zoltan Hidvegi
1996-07-08  6:38   ` Bart Schaefer
1996-07-11  8:11 ` Peter Stephenson
1996-07-11 12:51   ` Redirection bug fix 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=960709020813.ZM30009@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=A.Main@dcs.warwick.ac.uk \
    --cc=hzoli@cs.elte.hu \
    --cc=schaefer@nbn.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).