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.
Related
I installed neovim with pkg install neovim. I then downloaded the latest version of Nvim-R with curl -L "https://www.vim.org/scripts/download_script.php?src_id=26482" > NvimR.vmb. Finally, I opened the file with nvim NvimR.vmb.
Now I'm in the editor and I launch the command mode by pressing the : key on my keyboard. I then proceed to type packadd vimball into the command console. Finally I try to issue the packadd vimball command by hitting Enter on my keyboard and nothing happens. I look up in the editor panel and notice each time I hit Enter the cursor is just being moved around in the editor.
I don't want the cursor to move around in the editor. I want to issue my :packadd vimball command. How do I do this?
Everything I see in that gif is precisely what I would expect to see given what you typed.
You run :packadd vimballEnter—this does vim’s native packadd command (assuming nvim has that), and then returns you to the editing portion of the screen.
Subsequent Enter presses are equivalent to j—move down a line.
All of that said, I dont know of any packages named vimball, but I don’t really work with that format. Perhaps you’ve misunderstood a plugin’s usage or vimball usage? Ask about that stuff on vi.stackexchange.com: we probably have better vi/m experts there.
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 just installed the vim-r-plugin on a Linux server and I found this issue (see below figure) prompted from the R console window (vimcom: Did you pass the --servername argument to Vim? ...) when I typed "\rf":
To solve the issue I followed the instructions here and was trying to find the "servername" and tested some commands such like:
But I have no idea what's the "--servername" I should use here. Any suggestions or answers? Thanks!
--servername is usually followed by some arbitrarily chosen name. This allows external processes like those used by your R plugin to interact with a running instance of Vim.
When the feature is available, GVim always starts as if you added --servername GVIMn where n is a number incremented for each new GUI window. You can see it on the right of the window title.
But you are using Vim so you'll need to do that explicitely:
$ vim --servername FOO
I'm using CentOS 6. Since the CentOS repos have an older version of vim (7.2), I have compiled my own. However, I am having a weird issue. After running and exiting vim, I've found that my shell prompt has disappeared. Also, when I type, it does not appear in the terminal, nor does any output. What's weird is that it looks as though something is being outputted, since the cursor will move down the screen, but I can't see anything.
It must have something to do with compiling an X version, because it does not happen when I compile vim without X windows support (but I would like to have gvim, too). Here are the configuration options I supplied when compiling:
./configure --prefix=$OPT/Cellar/vim/7.4 --with-features=huge --enable-gui=auto --with-x --enable-xim
I also tried compiling without Xim. I've also tried explicitly setting --enable-gui=gtk2 (which is what gvim 7.2 from the CentOS repos uses).
I am using KDE4. The problem occurs both when running tcsh and bash. I have tried with $TERM set to both xterm and xterm-256color as well.
Additionally, running neither reset nor stty sane restores the shell to its proper behavior.
Any idea why my prompt disappears when running vim? As I missing a config flag or some other compilation issue?
I ultimately traced this down to an error in my ~/.vimrc file. I had some lines like this:
if has('gui_running')
# Gvim customization
endif
if has('gui_gtk2')
# GTK2-specific Gvim customization
endif
The second block was running every time vim loaded. Because it changed some window geometry, it ended up messing up bash; when I dropped back to bash, bash thought it only had ~53 columns to work with (and possibly some other things were messed up).
Solution: The second if block should be inside the first.
I am trying to use rxvt on my cygwin w win XP but the terminal appears and disappears. What could be wrong? This is true for all except rxvt-native . I have tried a few commands found online but with no success. I include 2 I have tried:
start C:\cygwin\bin\rxvt.exe -sb -sl 3000 -fg gray -bg black -fn "Lucida Console-14" -e /bin/bash --login -i
.
path C:\cygwin\bin;%path%
ssh-agent rxvt -e bash --login -i
Another problem I am facing is trying to get vi to work in my cygwin bash shell. Setting term to xterm or vt100 does not work. Hitting enter, I see a string 78 or some other issue pops up. I have never modified my .inputrc.
My main issue was trying to get vi to work properly. I just found out that if I run
/etc/postinstall/terminfo.sh.done , I can now navigate properly in vi. The 78 (newline) M still appears but at least I can navigate in vi.
Feb 25 - This problem went away after a few windows updates. Would it make sense to ANSWER my question on the basis that this is longer reproducible?
Can't answer the first question, but have you tried invoking rxvt from its shortcut in the Cygwin folder of the start menu?
Regarding the second question, the TERM variable tells applications what terminal they're running in, so if you set it to 'xterm' while running in the Cygwin console (where normally TERM=cygwin), they'll be sending xterm control sequences that the Cygwin console doesn't understand. So basically: don't do that!
Btw, you might also be interested in Cygwin's mintty package, which is another terminal that doesn't need an X server. Installing it also creates a start menu shortcut in the Cygwin folder.
I would assume you need an X server running.
You could install Cygwin/X
One thing which may not have been clear was that the whole exercise was to get vi to work. vim did not work either at that time. But after some windows update, the problem went away. Closing it...