Background
I was having dual boot issues with Windows 10 and Ubuntu 17.10, which eventually resulted in a boot loop and since I need Ubuntu 16.04.3 for an Operating Systems class I decided to load up an ISO into one of my USBs with Rufus, reformat my Windows partitions from GPT to NTFS to get around some nasty bootmg/efi issues and here we are, good as new, except for one thing...
Problem
The only thing I haven't been able to successfully reinstall has been Latex Suite for Vim. Installation last time had been an easy extraction into .vim, but after some deliberation I elected to use Pathogen.
I've installed Pathogen using
mkdir -p ~/.vim/autoload ~/.vim/bundle && \
curl -LSso ~/.vim/autoload/pathogen.vim https://tpo.pe/pathogen.vim
Which works for color schemes, etc., and every other aspect of latex-suite save for compiling, generating this every time I try to compile (using \ll):
/bin/bash: latex: command not found
I installed texlive which does then allow me to compile using vim, but I'd prefer not to use this solution if I don't have to (in fact I've already removed it, its more of a plan b for now given it's obstructive and non-intuitive compilation errors). I looked at the other questions asking how to install Latex Suite through pathogen and didn't see anything else similar to what I'm working on; below is self-explanatory in regards to installation structure.
~/.vim/bundle$ ls
vim-archery vim-latex-1.10.0
Obvious running pdflatex and latex can't be found because they are not in my $PATH but I was under the impression that with a good, recommended package manager like Pathogen I wouldn't need to which is what originally raised the red flag for me as its whole job is to modify the runtime path. I thought maybe trying sudo vim text.tex might work in case there hadn't been adequate permissions for Pathogen to modify runtime path but no dice.
.vimrc
execute pathogen#infect()
syntax on
filetype plugin indent on
colorscheme archery
let g:tex_flavor='latex'
set sw=2
Related
I'm trying to use Steel Bank Common Lisp with GVim.
I installed Steel Bank Common Lisp (AMD64) into 'C:\Program Files\Steel Bank Common Lisp'.
I unzipped SLIMV into 'C:\vimfiles'
I installed Python3 and put it in Windows PATH.
I installed Python 2.7 and put it in Windows PATH.
I installed 64-bit GVim and finally got Python recognized.
I ran ':helptags C:/vimfiles/doc' in Vim to generate help tags for SLIMV
I have a 'Slimv' menu at the top of the Vim window but no Repl menu.
g:slimv_lisp = sbcl
g:slimv_impl = sbcl
g:slimv_preferred not set
g:slimv_lisp not set
g:slimv_swank_cmd not set
Per webpages and manual, I put this in my vimrc file
let g:slimv_swank_cmd = '!start "c:\Program Files\Steel Bank Common Lisp\sbcl.exe" -l "c:\Users\epic\vimfiles\slime\start-swank.lisp"'
I don't know if that's supposed to be 'set' instead of 'let'.
(start_swank) doesn't do anything inside SBCL.
I assume '!start' is a Vim command, the first thing passed is the location of SBCL on my computer, don't know what the '-l' does, and the third parameter is where SLIMV put 'start-swank.lisp'.
At this point, the Vim command ',c' will open a command window running SBCL and wait. Typing '(exit)' in SBCL will take me back to Vim with a red error message saying 'SWANK server is not running, Press ENTER to continue."
Any other documentation I can find is for SLIME, not SLIMV.
How can I get SLIMV running so I can use Vim for SBCL?
EDIT:
Thank you for the help as to what I'm telling to do what, romaini. Thanks for the slimv help, Tamas.
I have removed the g:slimv_swank_cmd entry in .vimrc, as I believe it does the same thing by itself that it would if I had the command right.
Now, I think I'm back to the problem I was trying to fix with that command, and that might be that SBCL is not working for me (?). Without the g:slimv_swank_cmd setting in .vimrc, Vim starts SBCL which then fails because COMPILE-FILE returns NIL when evaluating line 16 of start-swank.lisp. Vim will then report "SWANK server not running" while SBCL is at a debug screen asking whether to RETRY, CONTINUE, ABORT,,,, or EXIT.
Could it be that slimv is working well but SBCL is not working? I'm still trying in Vim to either compile a program (* 3.0 4.0), evaluate the line, or just connect-server ',C'.
EDIT2:
Trying to install a newer version of slimv from GitHub, I'm afraid we've hit the end of my capabilities. The Readme says to install the zip, reading the whole thing says see internal docs for more, and the internal docs say unzip the zip file in the vimfiles directory. There are lots of files on Github but I don't see a zip.
EDIT3:
With slimv-master.zip from github extracted to .vimfiles, I get the same error that "COMPILE-FILE returned NIL" while evaluating line 16 of ./slime/start-swank.lisp.
EDIT4:
Apparently, the SBCL download went from v2.2.0 to V2.2.1 since 01-26-22. I'm on a 64-bit Windows 10 machine and my SBCL download is automatic from SourceForge after clicking Windows-AMD64 here. I have the same issue, ./slime/swank/sbcl.lisp returns NIL from line 16 where COMPILE-FILE returns NIL. It is starting SBCL v2.2.1 now.
EDIT5:
Both my versions of slimv were extracted to ./vimfiles/. My ./vimfiles/slime/slime.el is Version 2.19. Did the newer slimv version not overwrite files when extracting to ./vimfiles/? Is there an uninstall when we're just extracting zips to ./vimfiles/?
EDIT6:
I don't have a check mark next to comments to mark the last of Tamas Kovacs' responses as the answer (as was the rest of his help through the comments). I now have a REPL window in Vim and Tamas solved my issue.
I summarize the results of our investigation (see comments above):
No need to set slimv option g:slimv_swank_cmd, because slimv should autodetect sbcl and build the correct start command for the swank server.
If autodetection fails or you want to make your own start command for any other reason, then you should use the --load switch (instead of -l) for loading a script into sbcl (the switch depends on the lisp implementation). On Windows machines I also suggest adding /MIN to the !start command, that would start the swank server minimized. This is an example start command for starting sbcl on Windows:
'!start /MIN "c:\Program Files\Steel Bank Common Lisp\sbcl.exe" --load "c:\Users\epic\vimfiles\slime\start-swank.lisp"'
Unfortunately vim.org has an outdated version of slimv, and recent changes in sbcl broke compatibility with the swank server contained in that slimv version. Therefore I strongly recommend that you download or checkout slimv directly from the github repository: https://github.com/kovisoft/slimv
When downloading the slimv-master.zip file from github and manually installing it, make sure that you extract the files from the zip to the proper subdirectories of the vimfiles folder of vim. This means that the contents of slimv-master\ftplugin should go into vimfiles\ftplugin, slimv-master\slime should go into vimfiles\slime, etc. In other words the slimv-master directory in the zip represents the vimfiles directory on your system. Of course this also holds when you install slimv by checking it out from github.
Recently I decided to delve into Vim after looking for a new text editor after adopting a Linux distro as a secondary operating system. I've installed Powerline as it seems the norm to do and for about 20 minutes I had it fully working (until I closed Vim), though after that (about a week ago) they failed to appear again (pretty sure they were just separators, not actual symbols - although that coming from me is entirely unqualified).
I've followed just about every fix I could find under the Sun, followed the documentation on font patching etc, nothing seems to be working.
I'm sure it's a stupidly easy fix and I'm just a bit too dull to find it, but hopefully I can fix it somehow as it's really, really bugging me.
Have a good Christmas!
PS. I just registered (I could've sworn I already had an account though apparently not), so I'm unable to post images. But I'll do my best to explain it: On the left of the status bar you have the mode, then next to that it the first symbol error (again, it might not even be a symbol error, I'm just going off what I think was my issue online), it's a rectangle (portrait) with 2B80 in it, after that there's the filename, and immediately after is the very same rectangle with the same code in it. But there are other errors as stated in the title such as 2B83 and 2B61, as well as just 28.
I'd imagine they are supposed to be separators as they're after every segment of the status bar, but I have no idea. I'm stumped.
Thanks for any/all help!
Apparently I was following some outdated instructions. This worked fine for me:
Completely remove anything I'd already done with the modification (a
fresh start)
sudo apt-get install python-pip
pip install --user git+git://github.com/Lokaltog/powerline
Add the following to your .vimrc
python from powerline.vim import setup as powerline_setup
python powerline_setup()
python del powerline_setup
set laststatus=2
call vundle#end() (only applicable if you use Vundle)
You should then download the latest version of the Powerline Symbols OpenType font (use the commands below)
cd ~
wget https://github.com/Lokaltog/powerline/raw/develop/font/PowerlineSymbols.otf
Move the downloadef file to one of your font directories (either ~/.local/share/fonts/ or ~/usr/local/share/fonts as ~/.fonts is deprecated and won't be used in future versions).
mv PowerlineSymbols.otf ~/.local/share/fonts
Update your system's font chahe
sudo fc-cache -f -v
Download and move the fontconfig file to ~/.fonts.conf
wget https://github.com/Lokaltog/powerline/raw/develop/font/10-powerline-symbols.conf
Create a per-user fontconfig folder if it doesn't already exist
mkdir -p ~/.config/fontconfig/fonts.conf
mv 10-powerline-symbols.conf ~/.config/fontconfig/fonts.conf/
Again, this worked for me, can't guarantee that it will for others but it certainly worked charms for me.
Hi i have vim6 and upgraded to vim7.
I have both versions. vim6 runs fine.
Upgraded vim7 runtimepath has
/usr/local/share/vim/... this path does not exist, contain anyfiles
I am trying to get the colorscheme to work. When I set syntax on, I get that /usr/local/share/vim/syntax/syntax.vim not found error.
So i found the syntax.vim at ~/vim/runtime/syntax/syntax.vim
So I updated the runtimepath using
execute pathogen#infect('bundle/{}', '~/vim/runtime/{}')
the old vim still works, and has updated runtimepath. the new vim73 still has the updated runtimepaths , but when on syntax on it gives an error looking for the file at the old path that never existed.
so how do i remove path from the runtimepath
i also
thanks
edit
upgrade was to 7.4 from 7.3.547
compiled with python as follows:
./configure --enable-pythoninterp --with-features=huge --with-python-config-dir=/usr/lib/python2.7/config-x86_64-linux-gnu/
make
hack
whats wrong with just ln -s ~/vim/runtime/ /usr/local/share/vim/ ?
or just copy the file that i need to get syntax, and hopefully color ..
With a path of /usr/local/share/..., it looks like you've compiled Vim yourself from the sources. sudo make install should have taken care of the copying of the runtime files to that location. What you did with Pathogen is definitely not the right way to fix it.
Unless you're on a very old or poorly maintained Linux distribution, it should be possible to obtain a current Vim package (that is, a 7.4 version) through your distribution's package manager (on Debian-based systems, it's commonly called vim-gnome). Unless you need to have the bleeding edge version (unlikely in your case with the former Vim 6), or incorporate custom patches, that is the easy and recommended approach.
I'm using Vim/Cream on Win7 with the Vim binaries provided with Cream (v7.3.107), and have installed Vundle, and the plugins work fine after I run :BundleInstall. But after exiting and restarting, the plugins don't work until I run BundleInstall again. Is this normal? I thought BundleInstall was a one-time command (excepting when used for updates). Here's an excerpt of what I have in my vimrc (actually cream-user.vim, which is what Cream prefers):
set nocompatible
filetype off
set runtimepath+=$HOME/vimfiles/bundle/vundle/
call vundle#rc()
Bundle 'gmarik/vundle'
" Your bundles go here:
"
" ORIGINAL REPOS ON GITHUB
Bundle '907th/vim-auto-save'
.
However, when I run :AutoSaveToggle (a vim-auto-save command), I get the following error:
E492: Not an editor command: AutoSaveToggle
.
The cream-user.vim file is being invoked (it's listed in scriptnames):
83: C:\Users\<MyUserName>\.cream\cream-user.vim
[...]
85: C:\Users\<MyUserName>\.vim\bundle\vundle\autoload\vundle.vim
86: C:\Users\<MyUserName>\.vim\bundle\vundle\autoload\vundle\config.vim
.
...and Vundle itself is installed, as its commands work, notably :BundleList, which lists vim-auto-save among the installed bundles:
" My Bundles
Bundle 'gmarik/vundle'
Bundle '907th/vim-auto-save'
After I re-run BundleInstall, the plugins start working, and I do notice scriptnames now includes the extra files:
125: C:\Users\<MyUserName>\.vim\bundle\vundle\autoload\vundle\installer.vim
126: C:\Users\<MyUserName>\.vim\bundle\vundle\autoload\vundle\scripts.vim
127: C:\Users\<MyUserName>\.vim\bundle\vim-auto-save\plugin\AutoSave.vim
Putting :BundleInstall in the .vimrc doesn't look like the right move either, as it opens a buffer (can be worked around, but still...). I'm a brand new to Vim so I'm not sure what's wrong, probably something simple on my end, like my not being clear on how to appropriately invoke vundle. Any ideas on how to fix this?
First: You're right, :BundleInstall is not required on every launch. I guess the behavior you're seeing has to do with the Cream customizations; it probably messes with 'runtimepath' itself, and therefore interferes with Vundle.
If you just chose Cream for an easy install of Vim (though your 7.3.107 is quite dated already), there's also a "Vim-only" installer. Also, a Vim 7.4 installer is available from http://www.vim.org/download.php.
In case you do want Cream (wouldn't recommend that; especially if you're into programming / customizing Vim with plugins), I'd open an issue with the Vundle project, asking for help / support of Cream.
I had a similar problem with MacVim. The problem for me was that I didn't follow the instructions closely enough. I just assumed that I could just put the Vundle lines in my .gvimrc. This was WRONG! The solution, as per the instructions, was to place the lines in the .vimrc file. The order of operations matters, and it's possible this matters for Cream.
I found a solution to this problem in this bug report: https://github.com/gmarik/Vundle.vim/issues/430
At the end of your cream-user.vim file, add:
call vundle#config#require(g:bundles)
This causes the plugins to be loaded without showing the Vundle\Installer buffer at startup.
I've installed a fresh Arch Linux system on my laptop and downloaded the vim package.
I haven't altered the .vimrc file, but the syntax highlighting doesn't seem to work with any of the languages I tried (Python, Ruby, CSharp, C...).
Auto formatting (gg, =, G) also fails.
Until now when playing with vim (because I can't really say I've extensively used it) in other OSs (Ubuntu, Fedora), the syntax highlighting came on automatically.
Is there something I am missing here?
You need to have following settings in .vimrc file as per arch linux documentation
filetype plugin on
syntax on
This is the absolute minimum you need to put in your ~/.vimrc if you intend to use vim as your primary editor:
" activates filetype detection
filetype plugin indent on
" activates syntax highlighting among other things
syntax on
" allows you to deal with multiple unsaved
" buffers simultaneously without resorting
" to misusing tabs
set hidden
" just hit backspace without this one and
" see for yourself
set backspace=indent,eol,start
Anything else depends on your taste, workflow and needs.
vi /etc/profile
alias vi=vim
maybe you use vi instead of vim
I had this problem in Opensuse Leap 42.2 cloud. And solved it by installing vim-data
sudo zypper install vim-data
or just re-installing vim will include vim-data automatically.
sudo zypper remove vim
sudo zypper install vim
Type
:syntax on
to get it to work. It is not a default option for vim. Probably in the other systems, it was set to on in the system default vimrc
Or put
syntax on
in ~/.vimrc
Another reason syntax highlighting won't work is you might have a theme/colorscheme set that VIM cannot find.
colorscheme darkblue
Either delete the line or comment it out:
"colorscheme darkblue
I had a similar problem. I could not have syntax highlighting on. I also found that gvim launched without pulldown menus or toolbar icons. It turned out I did not have the vim-runtime package properly installed. In my case I was on debian jessie with a large set of files missing under /usr/share/vim/vim74/ directory.
$ ls /usr/share/vim/vim74/
debian.vim doc/ rgb.txt
The solution was to run:
$ sudo aptitude reinstall vim-runtime
That fixed the problem for me, for syntax highlighting and for missing menus/icons in gvim. I'm not sure why my system was in this state, but the reinstall of the above package solved both issues.
in my case , I changed the term(terminal type) from vt100 to xterm. And it works.
To change the terminal type:
in bash:
export TERM=xterm
in bourne shell or ksh:
TERM=xterm
export TERM
in csh or tcsh:
setenv TERM xterm
On my Ubuntu 18.04 system i.e. c-highlighting works but Icinga2 config file highlighting being provided by the vim-icinga2 package does not. Quote from https://packages.debian.org/sid/vim-icinga2:
As per the Debian vim policy, installed addons are not activated automatically, but the "vim-addon-manager" tool can be used for this purpose.
Executing vim-addon-manager -w install icinga2 following a regular vim-icinga2 package installation solved the issue. The -w option forces a system wide rather than a just per current user activation. Notice that executing vim-addon-manager without arguments yields a list of 39 modes being disabled by default:
> vim-addon-manager
# Name User Status System Status
align removed removed
alternate removed removed
...
icinga2 removed installed # Due to above command
...
If you do miss highlighting chances are your mode is among this list.
NB: Ubuntu 18.04 seemingly inherits Debian's policy. None of the above answers solved my issue. No ~/.vimrc configuration or manual activation was being required after the above described activation.