Making Viper state global - vim

EmacsWiki says:
There is a way to make Viper state and Viper insert state global, like in Vim (and probably vi). In Vim (and probably vi), you start in Normal Mode. You can switch buffer, and Vim stays in Normal Mode. Pressing “i” puts Vim in Insert Mode. Then if you switch buffers by clicking on another window, Vim stays in Insert Mode. You don’t have to remember which buffer is in what mode, you only need to remember in which mode Vim is.
But unfortunately, they don't say what this method is, and I couldn't find it quickly. Does anybody know?

I don't know a single setting or package to do what you want. It's not provided by viper itself.
That said, you can write some advice which does the job. The key being that you need to advise all the ways you switch buffers/windows. For example, if you switch windows through the other-window command (C-x o), you'll want this:
(defadvice other-window (around other-window-maintain-viper-state activate
activate)
"when switching windows, pull the viper-current-state along"
(let ((old-window-state viper-current-state))
ad-do-it
(viper-change-state old-window-state)))
But, switching windows using the mouse doesn't go through that function, and to get that to work you need to advise select-window in exactly the same way:
(defadvice select-window (around select-window-maintain-viper-state activate
activate)
"when switching windows, pull the viper-current-state along"
(let ((old-window-state viper-current-state))
ad-do-it
(viper-change-state old-window-state)))
If you find you use another mechanism to switch windows/buffers that doesn't use the above, it just takes a tiny bit of digging (M-x describe-key ) to find out what new thing you should be advising.

Related

Avoiding paste content to be executed in normal mode in Neovim/WSL/ConEmu

I've started using Neovim on Windows/WSL through ConEmu. It all works pretty amazingly except one pretty major flaw:
When I paste content into Neovim and forget to enter insert mode before, Neovim will register the input as keyboard strokes and execute them as commands. Needlessly to say, this can get pretty ugly, pretty fast.
A contrived example for clarity: I need to copy some text from my browser. The text in question is "sp" (yes, this is completely stupid, but bear with me). As I paste this into ConEmu (CTRL-V), the terminal transfers the input to Neovim that parses it as commands because it's in normal mode. In this example Neovim will replace whatever character is at the cursor at the time with p.
Vim for Windows has this solved and will paste the content without changing mode (how does a pure Linux environment handle this?). The problem with that solution is that it is dependent on the Windows file system which is a lot harder to tweak/maintain compared to apt-get/Ubuntu/WSL as well other annoyances.
So, initially I thought I'd try to make Neovim detect if the input was directly from the keyboard and not any other source, if it was, switch to insert mode and handle it from there. But I'm frankly not sure if this is even possible (especially though WSL). I also tried to add a shortcut that makes Neovim enter insert mode on CTRL-V in the hopes that is would trigger first and then correctly paste the content.
Maybe I need another terminal than ConEmu?
Anyway, I'm out of ideas, hope you guys can help.
ConEmu shall not detect any "internal" modes of the application you run in the terminal. Actually, when you "paste" something, terminal does almost the same thing if you press same keys manually.
Well, except one major difference: ConEmu uses "bracketed paste mode", so the console application may determine if user paste something or press keys manually.
So, it's the question to Neovim how to process/configure bracketed paste mode inside it.
In ConEmu settings, Keys & Marco -> Paste
There is an option:
Multi-line paste: avoid unexpected command execution by < Enter >
keypress
That's what you need.

How to map normal mode to modifier key on keyboard in vim (say Alt)?

I want to make my workflow in vim a little bit faster for me, by working all the time in insert mode, with executing normal mode commands(keybindings), when I hold some modifier key, say alt.
So, for example, I'm currently in insert mode and I want to call undo command, instead of typing <Esc> <u> <i>, I want to type <Alt>+<u>, and return to insert mode immediately.
I know, you can map all your mappings via imap/inoremap explicitly for every insert mode mapping, but I want to map ALL the normal mode mappings, even those used in my plugins, and this is too much work. Also, I know there's <Ctrl>+<o> command to execute only one command in normal mode with returning to starting mode right after, but I want to be able to execute any number of commands in insert mode, not just one, and not to execute any, if I just hold <Alt> key (or any modifier I set for this behavior) and then release, not switching to normal mode.
P.S. if someone heard about vim-clutch, I want to make the same, not buying extra one pedal for release event, having only one pedal.
thx.
Well, I found solution by myself already - this blog post describes all in depth via using libusb gem.

