This post is similar to this and this, however, without putty, the border could display properly. Therefore, I doubt this was caused by an old version of tmux.
I am running FreeBSD 9.2-release and tmux 1.9a (latest on FreeBSD).
I hope someone can give me solution as to why this happens and how to fix it.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
From the tmux FAQ:
I use PuTTY and my tmux window pane separators are all qqqqqqqqq's!
PuTTY is using a character set translation that doesn't support ACS line
drawing. With a Unicode font, try setting PuTTY to use a different translation
on the Window -> Translation configuration page. For example, change UTF-8 to
ISO-8859-1 or CP437. It may also be necessary to adjust the way PuTTY treats
line drawing characters in the lower part of the same configuration page.
That being said, I use tmux 1.8 with PuTTY 0.62, "UTF-8 translation", "Unicode line drawing code points" and a remote locale of en_US.utf8 which works perfectly fine.
You probably have PuTTY configured to use Unicode without using a UTF-8 locale on your FreeBSD box, or the other way round (if I switch my remote locale to C without touching my PuTTY settings I get the behaviour that you describe).
In my case I could fix it by enabling a setting in PuTTY:
Window ->
Translation ->
Adjust how PuTTY handles line drawing characters ->
[X] Enable VT100 line drawing even in UTF-8 mode
This makes sense, since the "lqqqk" sequences are what VT100 line drawing looks like if it is not interpreted as such.
I had the same problem. The root reason was that the Linux system was using locale "POSIX".
The issue is resolved by:
# show system locale
locale
# using utf-8 as system locale
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
# attach tmux
tmux a
Related
I want to execute a system command from gvim and retrieve the output of that command in the current buffer. So i run the following command in gvim:
:r echo éèà
However the result shows three black squares instead of the echoed characters. I have not yet figure out what to do to get this to work. I have the following encoding setup:
set encoding=utf8
set termencoding=cp850
My windows console encoding is cp850.
TL;DR
:r! echo éèà | c:\cygwin\bin\iconv -f cp850 -t cp1252
Assumptions
I have been able to reproduce your problem on my Windows 10 machine using gvim 7.4, installed via the Windows installer for gvim.
I also have cygwin on my machine, in which I have iconv, and its full path is c:\gygwin\bin\iconv.
Proposed solution
Apparently, gvim expects the output from the Windows shell to be in cp1252 because this worked for me:
:r! echo éèà | c:\cygwin\bin\iconv -f cp850 -t cp1252
I checked the results, and Vim correctly inserted the utf-8 characters for éèà in my document.
I don't have an equivalent to iconv that is Windows native, but if you have Cygwin you can add c:\cygwin\bin to your Windows path and the command should not require an explicit path.
Epilogue
Yuck. This is ugly. The solution works, at least on my machine, but I hope someone finds and posts a more elegant solution.
There ought to be a way to tell gvim what encoding to expect from the shell, but I did not find it. I played with various combinations of settings of encoding, termencoding and fileencoding instead of using iconv, but only managed to get different wrong results.
These related questions faced similar problems but their solutions didn't work in my tests either:
https://superuser.com/questions/682591/vim-uses-wrong-encoding-when-invoking-commands-in-the-terminal
https://vi.stackexchange.com/questions/7105/wrong-encoding-while-calling-shell
The problem stems from the mismatch in character encoding between cmd.exe (default :set shell in vim on Windows) and what gvim expects. I don't know why changing :set termencoding does not fix the problem.
I know this has been asked a few times but none of the answers worked for me.
I use the gnome terminal as default in Ubuntu 14.10 and I can't get unicode characters to show properly, mainly in vim airline.
I have set character encoding to unicode UTF8 in the terminal menu.
and LANG returns utf8:
echo $LANG
en_US.UTF-8
I have installed a patched font from https://github.com/powerline/fonts/
I have probably also tried other tips found on stackexchange that I now can't remember and I still see the weird characters:
When I installed the same font on OSX with iterm it worked instantly.
I have also tried in other terminals on the same system like guake or using ctrl-alt-f1 and the result is the same. I have tried inside or outside tmux as well.
Any help is welcome.
I cannot see any syntax highlighting in any language (e.g. python, c++ and sh) when I use vim within a screen session. The line numbers are in color though.
I precise that my terminal (in screen too) is able to show 256 colors schemes (I tested with the 256colors perl script found here: http://frexx.de/xterm-256-notes/ ).
How can I fix that?
OK, here is the issue/solution:
I used to call vim by using $vi, indeed:
$ which vi
alias vi='vim'
/usr/bin/vim
But:
$ screen
$ which vi
/bin/vi
I just learnt that screen doesn't load this system level alias which is tricky.
I had this problem. In my case, I was running a version of screen from brew. brew doesn't use ~/.screenrc as its startup file. So there's two solutions to this.
1) Set your term in the screenrc that brew_screen is expecting. This might be /opt/etc/screenrc. I didn't try this method, so I'm not sure.
2) Make an alias for screen that sets the term to what you want it to be. In this case, screen-256color is sufficient. I added the following line to my bash_profile, which is symlinked to my bashrc (mac problems):
alias screen='screen -T screen-256color'
on FreeBSD, how to exit from Gnome Session to Pure terminal mode.
Thanks!
Try Ctrl+Alt+F2 key combination to go to text terminal, use Ctrl+Alt+F9 to come back to Gnome or whatever you are running on top of X.
If you want to totally disable X11 open /etc/ttys file, find the line that says:
ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
comment it out, save the file and reboot.
When running a vim instance in gnu screen hitting shift enter in insert mode adds an 'M' and then a newline, rather than just a newline.
Does anybody know what the problem might be, or where to look?
Relevant system info:
Ubuntu 8.04.1
Screen version 4.00.03 (FAU) 23-Oct-06
VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan 31 2008 12:20:21)
Included patches: 1-138
Konsole 1.6.6 (Using KDE 3.5.10)
Thanks to the comments. When checking the value of $TERM I noticed that it was xterm (as expected), but within screen $TERM was set to screen-bce. Setting TERM=xterm after launching screen resolves this issue.
Adding the following to ~/.screenrc solved the problem without having to do anything manually:
term xterm
Missing info from your question:
Where do you run screen and see this issue? Some terminal app (KTerminal, Gnome terminal, virtual console etc) or remote session (eg putty, ssh from another computer)
do a “echo $TERM” and tell us its output
do a “cat -v”, press Shift-Enter, then Enter, then Ctrl-D and then tell us what is output.
First, you could fix your $TERM for within konsole. Install "ncurses-term" and configure konsole to set $TERM=konsole-256color. Then configure screen with "term screen-256color". Or 'konsole' and 'screen', respectively, if that's your preference. Konsole and screen are not xterm and doesn't support everything xterm does, so using incorrect $TERM can lead to bad things.