I'm a happy user of the Nvim-R plugin, but I cannot find out how to scroll up in the buffer window that the plugin opens with R. Say for instance that I have a large output in console, but I cannot see the top of it - how do I scroll up to see this? In tmux for instance there's a copy mode that quite handily lets you do this, but how is this done in the R buffer?
An example below where I'm very curious to see what's on the line above the one begining with "is.na(a)...". How can this be achieved?
I have scoured the documentation found here, but without luck.
The answer is apparently to use Ctrl+\ Ctrl+n according to this answer on the bugreports for NVim-R.
Here's what my output looks like when I output mtcars:
When I hit Ctrl+\ Ctrl+n, I can move the cursor and I get line numbers:
To get back to interactive, I just use i, the same way I normally would.
Apparently, if you are using neovim, then you can add let R_esc_term = 0 in your ~/.vimrc file and you can then use the escape key, but if you don't use neovim, you are stuck using the two ctrl commands ¯\_(ツ)_/¯.
As pointed out by ZNK, it is about switching to normal mode in Vim's terminal. This, however, can easily fail due to cumbersome keybinding. If such is the case, remap the default keybinding to something reasonable, say, by putting this in your .vimrc:
tnoremap jk <C-\><C-n>
This works for me in Linux running Vim 8.0 in terminal (e.g. does not require Neovim). As you can see, I use 'jk' to switch from insert to normal mode. One can use Esc instead of jk, however, this makes me unable to use up arrow to retrieve command line history as been reported elsewhere.
Related
Is there a quick way to search old commands which were run in the Julia REPL? Using the up arrow to go back in time seems to have a limit on its history and it is also quite cumbersome.
One of the five REPL models available in Julia is the "Search mode" which allows you to search through previously executed commands from the REPL. You can click "Control" + "r" to open search mode like is shown below:
(reverse-i-search)`':
There is also a forward search available with "Control" + "s". You can read more about Julia's REPL Search mode here: https://docs.julialang.org/en/v1/stdlib/REPL/#Search-modes
In addition to "real" search, you can also enter the beginning of a previous line and scroll up in the history (using ↑ or Ctrl-P) to switch between all previously entered lines starting with the same prefix.
So, if you had previously entered x = some_complicated_expression, you can write x = and go up until the line you were looking for appears.
Checkout: https://kristofferc.github.io/OhMyREPL.jl/latest/features/fzf/#Fuzzy-REPL-history-search
Which will be easier to use than reverse-i-search
When using the up and down arrow in my terminal (iTerm 2 on Mac OS Catalina), I can browse through my last commands using the up and down arrows.
I use ZSH (Oh-my-zsh to be precise) and if I type e.g. vim then press up, it will browse my history for any commands issued starting with vim.
I think it's annoying to have to move my hand to the arrow keys, so i wanted to bind ctrl-j and ctrl-k for browsing up and down.
I looked at bindkey and bound ^j to down-history and ^k to up-history. This allows me to browse my history, but not with the "smart" functionality (i'm not sure of the right terminology here) - It simply goes up and down in my history, without regards to my input.
I've looked through the standard widgets on the Zsh Line Editor manual, but I cannot find the right command for this.
Which command should I bind ^j and ^k to to get my desired result?
After some further digging, i ended up on the The Z-Shell Line Editor page at the section called "Prefix searching".
It revealed that the widget I was after, is called history-beginning-search-backward.
When using that widget, it works almost as I wanted it to, but not jumping to the end of the line.
A quick search lead me to another StackOverflow Question, that states that if you want to jump to the end of the line (as with the up arrow), it should be done as follows;
I had the same question and managed to find the solution with some experimentation.
I added the following to my .inputrc
"\eOA": history-search-backward # Up
"\eOB": history-search-forward # Down
"\C-P": "\eOA\C-E" # Ctrl-P
"\C-N": "\eOB\C-E" # Ctrl-N
This binds two hotkeys to Ctrl-P and Ctrl-N. One for history search, and the other Ctrl-E for end-of-line.
I'm a new Atom user and I want to override the Atom command palette (shift-ctrl-p) scrolling key bindings to something more vi friendly like
ctrl-n and ctrl-p instead of the annoying arrow keys (which force me to take my hands off the home row).
Just to be clear, I don't want to change the key binding that brings up the command palette, but the key bindings you use to scroll through the list once it's up:
I can only find a binding to override the command palette toggle:
As you can see in the following config file, I was able to override the autocomplete scrolling, and I hope to do the same with the command palette. I've tried 'command-palette:up' ,'command-palette:down' and 'command-palette:move-up' etc. to no avail.
Here's is my keymap.cson.
# Atom Flight Manual:
# https://atom.io/docs/latest/using-atom-basic-customization#cson
#vt add
'body atom-text-editor.autocomplete-active':
'ctrl-p': 'autocomplete-plus:move-up'
'ctrl-n': 'autocomplete-plus:move-down'
'alt-p': 'autocomplete-plus:page-up'
'alt-n': 'autocomplete-plus:page-down'
'home': 'autocomplete-plus:move-to-top'
'end': 'autocomplete-plus:move-to-bottom'
# vim-plus ex mode 2016-04-18
'atom-text-editor.vim-mode-plus.normal-mode':
':': 'vim-mode-plus-ex-mode:open'
'!': 'vim-mode-plus-ex-mode:toggle-setting'
# add cmd palette key bindings --> These do not work.
'body .native-key-bindings':
'ctrl-p': 'command-palette:up'
'ctrl-n': 'command-palette:down'
#vt end
I've been really impressed with the key binding support in Atom thus far. I'd be really surprised if it couldn't handle this but, alas, I think this might be the case.
Does anyone know of a way to do this?
Atom 1.7.2, linux
I was able to get single line scroll to work, but not page scroll to work with the following in my keymap.cson:
'atom-workspace':
# these work
'ctrl-p' : 'core:move-up'
'ctrl-n' : 'core:move-down'
# these don't work
'alt-p' : 'core:page-up'
'alt-n' : 'core:page-down'
It would be nice to have page scroll as well, but I should be able to narrow down the list down by typing in text, so I don't foresee needing page-up, page-down all that often.
Now I'm happy.
To target keybindings for just the command palette, you can find an appropriate selector by looking in the command-palette repo keymaps: https://github.com/atom/command-palette/blob/v0.43.5/keymaps/command-palette.cson
This suggests the use of the .command-palette selector, which seems more appropriate then atom-workspace.
'.command-palette':
'ctrl-n': 'core:move-down'
'ctrl-p': 'core:move-up'
I was not able to find a mapping to scroll a page at a time within the command palette, though I'm sure someone else can figure it out. The keyboard page up/down keys have no effect so mapping to core:page-down etc. is not going to work.
I've removed and added a few times now the following line to ~/.tmux.conf:
set -ga terminal-overrides ',xterm*:smcup#:rmcup#'
Which according to the person who provided it does the following:
to fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.
The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as.
The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.
I don't quite understand the bolded section (emphasis added), but guess this is the source of what I'm seeing. It's causing some weird sort of unicode overspill upon exiting tmux.
Pasted as plaintext this text won't show up, but the symbol [001B]112 appears alongside the usual [exited]:
]112[exited]
(FWIW I think it has pasted in that line, but isn't displaying)
I followed this advice ("Use terminal scrollbar with tmux"), and while it does work, this is just ugly/annoying to see that upon exiting. Can anyone advise how to fix or avoid the output message?
Offhand, I would get the unwanted "message" is some hard-coded application (or script) which is helpfully resetting the xterm dynamic text cursor color. See XTerm Control Sequences in the description of Operating System Controls:
The dynamic colors can also be reset to their default
(resource) values:
...
Ps = 1 1 2 -> Reset text cursor color.
So... somewhere there is some script doing the equivalent of
echo -n -e '\e]112\a
The results probably depend most on what particular terminal emulator you are using. Both screen and tmux filter out escape sequences that their developers did not care to implement, and pass through those that the terminal "should" handle.
Just take a look at sentence you provided: "The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as."
In my case, the $TERM has value xterm-256color and the corresponding line in ~/.tmux.conf looks like:
set -g terminal-overrides "xterm-color256:smcup#:rmcup#"
I have Vim 7.2 installed on Windows. In GVim, the <C-PageUp> and <C-PageDown> work for navigation between tabs by default. However, it doesn't work for Vim.
I have even added the below lines in _vimrc, but it still does not work.
map <C-PageUp> :tabp<CR>
map <C-PageDown> :tabn<CR>
But, map and works.
map <C-left> :tabp<CR>
map <C-right> :tabn<CR>
Does anybody have a clue why?
The problem you describe is generally caused by vim's terminal settings not knowing the correct character sequence for a given key (on a console, all keystrokes are turned into a sequence of characters). It can also be caused by your console not sending a distinct character sequence for the key you're trying to press.
If it's the former problem, doing something like this can work around it:
:map <CTRL-V><CTRL-PAGEUP> :tabp<CR>
Where <CTRL-V> and <CTRL-PAGEUP> are literally those keys, not "less than, C, T, R, ... etc.".
If it's the latter problem then you need to either adjust the settings of your terminal program or get a different terminal program. (I'm not sure which of these options actually exist on Windows.)
This may seem obvious to many, but konsole users should be aware that some versions bind ctrl-pageup / ctrl-pagedown as secondary bindings to it's own tabbed window feature, (which may not be obvious if you don't use that feature).
Simply clearing them from the 'Configure Shortcuts' menu got them working in vim correctly for me. I guess other terminals may have similar features enabeld by default.
I'm adding this answer, taking details from vi & Vim, to integrate those that are already been given/accepted with some more details that sound very important to me.
The alredy proposed answers
It is true what the other answer says:
map <C-PageUp> :echo "hello"<CR> won't work because Vim doesn't know what escape sequence corresponds to the keycode <C-PageUp>;
one solution is to type the escape sequence explicitly: map ^[[5^ :echo "hello"<CR>, where the escape sequence ^[[5^ (which is in general different from terminal to terminal) can be obtained by Ctrl+VCtrl+PageUp.
One additional important detail
On the other hand the best solution for me is the following
set <F13>=^[[5^
map <F13> :echo "hello"<CR>
which makes use of one of additional function key codes (you can use up to <F37>). Likewise, you could have a bunch of set keycode=escapesequence all together in a single place in your .vimrc (or in another dedicated file that you source from your .vimrc, why not?).