Vim: Is it possible to bind a key to open search (i.e. put me in the command mode having entered a slash, but do not type anything)

While vim's way of doing things is generally good, I feel like there are aspects that really get in the way as somebody who is not completely committed to vim for text-editing.
This means that I am hitting Esc+/ and typing slashes into files in Sublime Text, and hitting Ctrl+F in vim, scrolling down a page.
Similar things happen with Ctrl+S and :w and custom mapping ; to : still doesn't make it as convenient and fail-safe as Ctrl+S. Not to mention in PuTTY, Ctrl+S does something rather upsetting (it suspends output from the terminal till Ctrl+Q is pressed). Basically, IMHO some things (like switching to a "find mode" and saving the file) are good to attach to a global left-hand home-row shortcut chord rather than requiring the user to mess about in a modal command line. It simply is too often used to subject the user to these mode changes. I suppose this isnt a legitimate complaint because the entirety of vim is constructed around the modal concept, and these functionalities are a result of that.
In any case I'd like to make it a bit easier on my brain because I've tried for a while now to keep it all intact and it's simply too much (I have more or less internalized the switching between Ctrl on a windows machine on a desktop keyboard and the use of the thumb for the Cmd on my Macbook, but this modal text editor business seems to be too much). It did not take too much deliberation for me to decide that global homerow key chords are simply more intuitive.
Mapping Ctrl+S to :w is trivial, so the question here is about the find mode. I want to bind Ctrl+F to put me in find mode, but repeating it should not type slashes into the find command. Can this be done? Is there perhaps a colon-command that when executed simply drops me into the current find-command-buffer-thing?
In your .vimrc add:
inoremap <C-f> <Esc>/
noremap <C-f> <Esc>/
In whatever mode you are in, this will put you in "find" mode (it actually just types a slash in the command line which you can use to search). With these bindings it will work for all modes, even if you are in insert mode.
do you want this?
nnoremap <c-f> /
if you like you can also try
nnoremap <c-f> q/
the 2nd mapping brings you to a search history window. you could choose previous search keywords/patterns. also available to type new pattern (by pressing i)
btw, there is no find mode
Mappings can be defined separately for the different modes in Vim, see :help map-modes. This automatically takes care of your proposed <C-f> mapping: Initially, you're in normal mode, then the search pattern is entered in command-line mode.
If you so far only occasionally use Vim, and find it too "different", several things may make the switch easier:
easy Vim (evim or vim -y) defaults to insert mode
on Windows, :behave mswin and the $VIMRUNTIME/mswin.vim script create some common Windows shortcuts
graphical GVIM has menu items like Edit > Find... and toolbars.
Some things like the flow-control freeze on <C-s> in terminals are unfortunate, mostly historical accidents; you can't blame Vim for those.
You don't need to map anything. / is expressive enough and is definitely not slower than <C-f>. Same for <C-s> which, despite a certain familiarity, is not much better than :w<CR>. You are learning a new tool, remember?
What you should focus your efforts on is getting confortable with Vim's modality. The simple fact that, for you, doing a search involves hitting <Esc> is a sign that you didn't get that part. Your other comments on using Vim shortcuts in ST and ST shortcut in Vim are not good signs either and the part where you complain about having to adjust to your Mac's Cmd is the icing on the cake, IMO.
It may sound brutal but, from your question, it seems like you are doing too much at the same time, without organization and for, probably, no good reasons.
Switching from Windows to Mac OS X and switching from ST2 to Vim at the same time is sure to be confusing and I suggest you slow down a little and make a choice before you loose your mind and waste more of your time.
Which leads me to this: Why do you use a Mac and why are you using Vim?
Windows is a fine OS. Sublime is a fine editor. Even if you switch to the Mac, Sublime works very well there. So Why Vim?
If you are tired by some Sublime limitations and want the awesome power of Vim, fine. But you must wrap your head around its modality and awkwardness and accept to change your habit.
If you don't approach Vim with more flexibility, you'll never get full benefits.
If you decided to use Vim because it is trendy, I'll respectfully suggest you to stop there and go back to Sublime. Vim is weird, Vim is different, Vim is huge, Vim is a rabbit hole… if you are not ready to work with it and insist on not accepting its core design, you won't get far so why bother? You can pretty much live all your professional carreer without ever touching Vim. There's no shame in that.
Remapping / to <C-f>, on the other hand…

