Re: zsh widget to resolve symlinks

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

Mikel Ward wrote:
> It turns out copy-region-as-kill doesn't use killring but rather
> CUTBUFFER.  This is a little confusing!

Right, CUTBUFFER is the most recently killed, killring holds the entries
before that.  This is something of a historical curiosity.  The manual
needs to be more explicit about the link between the two.

> I'm also surprised that CUTBUFFER persists invocations of zle, yet it
> isn't set in the top-level interactive shell.

This reflects how zle works.  If you use "yank" when editing, it will
insert the last string cut or copied even if it wasn't in the current
command line, and even though zle wasn't active in the intervening period.

In recent zsh, you can hook in code to be run at the start of the line
by defining zle-line-init as a widget; however, you probably don't want
to reset CUTBUFFER because of its unexpected effect on yanking.

You can avoid using CUTBUFFER at all with something like (note I haven't
actually tried this but it shouldn't be too far out):

zle backward-word
integer pos1=$((CURSOR+1))
zle forward-word
# this will grab any whitespace at the end, too...
integer pos2=$((CURSOR))
local word="$BUFFER[$pos1,$pos2]"

and to replace the word, leaving the cursor after it,

LBUFFER="${LBUFFER[1,$pos-1]}$realpath"

If I were writing the widget, I'd probably use raw access to $BUFFER
etc. to find the start and end of the word (hence avoiding the use of
$CURSOR apart from finding out where to start), and ${(z)...} trickery
to access shell words as done in match-words-by-style (which might give
you some other ideas).

It occurred to me recently that a generic widget to split the line into
shell words and whitespace would be extremely useful, making this sort
of task much easier.  However, I haven't got around to it yet.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/