Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 15, 10:41pm, Oliver Kiddle wrote:
} Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER
}
} On 10 Nov, Bart wrote:
} > A useful addition to zsh/zleparameter would be a special hash of
} > register-to-content mappings (emacs calls this register-alist).
} 
} The following patch adds this under the name "registers" [...]
} For what it's worth, I think the term
} "registers" is better than "buffers" and it'd be good to use the same
} ones with emacs style widgets.

I don't have any particular quibble with this, except that the names
of the vi-widgets all refer to "buffers" and it would be annoying to
change them.  As a thought, could use the terms "killring buffer" for
1-9 and "register buffer" for a-z, when updating documentation.

(Although it's possible to expand the killring to more than 9 elements
by assigning directly to the variable.)

} What does the "alist" part of the emacs name denote.

For practical purposes, it means the same as ${(kv)registers} after
your patch:  a list of alternating key-value elements.

} It contains just the registers 'a' to 'z' for now. Including the
} numbered registers would just be a duplication of killring/CUTBUFFER.
} (except the yank register - "0).

Aside: If the numbered registers duplicate $killring, how is it there
are 9 numbered registers but the killring defaults to only 8 elements?

} Why does makezleparams set pm->level to locallevel + 1? That seems
} wrong. What does the + 1 achieve?

The parameters are created before the function for any user-defined
widget is called, but are defined as being local to the scope of the
user-defined widget.  Or at least that's my understanding, it's been
a while since I walked through the flow.  Anyway, the point is that
the ZLE parameters hide (rather than refer to) any existing parameter
of the same name, and are always local.