Vim (terminal) - copy to x clipboard and paste while suspeneded

I have vimx installed, so I can copy in vimx to the x clipboard by using "+y and the like, which works well as long as I can keep the current vimx running.
However, I also love to be able to switch to the current running shell with ctrl-z and be able to paste what I copied from vim into the shell. Does anyone know how to do this, because as soon as I suspend vim with ctr-z the x-clipboard becomes empty, until I put vim into the fg again.
ok,
After about an hour of head bashing this issue, I have decided to use a different approach to do the same thing.
I will detail what I did here for the benefit of those with the same issue.
If you have wxcopy on your system that is enough to get copy/paste support on your system between vim and other apps. If you want to copy from vim, select the text using v or V or whatever method you prefer, then use the command :tee >(wxcopy). This will copy that code into the oldschool X11 cut buffer. This buffer has the added bonus of not requiring the parent application to be running for pasting to work, hence my problem goes away.
I realize it may be hard to get your hands on wxcopy, under fedora the package that provides it is:
WindowMaker
This isn't an answer as much as a push in the right direction, but start here:
:help quoteplus
:help x11-cut-buffer
Specifically the second help text has some interesting notes about suspending vim. It claims to write the buffer into PRIMARY and CUT_BUFFER0 so you can still use middle click after you've suspended. Maybe you've deleted those or a plugin is interfering? Maybe you are running an old version of vim (I'm running 7.2.182).
My suggestion is to disable all plugins you've manually installed and try vanilla vim. If that doesn't work, consider using vim's -V (verbose) flag and see if it will try to put the buffer into PRIMARY or CUT_BUFFER0 before it actually gets suspended.
I don't have vim compiled with X (vimx) so I can't actually test this myself. Hopefully that gets you in the right direction.

Readline's vi-mode in vim ex mode

Let's see if I can explain myself.
I use vi-mode in bash, which is really great since I'm used to Vi.
When I'm inside vim and type : (to go to ex mode), since I'm used to the vi-mode from bash, I feel the slowliness of having to use this mode like the "regular" way of using bash.
Question is: is there a way of using vim's ex-mode like bash's (or readline) vi-mode?
Not sure if I understand what you're trying to do, but it might be something like hitting q: in normal mode?
For users that use Vim or vi bindings almost everywhere, including on their shell command line, it really hurts when you leave that environment. If you're used to the vi bindings hyperdrive, going back to chords for skipping words and other manoeuvres is painful and slow. Operating systems also differ on their default bindings so Mac, for instance, supports option-arrow instead of control-arrow, adding to the pain.
But there is one place where this also happens where it's really upsetting: in Vim itself. When working in Vim and entering command mode using : the default readline editing returns. Chords all over again. How to fix this?
Simple: When in "normal" mode, that is, when navigating around, type q:
Vim will drop you at the bottom of a full Vim full screen editing experience, go for your life
Additionally the command history is available on previous lines in the buffer
You can yank and paste lines and edit the commands as much as you wish
To execute a command in "command" or "ex" mode just hit ENTER on the line you want to execute
Hitting enter on an empty line closes the buffer and does nothing
But this is just another buffer so you can quit it as usual with :q as well
Although ESC leaves the "ex" command line, ESC in the buffer will not leave the buffer, because it's an actual buffer
The q prefix is used to introduce macro recording, so the q: variant is perfectly mnemonic for entering recording of an "ex" command line.
Note that q: to enter the buffer editing mode is very similar to :q ! You may have hit that by accident sometimes ;-) Now you know how to get out of it!
Zigdon had this answer a long time ago, of course, but it's pretty darn sparse, but then again, so is the question. If Zigdon adds this extra detail to his answer I'll be happy to delete this answer so that there can be one good answer.

Resources