When I search in, for example, man ls while in a tmux session, the search strings don't appear highlighted - the page jumps down so that the search string is on the top line of the buffer, as expected, but it's not highlighted.
Doing the same thing in the same shell while not in a tmux session results in highlighted search strings.
I have no idea where to start looking to solve this. Any hints are appreciated.
Based on Less Colors For Man Pages by Gen2ly, here is my man page and how to do it:
Preview
This is a shell, not a web page !
How to
(optional) I'm using Tomorrow theme for Konsole/Yakuake ;
Edit your ~/.bashrc ~/.zshrc, etc. to add :
# Colored man pages: http://linuxtidbits.wordpress.com/2009/03/23/less-colors-for-man-pages/
# Less Colors for Man Pages
export LESS_TERMCAP_mb=$'\E[01;31m' # begin blinking
export LESS_TERMCAP_md=$'\E[01;38;5;74m' # begin bold
export LESS_TERMCAP_me=$'\E[0m' # end mode
export LESS_TERMCAP_se=$'\E[0m' # end standout-mode
export LESS_TERMCAP_so=$'\E[38;5;016m\E[48;5;220m' # begin standout-mode - info box
export LESS_TERMCAP_ue=$'\E[0m' # end underline
export LESS_TERMCAP_us=$'\E[04;38;5;146m' # begin underline
Reload your config and try a man page search :
. ~/.bashrc && man ls
Fixed it. The problem is to do with the way that the screen $TERM handles italics. From the tmux FAQ:
vim displays reverse video instead of italics, while less displays italics
(or just regular text) instead of reverse. What's wrong?
This matches my problem exactly. The $PAGER used by man is less by default - basically, man uses less to show the contents of the manual pages. In my case, less wasn't highlighting text, just showing regular text.
The reason for this happening:
Screen's terminfo description lacks italics mode and has standout mode in its
place, but using the same escape sequence that urxvt uses for italics. This
means applications (like vim) looking for italics will not find it and might
turn to reverse in its place, while applications (like less) asking for
standout will end up with italics instead of reverse.
The solution is to make a new terminfo file for tmux, which lets it know that italics are supported. The solution's outlined in the (at time of writing) very, very bottom of the tmux FAQ.
After creating the new terminfo file, in tmux: C-b :source-file /absolute/path/to/.tmux.conf (from this SuperUser question) - this should make tmux reload the .tmux.conf file. However, this didn't work for me, and the changes only applied after restarting the tmux server (close all tmux sessions, then re-open them).
This thread is a few years old but is still the one that comes up as the best search result, so I'm answering with what finally worked for me. This is based off of tmux FAQ.
...but the instructions aren't completely clear on when or where to substitute the -256color string. I use gnome-terminal (v 3.16.2) with tmux, and this worked for me:
$ mkdir $HOME/.terminfo/
$ screen_terminfo="screen-256color"
$ infocmp "$screen_terminfo" | sed \
-e 's/^screen[^|]*|[^,]*,/screen-256color|screen with italics support,/' \
-e 's/%?%p1%t;3%/%?%p1%t;7%/' \
-e 's/smso=[^,]*,/smso=\\E[7m,/' \
-e 's/rmso=[^,]*,/rmso=\\E[27m,/' \
-e '$s/$/ sitm=\\E[3m, ritm=\\E[23m,/' > /tmp/screen.terminfo
$ tic /tmp/screen.terminfo
And tell tmux to use it in ~/.tmux.conf:
set -g default-terminal "screen-256color"
Note: I tried it once without the -256color and since that didn't work (still seeing italics instead of highlighting), I had to delete everything under the .terminfo dir (another dir called 's') before the infocmp would work.
Related
I use zsh and I would like backward-kill-word in Emacs mode to behave like Emacs (and bash, fwiw). The behaviour that I have failed to reproduce is that when I press multiple backward-kill-word Emacs adds the killed text to the cut buffer (the first item in the killring) making it possible for me to yank everything with one yank command.
How can I configure zsh to behave like this aspect of Emacs editors?
Actually, by default, Zsh's cut buffer works exactly the same as in Emacs. Just use zsh -f to start Zsh without config files and try it.
However, are you perhaps using zsh-autosuggestions or zsh-syntax-highlighting? There are bugs in these plugins that break this feature:
https://github.com/zsh-users/zsh-autosuggestions/issues/363
https://github.com/zsh-users/zsh-syntax-highlighting/issues/150#issuecomment-658381485
Fixes have been submitted, but for zsh-autosuggestions, none have yet been merged, and for zsh-syntax-highlighting, the fix won't work until Zsh 5.9 has been released.
In the meantime, though, zsh-autocomplete contains a workaround that fixes the problem. If you add that plugin, your cut buffer will start functioning like normal again.
I discovered this little navigation trick the other day, which allows me to trigger menu completions by number when I enter 'cd -'
~ cd -
0 -- ~/home
1 -- ~/home/stuff
2 -- ~/downloads
3 -- ~/wallpaper
Shell scripting syntax still reads like a foreign language to me, but to get this functionality my directory stack history is piped into the function below.
DIRSTACKSIZE=9
DIRSTACKFILE=~/.zdirs
if [[ -f $DIRSTACKFILE ]] && [[ $#dirstack -eq 0 ]];
then dirstack=( ${(f)"$(< $DIRSTACKFILE)"} )
[[ -d $dirstack[1] ]] && cd $dirstack[1] && cd $OLDPWD
fi
chpwd() {
print -l $PWD ${(u)dirstack} >$DIRSTACKFILE
}
The magical part is being able to choose from the list by number, but I have come to learn that this is probably
because the functionality for navigation by number is baked in to the 'cd -' command. Still, I'd like to use this everywhere.
Any tips writing a wrapper function (or something like that, I guess) for the completion menu that pipes in completions from the menu when it is triggered
and displays them in a numbered list where those numbers select the corresponding element?
I've gotten started reading the manual and what not, but everything remains rather opaque. Thanks!
First off, the code snippet you show has nothing to do with completion. Instead, what it does is to record the directory stack to a file in order to preserve it between zsh sessions. (Personally, I'm not even sure this is a good idea.)
A good place to start investigating zsh completions is the _complete_help ZLE widget. This is bound by default to ^Xh in zsh's viins (vi insert) keyboard map, but is unbound by default in the emacs keymap. If you want to use it in the emacs keymap (the default for many people), you have to bind it:
bindkey -M emacs "^Xh" _complete_help
Now you can type cd - (or cd +) and follow it by CTRL-Xh instead of TAB. You should see the following output:
tags in context :completion::complete:cd::
directory-stack (_directory_stack _cd)
(At this point I'll admit we're getting close to the limits of my knowledge of the zsh completion system.)
Now you can see the completer functions for the directory-stack tag in this particular context. The one you're probably interested in is _directory_stack, and you can see the content of that function with:
functions _directory_stack
…which is where those leading numbers are actually generated.
Arguably it's possible to write similar completion functions for other completion contexts, and apply the using zstyle. However, this is non-trivial completion magic, and beyond anything I have attempted
I have looked at the answers to vi input mode in R? and vi mode to emacs mode while on R. Through the latter question, I learned that meta-ctrl-j will work to toggle vi-mode in R, but I cannot get it to stick so that every time I start R, vi-mode is enabled by default.
I have tried placing set editing-mode vi in my .inputrc, but that does not have the desired effect.
How can I get the vi-mode from meta-ctrl-j to be persistent across R sessions?
Try bind -f ~/.inputrc then bind -V | grep editing-mode and see if you get editing-mode is set to 'vi'.
If that works, it's just a matter of getting that file to be read on login.
Try echo $INPUTRC, if empty set it in your ~/.bashrc. Bash will supposedly check for ~/.inputrc then $INPUTRC then /etc/inputrc in search of your inputrc config.
Additionally, you might try adding bind -f ~/.inputrc to your ~/.bashrc if R opens up an interactive shell.
I'm new to Vim. I was experimenting with vim-powerline and tmux (and pathogen and vundle).
Somwehere in that process I tried to remove powerline and tmux started receiving this error.
My .tmux.conf file is empty. How can I find where tmux is trying to run this command?
I had this problem, too, but not in the first tmux window. It only happened for me in subsequent windows. I found a solution, but not exactly the cause of the problem.
The short version is the set the value of the POWERLINE_COMMAND variable in your .bashrc on the line before you source the bash binding. For me, that means:
export POWERLINE_COMMAND="$HOME/powerline/scripts/powerline"
. $HOME/powerline/powerline/bindings/bash/powerline.sh
I don't get exactly why this happens in subsequent tmux windows but I added some echo lines to the bash binding to find out what's happening. When the binding is sourced in subsequent windows, POWERLINE_COMMAND is already set to powerline, so it skips the code that checks for the right place to set it. I couldn't figure out where, how, or why it's already set, though.
Here's the code that does the check from the beginning of the bash binding:
if test -z "${POWERLINE_COMMAND}" ; then
if which powerline-client &>/dev/null ; then
export POWERLINE_COMMAND=powerline-client
elif which powerline &>/dev/null ; then
export POWERLINE_COMMAND=powerline
else
# `$0` is set to `-bash` when using SSH so that won't work
export POWERLINE_COMMAND="$(dirname "$BASH_SOURCE")/../../../scripts/powerline"
fi
fi
Since it works in the first window, I just set POWERLINE_COMMAND to point to the command that it points at in the first window. Setting it before sourcing the bash binding skips the whole check.
I suggest you to check your shell's configuration files. If you use e.g. use bash, check $HOME/.{bashrc,profile} or $HOME/.zshrc for zsh. There is probably a line like
. {repository_root}/powerline/bindings/bash/powerline.sh
according to the powerline installation instructions.
The mark " in Vim takes you to your last cursor position. I want to create an alias that will open my Vim instance and jump to that mark; something which is obviously extremely useful.
This works from the command line:
$ vim -c "'\"" File.cpp
Now I want to make an alias for this:
$ alias v='vim -c "'\""'
Well that's not going to work! You need to escape the first single quote you say...
$ alias v='vim -c "\'\""'
Hmm. That didn't work either... So I try a whole lot of variations of single quoted and double quoted madness, bang my head against the table and load up stackoverflow in my browser, and here we are.
How do I properly escape this alias?
Edit
In fact there is a better way to do this :h last-position-jump.
This autocommand jumps to the last known position in a file just after opening it, if the '" mark is set:
:au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
Your question is an example of a situation in which functions are superior to aliases:
v() { vim -c "'\"" "$#"; }
This looks completely obscure, but should work:
alias v='vim -c "'"'"'\""'
That's a single-quoted vim -c ", followed by a double-quoted ', followed by a single-quoted \""...
Another solution is GNU Screen. It let's you save one or more shell instances (where one or more could be running vim) and saves their exact contents as if your computer would be idling. In particular, it's perfect for having many tabs and files open on a remote computer.
So instead of just going to the last mark, you'd simply type screen -r mysession and you'd restore not just the last position of the cursor, but all your buffers/tabs/shell instances/other programs and what not.
But perhaps you knew that already.