Re: ZLE and handling of MARK

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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