Skip to content

Should Vi mode really use its own internal clipboard? #319

Closed

Description

srdubya : Thank you for implementing Vi mode!

I got tripped up trying to use "p" to paste some text from the system clipboard. I took a look at the code, and saw that Vi mode uses its own internal clipboard (just a string member called _clipboard).

I don't anticipate ever getting register support in PSReadLine (I don't think we want an entire vi implementation inside PSReadLine), so I think it would make sense to make the system clipboard the backing store for Vi mode's yank/put operations.

What do you all think?

Activity

  1. srdubya commented on Dec 15, 2015

    @srdubya
    Contributor

    Hi Dan,

    I thought about implementing it that way but decided against it because:

    1. Git Shell does not do this, at least on my system.
    2. Lots of vi-mode commands put text into _clipboard. I figured overwriting the system clipboard while editing a command would be viewed as an undesirable side effect most of the time.

    I like it the way it is, but I'd support putting your idea behind a setting.

  2. gwojan commented on Dec 15, 2015

    @gwojan

    Dan Thompson (@jazzdelightsme), srdubya Interesting! I was just going to request that this be configurable. 😄 I too would like access to the system clipboard because I'm constantly doing the copy/paste thing from other sources into the PowerShell prompt. I always use the unnamed register in gVim/VsVim.

    With that said, I really like the the existing visual copy capability from Jason Shirk (@lzybkr). That's why I originally asked that v be changed to allow visual selection and V actually launch $env:VISUAL.

  3. lzybkr commented on Dec 15, 2015

    @lzybkr
    Contributor

    Agreed, a configuration option is a good idea. I use that setting in Vim and find it extremely useful, but it's not for everybody.

    As for registers - I could see adding them. Emacs mode has the kill ring which is similar to having multiple registers.

  4. jazzdelightsme commented on Dec 16, 2015

    @jazzdelightsme
    ContributorAuthor

    Thank you everyone for the discussion!

    srdubya : I personally don't care much what git bash does :), but item 2 alone is a good enough reason on its own to tread carefully, like putting it behind an option. When I get a chance I'll think about how registers might be implemented, unless somebody beats me to it.

  5. springcomp commented on Oct 19, 2019

    @springcomp
    Contributor

    My work on #333 currently awaiting review as PR #811 lead me to implement the internal clipboard as a register. It could then be extended for named registers fairly easily.

  6. wang-jinbo commented on Feb 1, 2021

    @wang-jinbo

    So if I want to vi mode use system clipboard instead of its own, what should I do for it?

  7. springcomp commented on Feb 1, 2021

    @springcomp
    Contributor

    @Wongboo Make vi-mode use the system clipboard is not currently supported, unfortunately.

    Not sure this would be worth it to be honest.

    One way would be to have an option, which would replace the internal clipboard and use the system clipboard.

    A better way would be to support the + register which is the standard way in vim to use the system clipboard. Thus, the user would have to type sequences like: "+yy or "+p for instance.

    Again, I’m not really sure there is a use case for it, though 🤔.

  8. daxian-dbw commented on Apr 6, 2022

    @daxian-dbw
    Member

    A better way would be to support the + register which is the standard way in vim to use the system clipboard. Thus, the user would have to type sequences like: "+yy or "+p for instance.

    I agree that would be the better way to go, if we really decide to support it.
    Given that there is no plan to support the system clipboard as a configuration and that the discussion has made it clear that using an internal clipboard is the desired design, I will close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions