When using vim in a non-English language environment, mistakes in mis-entering command often occur.
To prevent this, is there a way to view the current input source on the statusline?
For example, EN or JP.
like MS word bottom bar
Vim doesn't have that information so it can't expose it, which is not exactly a problem since your desktop environment already does.
If you really want to duplicate that information in your Vim status line, then you will have to find what external command to call, and then find a way to consume the information that doesn't slow Vim to a crawl because the status line is refreshed several times per second.
Now, your question is really two questions:
How to get the information?
How to show it in the statusline?
The answer to the first question depends on your desktop environment, which you didn't disclose. You will have to look around on your own, on more specialised forums.
The answer to the second question is irrelevant without an answer to the first one but you can look up :help 'statusline' and :help system() if you are curious.
Anyway, you already have the information in your desktop environment's menu bar/task bar/whatever, so why bother?
Vim has modes. In Normal mode where it is supposed to stay most of the time all commands consist of latin letters by default. Therefore, using OS level keyboard layout switch cannot be recommended. Instead, Vim has a feature called "keymap". Vim keymap is only active in Insert or Command-line mode never affecting the Normal mode.
So, Vim never cares what is your active keyboard layout on OS level and you won't expect an easy way showing it. On the other side, Vim keymap name is accessible either as b:keymap_name variable or %k format specifier for the statusline option. So it is pretty easy to add it.
Related
I'm posting this question largely to provide the answer I've arrived at (because I found nothing elsewhere online and see no questions asking how to do this), to hopefully save future LightTable vim users a bit of time. But I'd also like to hear about any other solutions people have found to this problem, or vim LightTable problems in general.
I've fallen in love with LightTable, but at least minimal vim support is a must before I even consider an IDE. LightTable has that. Currently, though, you're largely stuck with the default vim options and little ability to alter configuration. I would be very interested in hearing about what the future plans are in this area (you out there Chris?). Exposing a .vimrc in a local config directory, even if highly limited in functionality, would be simply awesome, but I realize its very early yet in development and largely depends on what CodeMirror can provide.
One thing I can't tolerate is having to send my pinky way up and to the left to hit the ESC key to exit insert mode. That is way too slow and requires your left fingers to leave the home row, which is never good. The way I normally handle this in vim is to map ii to exit insert mode in .vimrc. Another alternative that is there by default is to hit CTRL-[. That's better, but to me that's entering emacs chording territory and for some reason my right pinky finger almost always flubs hitting either of the bracket keys.
This is a bit of hack, but it's a tolerable work-around until better vim support comes along in LightTable/CodeMirror. I've only tested it on the latest LightTable (0.4.9), so I'm not sure how applicable it is to earlier versions (which you probably shouldn't be on anyways), or, for that matter, later versions that will come along.
There is a command option called "Vim: toggle vim mode". This turns vim on and off in an editor (or instarepl). You can bind this command to a hot-key combination via the "Settings: Change key bindings/shortcuts" command. This will open up a new tab where you can enter new key bindings on the left. The current key bindings are shown on the right.
I use SHIFT-i, within a context of :editor.keys.normal. (This means I can't use capital "I" directly in the text, but in actual practice with program editing - especially clojure - this almost never causes a problem, and if it does you can just use lower-case i and then back up and do a replace char.) This effectively makes "II" (SHIFT-i SHIFT-i) the means of exiting insert mode. The first SHIFT-i exits vim and puts you in the normal, WYSIWYG editor. The next SHIFT-i puts you back in vim, but in command mode. Voila! You've went from vim insert mode to vim command mode.
Hope this helps other LightTable vim users.
Update: I think the latest LightTable release supports this. Someone please comment if adding the following to their user.behaviors file works (user behaviors is accessible via the command pane (ctrl-space)):
[:editor :lt.plugins.vim/set-options {"enableInsertModeEscKeys" true,
"insertModeEscKeys" "jk",
"insertModeEscKeysTimeout" 200}]
Old answer:
The latest LT plugin source supports this, but has not been released yet.
To easily install it do the following:
Open your LT plugins folder, e.g. on OSX ~/Library/Application Support/LightTable/plugins/Vim/
(Optional) Save a backup of the Vim (plugin) folder somewhere else
Delete the Vim folder
Download https://github.com/LightTable/Vim/archive/master.zip
Unzip it, rename the unzipped folder to just Vim, and move/copy it to your LT Plugins folder (i.e. it is replacing the official Vim plugin that you just deleted)
Add the following options in the :editor section of your user.behaviors file:
(:lt.plugins.vim/set-options {"enableInsertModeEscKeys" true,
"insertModeEscKeys" "jk"
"insertModeEscKeysTimeout" 200})
Restart LT and you should be able to use jk (or whatever keys you set in insertModeEscKeys) to exit insert mode
CodeMirror's API is designed in such a way that it's not very complicated to add key bindings but adding support for a configuration file and extending the default key bindings to cover a larger part of Vim's feature set doesn't exactly sound like a trivial task to me. And, considering the fact that LT doesn't even have search/replace, probably something that is near the bottom of their TODO list.
That, and CodeMirror is a third party "library" on which the LT team probably doesn't have much leverage.
The question is self explanatory, but I haven't found a single resource that explains what the difference is after an hour of searching. After poking around a little bit in both, it appears that gVim and gVim easy are identical.
Gvim easy is started and locked in insert-mode (every character you type is printed like a simple notepad).
Standard gvim starts in normal mode and you have to toggle between normal/insert like all other vim.
From help:
Easy mode. Implied for |evim| and |eview|. Starts with
'insertmode' set and behaves like a click-and-type editor.
This sources the script $VIMRUNTIME/evim.vim. Mappings are
set up to work like most click-and-type editors, see
|evim-keys|. The GUI is started when available.
{not in Vi}
gVim-Easy, which is installed with gVim, has all the functionality of
normal gVim but lacks modes. This is especially useful for begginers
and people who do not want to, or do not have the time to, learn how
to use gVim. Users can benefit from gVim's superior syntax
highlighting and auto-indentation while not having to have to learn
the, often deemed complex, command set of gVim in order to edit a
simple document. It is recommended that readers of this tutorial at
least try to learn how to use gVim in normal mode, the learning curve
is steep, but, the benefits in speed and usability this confers is
worth the investment.
Read here
gVim Easy: gvim.exe -y (pass a parameter y)
gVim: gvim.exe
It seems that Insert and Replace are available modes, and command mode is missing. And at first glance it appears to have lost the ability to save a document using keystrokes - the File menu shows only ":w" for Save and without command mode, the command simply isn't there. What isn't shown however is Alt-F followed by S - this works, although also missing is the status line confirmation of the file being written.
The screens plugin turns vim into a kind of dreampie, only its a whole lot better because you have more control over what gets send even when you have multiple buffers and specific text within those buffers.
To follow my environment setup, merely install screens with vim, and then at the command line, do screen, reach the shell, then type vim in. Edit a shell script of some kind with it, then do :ScreenShell *shell type here, eg python/bash/irb* which spawns a shell below. You can use :ScreenShellSend to send the visually selected text to the shell or all of the file if none is selected.
My problem is, say I want to restart the shell that I'm running using this plugin and sending it some text. I need to do :ScreenShellFocus, call exit, and then start it up again. But then I need to be able to return to the same vim session that is directly above the shell that I'm affecting. I realize that I can use screen to just reach the vim session, but the only way I can do that now is to select it with ^a 1, which really only replaces the lower portion, the one that supposed to be the shell, with the vim buffer being edited. This is stupid because now you have vim buffer on top of vim buffer.
So my question is, how do I return the cursor to the vim session above after doing :ScreenShellFocus?
(yes I know my example of killing and restarting a shell may be circumvented by other logic, but I'm not that acquainted with the GNU screen util, and I think there's a way to do it like this, which I think preserves the workflow of the programmer)
<C-a><Tab>
is the mapping used in screen to cycle through "regions". Since you have only two, it moves the focus to the other region.
Since you are effectively using screen, you should learn how to use it to make this plugin really useful.
$ man screen
Sometimes I hit the wrong keys on my laptop's small keyboard, and odd navigation or editing occurs (sometimes a feature that's new to me).
Although I can undo the editing (u) or navigation (control-o), I don't know what I did wrong, so it's difficult to avoid it in future. It's also frustrating to not know what just happened. So, I would like to be able to see my last few keystrokes.
A bit like :set showcmd, but to show the literal keystrokes, and (ideally) a short history of them.
I've only found commandline and navigation history in help/google.
To clarify: I'm not looking for commandline history, but keystroke history. e.g. did I press ) accidentally and go to the next sentence? Did I press dd and delete a line? I guess it's similar to a keystroke logger.
Commandline history (:history) only shows commands entered at the : prompt.
A bit old, but I've just found this on reddit:
You can start vim with the -w flag to write all keystrokes in a file. See :h -w
vim -w filename
To my knowledge, the closest you can get is the q command, which records your keystrokes into a register of your choice. Obviously, that has to be set up a priori as it's intended for complex repeats, although you could probably hack something to start recording on every file open. There's the matter of memory usage and that annoying "recording" prompt though.
Probably the most straightforward way would be to install keylogging software. I don't have any personal experience with these, but the security implications are probably mild if you get it from a trustworthy source or build it yourself, set it to only log to memory not a disk, only have a buffer the size of a sentence or so, or only log for vim windows.
More recently I came across a logging plugin for Vim and it reminded me of this question:
http://wolever.net/~wolever/wiki/vim-logging
It basically records everything you do for later analysis, it was intended for getting statistics about command usage but should work perfectly for finding what those magic commands you accidentally entered were.
:history will show your command history - that should help you uncover the new features that we all uncover in vim with misplaced keystrokes.
Gundo - Is probably worth a look, whilst perhaps not exactly what you are looking it will help slightly.
It lets you visualise the Vim undo tree, this means you will be able to see the last edits that happened. For example if you accidentally deleted a line or some such this will show up in the tree, however, it doesn't show you the actual keystrokes that were pushed and will not show things such as cursor movements.
There are important features of Emacs which are missing in Vim, such as the comint mode, and there are no scripts/plugins which can replace them.
There are also benefits of Vim over Emacs, such as modal editing and generally better default shortcuts. However, Viper mode gets me both. Vimpulse also enables visual mode.
Unfortunately, no mode can make Emacs work as fast as Vim.
So I mostly learned Vim-in-Emacs. What Vim features am I missing?
I'm a regular vim user but not an emacs user and haven't used vimpulse to confirm this.
But browsing the vimpulse code below I see no mention of text objects.
http://www.emacswiki.org/cgi-bin/wiki/vimpulse.el
Vim introduced some very useful idioms for selection and movement that aren't in regular vi
cat 'cut around tag' for xml/html tags
diw 'delete in word'
di( di" delete text within a "" () etc.
in the vim help see :he text-objects for more.
Unfortunately, no mode can make Emacs work as fast as Vim.
If you mean that the emacs startup time is poor, you can cut it down dramatically by having an emacs session permanently open, and use gnuclient/emacsclient whenever you need to edit a file.
http://www.emacswiki.org/emacs/GnuClient
One vi feature that I miss in emacs is the . (dot) command that repeats the last edit. There is dot-mode.el which implements C-. to simulate this but it didn't always work for me (I am not proficient in elisp to figure out why).
Even viper doesn't implement this command exactly like vi does (last time I checked), and even if it does, I don't think that is enough for me to start using viper.
To get a complete list of what vimpulse may be missing type
:helpgrep not in Vi
Every feature in the help that is not vi compatible will be listed.
Theres about 700 matches.
Of course there will be a lot of duplicated functionality
Vi motion everywhere - in Vi you can always navigate using the same shortcuts, whether you are inside a directory listing, a help file, a write only file or something you're allowed to edit.
Correct visual and delete behaviour - very similar to emacs marking but idiomatically different, so difficult for a Vi user to retrain. If you're already used to the emacs marking you're not really missing anything.
Correct escape behaviour - should cancel all other modal activity and return you to command mode. Again, if you're comfortable in emacs you're probably used to having modal inputs and such anyway.
The obvious chestnuts about Vi being deployed on every nix system in the world (Gentoo purists correct me?) - not a very strong argument in my eyes anyway.
Those are the ones that sprang out during my use of emacs+viper.
Vim macros don't seem to work with viper/vimpulse:
Vim macros don't work when using viper + vimpulse in Emacs
(Btw, the killer emacs feature that makes me care about vim/vimpulse is that different frames can edit the same file. It's like having a split where the two pieces can be in different windows. If anyone knows how to accomplish that in vim, you'd be my hero.)
Incremental search using / and ? is missing.
Being a lover of emacs as an OS and vi as an input model, naturally I wanted to love viper. However within two seconds of using it I had to give it up: viper does not support C-[ as a substitute for the escape key–which is an essential shortcut for the most frequently used command in vi.