I recently installed Zsh in hope of a better life and brighter mornings. However, I quickly realized Zsh introduces various issues in conjunction with tmux.
The first issue was some weird stuff happening at the end of the prompt, before my commands, but this was resolved by supplying tmux with the -u flag for unicode-support. However, I am stuck with one final issue that needs resolution before I can use Zsh with tmux:
Usecase: Autocomplete a command which contains multiple suggestions
Issue: Autocompletion shifts suggestion one character to the right, while leaving the original character behind (visual bug, it is not included in the command)
Example 1.
Then I hit TAB..
Example 2.
Then I hit TAB..
Note 1: This does NOT occur when using the Bash-shell.
Note 2: I am using "oh-my-zsh". This issue only occurs when using the provided themes. This narrows it down to an "oh-my-zsh"-theme issue, not native zsh/tmux.
In case some people still get a similar issue, see also the top-voted answer of Remnant characters when tab completing with ZSH. The plugin you were using may have had the same non-printable characters issue, that would explain the symptoms.
Related
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.
When R is run interactively in a terminal which supports colors, it is possible to use ANSI escape sequences in order to put colors in the prompt, such as
options(prompt = "\033[0;31mThis is red\033[0m> ")
Unfortunately, something goes wrong because for long command lines, the line continuation override the prompt instead of being written in the next line.
The problem gets worse when using several colors, because somehow each escape sequence "takes up some space" in the command line, up to the point that the end of the prompt might overwrite the beginning. On my configuration this happens with for instance
options(prompt = paste("\033[0;31m With \033[0;32m multiple",
"\033[0;33m colors \033[0;34m this",
"\033[0;35m gets \033[0;36m really",
"\033[0;37m wrong! \033[0m"))
Why is it so? Is there a workaround?
PS: This rather old post seems related http://r.789695.n4.nabble.com/Xterm-escape-sequences-in-Prompt-td906375.html
update: with R version 3.6.0 and readline 8.0 (don't know which matters here), most of the above described problem disappeared, but some strange behaviors remain. Accepted answer below resolves everything.
you need to surround each «invisible» color code with special «marks»: \001 and \002:
options(prompt = "\001\033[0;31m\002This is red\001\033[0m\002> ")
for explanation see $ info readline (or this short answer).
Gábor Csárdi on the r-devel mailing list says that I cannot easily change this behavior (http://r.789695.n4.nabble.com/buggy-ANSI-escape-sequences-in-R-prompt-td4728671.html). The workaround he proposes is to use a two lines prompt, which suits me well enough.
I've seen both:
#!/path/...
#! /path/...
What's right? Does it matter? Is there a history?
I've heard that an ancient version of Unix required there not be a space. But then I heard that was just a rumor. Does anyone know for certain?
Edit: I couldn't think where better to ask this. It is programming related, since the space could make the program operate in a different way, for all I know. Thus I asked it here.
I also have a vague memory that whitespace was not allowed in some old Unix-like systems, but a bit of research doesn't support that.
According to this Wikipedia article, the #! syntax was introduced in Version 8 Unix in January, 1980. Dennis Ritchie's initial announcement of this feature says:
The system has been changed so that if a file being executed begins
with the magic characters #!, the rest of the line is understood to
be the name of an interpreter for the executed file. Previously (and
in fact still) the shell did much of this job; it automatically
executed itself on a text file with executable mode when the text
file's name was typed as a command. Putting the facility into the
system gives the following benefits.
[SNIP]
To take advantage of this wonderful opportunity, put
#! /bin/sh
at the left margin of the first line of your shell scripts. Blanks
after ! are OK. Use a complete pathname (no search is done). At the
moment the whole line is restricted to 16 characters but this limit
will be raised.
It's conceivable that some later Unix-like system supported the #! syntax but didn't allow blanks after the !, but given that the very first implementation explicitly allowed blanks, that seems unlikely.
leonbloy's answer provides some more context.
UPDATE :
The Perl interpreter itself recognizes a line starting with #!, even on systems where that's not recognized by the kernel. Run perldoc perlrun or see this web page for details.
The #! line is always examined for switches as the line is being
parsed. Thus, if you're on a machine that allows only one argument
with the #! line, or worse, doesn't even recognize the #! line, you
still can get consistent switch behaviour regardless of how Perl was
invoked, even if -x was used to find the beginning of the program.
Perl also permits whitespace after the #!.
(Personally, I prefer to write the #! line without whitespace, but it will work either way.)
And leonjoy's answer points to this web page by Sven Mascheck, which discusses the history of #! in depth. (I mention this now because of a recent discussion on comp.unix.shell.)
It seems to usually work both ways. See here. I'd say that the no-space version is much more common today, and, to me, much more appealing.
BTW, this is not specifically related to Perl (but it's definitely related to programming).
I'm simply trying to get shift+tab to be a recognized key sequence during my rxvt terminal sessions. So I can map it to usefulness such as:
bindkey "\e[Z" reverse-menu-complete
But, based on my research, I'm pretty sure the answer is no. Just want to make sure.
This is a hard limitation of rxvt? (Is there a technical reason for this limitation? Or just an unsupported feature?)
I can't get it to emit that either, although strangely enough, the rxvt source code (as shipped with Cygwin) does appear to have support for it:
case XK_Tab:
if (shft)
STRCPY(kbuf, "\033[Z");
else {
...
Anyway, rxvt development stopped eight years ago. Try its successor, rxvt-unicode, aka urxvt, where this does work. If you're on Cygwin or MSYS and you were using rxvt without an X server, which urxvt does require, try mintty.
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?).