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.
Related
I am trying to set a custom prompt for GHCI on Windows, but the ANSI colours do not seem to be working.
I tried opening GHCI on CMD (and even in the new Windows Terminal app) and running
:set prompt "\ESC[101m\STX \ESC[m\STX"
which should just display 2 red spaces, but the colouring does not work. It just shows two black spaces.
It works without any problem on my linux distro, so the code should be fine?
Also, it works on Git Bash but not on the VS Code terminal, even if I set it to use Git Bash by default.
I don't even know where to look for a solution, as it could be a GHCI problem or a CMD problem or I'm just missing some package that I need on Windows?
I found a solution but it requires an extra \n after the prompt.
The following command shows it correctly.
:set prompt "\ESC[101m\STX >\ESC[m\STX\n"
One Trick that can be applied is to use a combination of \r \t characters for a fixed tab width.
:set prompt "\ESC[101m\STX >\ESC[m\STX\r\t"
I however could not find how to change the width of tab character in PowerShell or Windows Terminal.
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.
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
I've just started using zsh as my shell, coming from bash. I am on a RedHat Linux Workstation build 6.4. I have all the relevent locales installed but when I move to a zsh prompt and pick any of the themes I have a PS1 that looks like this
ââ[name#host] - [~/tars] - [2013-11-05 09:50:26]
ââ[0]
I'm not sure what is causing these special characters. Another example:
name#host ~/tars » echo $PS1 1 âµ
%{$fg[$NCOLOR]%}%n%{$fg[green]%}#%m%{$reset_color%} %~ \
$(git_prompt_info)\
%{$fg[red]%}%(!.#.»)%{$reset_color%}
Is there something I'm missing that I should have installed?
Depending on the prompt theme you use you need a font which supports those characters or need to install additional fonts for your terminal, like the Powerline fonts.
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.