From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6199 invoked from network); 5 Oct 2000 16:58:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Oct 2000 16:58:56 -0000 Received: (qmail 22227 invoked by alias); 5 Oct 2000 16:58:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12904 Received: (qmail 22220 invoked from network); 5 Oct 2000 16:58:40 -0000 From: "Bart Schaefer" Message-Id: <1001005165822.ZM23943@candle.brasslantern.com> Date: Thu, 5 Oct 2000 16:58:21 +0000 In-Reply-To: <200010050818.KAA12655@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: ZLE and handling of MARK" (Oct 5, 10:18am) References: <200010050818.KAA12655@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: ZLE and handling of MARK MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 5, 10:18am, Sven Wischnowsky wrote: } } Bart Schaefer wrote: } } > If one sets the mark in zle and then delete characters to the left } > of it by assigning to a slice of $BUFFER in a user-defined widget, } > the mark remains in the same numeric position rather than the same } > logical position. } } The only `secure' change I can see is to update the position of the } mark if it is in $RBUFFER and only $LBUFFER is changed. We perhaps should have forseen this problem with editing by assignment rather than by function (builtin command) call. Really, I suppose, an assignment to (|L|R)BUFFER should clear the mark entirely, and should be documented to do so ... and do what, with CURSOR ...? Hmm, is there perhaps some way that we could detect assignment to a slice (e.g. BUFFER[x,y]=...) and automatically recompute the mark based on the endpoints of the slice? Assigning to the entire variable would be treated like assigning to BUFFER[1,-1], which would probably end up moving both the mark and the cursor to the end of the buffer; assigning to LBUFFER is like assigning to BUFFER[1,$#LBUFFER], etc. All we need is to be able to hook into the slice range. The advantage here is that if one really did want to preserve the numeric MARK and CURSOR across the assignment, all that's necessary is to declare them "local +h". } > If one sets the mark and then moves around in the history, the mark stays } > at the same numeric position in each recalled line } } It's a bit like emacs' line-movement, isn't it? Not really. The position of the cursor is like emacs' line-movement, but: } (I always thought the mark should be either attached to a history line } so that exchange-p-a-m would toggle between lines *That* would be like emacs' line-movement; but since you can't actually do editing operations (like copy-region) across multiple history lines, I suppose that behavior doesn't make much sense for zle. } or it should be per-line. Maybe.) That the mark is global is very convenient for things like searches on a common prefix of history lines (see Functions/Zle/history-search-end). Without that, the widget function would have to make use of global non- special shell parameters (as it did before MARK existed). So I guess the conclusion is that the current behavior does make as much sense as anything else. -- 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