I am using Cygwin on windows 7
mintty 2.3.6 (x86_64-pc-cygwin)
And randomly a [28~ will appear on my prompt line. Sometimes it even appears while I am in the middle of typing a command. And often it appears even when the terminal window doesn't have focus.
This is really hard to google for, because google just sees the 28. I would appreciate suggestions on how to improve my google-fu to search for the specific sequence.
This can be caused by an application such as Caffeine, which stops your screensaver by pressing a key periodically (like F15 which has ansi sequence \[[28~) . You can stop the program or add an entry in your ~/.inputrc to ignore the sequence. in ~/.inputrc add the line:
"\e[28~":""
to remap F15 to nothing in the terminal.
For the record, there are two other ways to fix this:
Prevent F15 from being interpreted on the mintty side: Add the following line to your mintty config file (e.g. ~/.minttyrc). It tells mintty to ignore F15 by itself or with the Ctrl modifier, which does the trick for me (on my machine, it would produce ~ by itself, and with Ctrl, ;5~):
KeyFunctions=F15:void;C+F15:void
Prevent Caffeine from sending F15 by running it with the -useshift option.
Related
In Vim, a very useful keyboard shortcut is ctrlxctrll (that's a lowercase L) which will complete the entire line you're typing based on lines in all open buffers. My linewise completion has stopped working.
When I type (in insert mode) ctrlx it correctly shows me ^X Mode (...^L) in my status line, but when I hit ctrll Vim just beeps at me and outputs nothing.
I have 54 plugins and update my .vimrc often. How can I debug this shortcut? Is there a way to see what a double stroke motion is mapped to?
Turns out this was because I was using the software Karabiner which ironically is designed to give you Vi mode in various parts of OSX. The specific setting I had enabled was ctrl-hjkl in any inputs would map to up/down/left/right. I discovered this by running vim -u NONE to run Vim without plugins, and as it still presented the error, I realized the problem lied outside of Vim.
I'm using SBT 0.13.6 on Windows 7, and I'm running it using Cygwin (bash shell). I have a problem with the arrow keys: Arrow-up moves the cursor up, whereas I want it to cycle through the command history (and I think that's what it should do by default).
The problem seems to be what's printed in the terminal. When I press: [arrow up] [enter], it does execute the previous command. But what I see in the terminal is the cursor moving up one line, and after the enter, it prints the previous command and execute it.
It should, of course, print the previous command immediately after I hit arrow-up, and it should not move the cursor (not vertically at least)
The command-line in SBT is handled by JLine 2. Running JLine in trace mode I can see that it does recognize the key-presses and it has mapped the arrow-up to "previous-history", but the terminal is not updated correctly.
I also had the problem that I had to manually insert an end-of-line character for a command to be entered, which was fixed by adding the following option to my SBT start-up script:
-Djline.terminal=unix
I have tried the other options as well (win, auto, off, etc). I have put the following lines in a file jline.inputrc in my home directory, but it doesn't help:
"\e[A": previous-history
"\e[B": next-history
And in fact I didn't think it should help, because I can see that the key-presses are recognized correctly and mapped to the right command.
The behaviour does not depend on which arrow keys I use (the ones on the numeric keypad or not).
A work-around is to run SBT directly from the Windows command shell (cmd.exe).
Does anyone know of a way to fix this, so that command-history cycling works as expected in Cygwin?
Is there a command which shows what was the last command in normal mode?
Suppose I accidently hit random key and got some unexpected result.
Sure I can undo it, but could I reveal what key was pressed and how it was interpreted?
Hit the colon (:) and then use the up arrow to start going back through previous commands. You can use the up/down arrows too to move around the list.
q: will show you command history in Vim.
q/ will show you history of searches.
And must importantly, :q will quit the mode.
The text from the last command is stored in the . register. You can see all registers by :display. Unfortunately it doesn't say what the started the normal command.
To see commands from : (command mode) you can use :hist or q: which is limited to the last 20 (by default).
Another ability is to save the undo buffer :wundo undo.bin -- but the undo buffer is binary.
But none of these actually answer your question. I'm curious if it can be done.
Entering colon : then ctrl+p shows your previous command, i.e., moving backward through your vim command history. ctrl+n moves forward.
This is very convenient if you're used to using the command line and prefer not to change your keyboard hand positioning to use arrow keys.
It is difficult to know it. You can play with the variables:
v:operator
v:count (and v:prevcount)
v:register
But you cannot fully get the last normal mode command issued.
However if you want to systematically record everything you type while in Vim, you can launch vim -W ~/.vim-last-scriptout (a Windows version: vim -W "%HOMEPATH%\Vim\.last-scriptout) You can alias it in your shell on a UNIX machine. Every single key, or control-key, will be recorded into that file. Note that if you happen to use gvim or vim -g (the GUI) you might encounter this bug.
If you want to replay this file you can use :source! (with the exclamation mark) or the -s option from the command line.
On Windows I have set gvimportable.exe -W gvim_directory\last_scriptout as my default editor in my Commander program (FreeCommander). This way I can always remember what I have typed to do something and repeat a sequence of commands on another file. Of course I have another shortcut for opening Vim and playing the scriptout.
Note that the file might be written only when Vim exits, so you have to lose your session to know what you've done.
I want to see the original contents of screen after quitting vim
as they were before opening a file , as of not my file quits but the original display is not there
THanks
The feature of returning screen contents after running a full screen application vs, leaving the contents there, is not specific to vi, but to your terminal emulator. The feature you want to turn on to return to the previous text is often known as 'altscreen'. If you are using xterm as your terminal emulator, this behaviour is default. However if you are running GNU Screen inside of an xterm (or other terminal), you need to add the line
altscreen on
to your ~/.screenrc file. Other terminals that support this feature will have other mechanisms to turn it on and off.
Instead of quitting, you can put vim into the background by typing control-z. This restores the previous screen, but leaves you the editor running 'stopped' with the current file. To get vim back, enter the command
fg %1 at the shell prompt. This brings vim back to the foreground again - at least assuming you only have one stopped job. The command jobs will give you a list of stopped jobs, which you can access by number.
So the work sequence becomes edit, save, control-z, compile, test, fg...
This works on linux, and Mac OS X - YMMV on other Unix variants.
If you are using xterm, then see :help xterm-screens, or ... read that anyway as it describes that your problem should be related to some terminfo setting - probably.
HTH
Is it possible for the terminal to detect ⇧ Shift+Enter↵ or Ctrl+Enter↵ keypresses?
I am trying to configure vim to do key mappings that use these sequences, and while they work fine in gvim, they don't seem to work in any terminal console.
The curious thing is that although Ctrl+Enter↵ is not detected in vim, mapping Enter↵ to Esc maps properly, but then pressing Ctrl+Enter↵ behaves like Enter↵!
Some terminals send <NL> when <C-Enter> is pressed. This is equivalent to sending <C-J>.
To find out what your terminal does with <Shift-Enter>, <Ctrl-Enter> and <Enter>, go to your terminal, type <Ctrl-V> (similar to sykora's suggestion for vim), and type in the sequence you're interested in.
Using gnome-terminal, I get the following:
<Enter> : ^M
<S-Enter> : ^M
<C-Enter> : <NL>
Looking at man ascii indicates that ^M gives the <CR> sequence.
The answer is that it depends on the terminal, and there's an easy way to check.
Gvim runs its own manager for keystroke handling and so can pick up all the various key combinations. Vim is reliant on the specific terminal for passing on the particular keypress, so keyhandling is only as good or varied as the terminal is.
One way you can find out whether you can do what you want to do is to use the key to find out what is inserted. eg Type:
:<C-V><C-Enter>
ie actually type in the combination you want to press after having typed the combination Control-V. After that do the same thing for enter, ie
:<C-V><Enter>
If they yield the same code, then the terminal interprets both key combinations as the same keycode, and you can't bind them without messing with the terminal.
In my terminal (urxvt), Control-Enter, Shift-Enter and Enter (by itself) all produce the ^M character, meaning I can't map one without mapping the other. The same goes for Control-Tab and Control-I, and Control-Space and Control-#
EDIT: Use C-Q instead of C-V for Windows.