Zsh Mailing List Archive
Messages sorted by:
Re: Shift-Insert overwrites ZLE CUTBUFFER
- X-seq: zsh-workers 39963
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER
- Date: Thu, 17 Nov 2016 17:53:55 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1479401636; bh=bDWty8DScaqLS8a4mjLbVQhLBZ/c5U00O/ff6uQDj/M=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=ofw/PraveKD1x6BeZdivgbHfLDQ0TMpHH2B1MVTOT5mWKqQfKnjPAPHRm6lBiFofVBgzDfdyx7WbgLP4VUrklA1zxeoAMKDais3XyUasDo4QxpoxQg2U4niR2anWYTZEnqHIQ2fenDi6IijMD2Mc11VvVc6Ji40M8kRByX+GNTt3kNyGHwCoWYm7zh3OU0s8pXxzSYPJ348cTPl+OMSfgdMzhmKtktbvUhP9EDKLtIPa9hn6BLKpYLJAFGYO3xIs+bu3vxwDz/j2FhGDNbNSK6HQpqU5zRIN7X1md/UlLuEx8BBrE5QUf131bCsuzhM9bSF1EWsPRl26sEm6M6BSiA==
- In-reply-to: <161115140723.ZM11274@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAMtVo_PG_fd62V1FZ4r7fRUragzzS6H4McN5sO1=hhY=6DR6Yg@mail.gmail.com> <161025091249.ZM7232@torch.brasslantern.com> <CAMtVo_N6qOQr++Amzn11+m3pkOxjc908mwFUerur77+OWd92uw@mail.gmail.com> <161026090133.ZM11120@torch.brasslantern.com> <CAMtVo_P09j6fyJytA21iu_qOom6bCTvJEWn-dXTBX97Bp00Sdg@mail.gmail.com> <161026165138.ZM12130@torch.brasslantern.com> <firstname.lastname@example.org> <161027133523.ZM15655@torch.brasslantern.com> <email@example.com> <CGME20161031160350epcas3p4849616fbcc05783a9966320a28ed731c@epcas3p4.samsung.com> <firstname.lastname@example.org> <161109092745.ZM2477@torch.brasslantern.com> <email@example.com> <161110091736.ZM20932@torch.brasslantern.com> <firstname.lastname@example.org> <161115140723.ZM11274@torch.brasslantern.com>
On 10 Nov, Bart wrote:
> emacs. So yes, emacs does have a whole suite of register operations,
> none of which are present in zsh (which in fairness was based on a
Would it be useful to add some of those operations given that it
might share much of the existing code that's there for vi (given a
Coming back to the original point of this thread, would it make
sense to instead put the bracketed-paste text in a register? (g)Vim's
nearest equivalents are "* for the X selection, "+ for secondary
selection and "~ which allows drag and drop. I wonder that if we
want "*, it'd be better handled by allowing external commands like
xclip, xsel or pbcopy to be hooked in. Maybe "~ then? Emacs allows
basically any character to be used for a register which wouldn't
really allow for any special ones unless we ignore that.
With the paste in a register, we might want at least the emacs
insert-register widget along with copy-to-register. Frustratingly,
emacs' insert-register leaves the cursor to the left of the inserted
text making it less suitable as i_Ctrl-R in vim.
Both emacs and vi use the registers for storing macros. I don't
really miss macros in zsh (and have bound q to something else) but
bash has them. Storing a POINT is analagous to a vi mark. In zsh,
I find vi marks are mostly useful for bookmarking history lines and
it'd seem reasonable to offer that for emacs mode too. marks are
stored separately from buffers but I'm not sure that the separate
namespace would really matter.
> change them. As a thought, could use the terms "killring buffer" for
> 1-9 and "register buffer" for a-z, when updating documentation.
I quite like that. Would mean that anyone searching for either register
or buffer would find what they're looking for.
> (Although it's possible to expand the killring to more than 9 elements
> by assigning directly to the variable.)
> Aside: If the numbered registers duplicate $killring, how is it there
> are 9 numbered registers but the killring defaults to only 8 elements?
Actually it seems the numbered vi buffers are quite separate from the
killring and there are slightly different rules about what goes into
them. So I should probably put the numbered registers in the registers
special parameter after all.
> 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
That makes sense. Thanks
Messages sorted by: