After following some tutorials i tried to use exuberant ctags to autocomplete e.g. openGL functions. I used the command
ctags -R --languages=C,C++ --c++-kinds=+p --fields=+iaS --extra=+q ./
in the directory where the freeglut.h, glew.h etc resides. Then copying this to a directory pointed by in the .vimrc file (with 'set tags+=./myTag/tags' in my .vimrc)
When I try to autocomplete some glut functions i dont get the funciton parameters listed, only the function itself gets completed, but without the parameters.
On the other hand, when Im applying the ctags command above to a .cpp file in the same directory where my main file resides it autocompletes with the function parameters.
Im probably missing some essential information here.
Firstly, I'm tired of managing ctags by hand, and I wrote plugin Indexer for that. It provides painless automatic tags generation and keeps tags up-to-date. For detailed information, see the article: Vim: convenient code navigation for your projects, which explains the usage of Indexer + Vimprj thoroughly.
And secondly, for code autocompletion, I suggest you to use clang_complete. It provides real, perfect C/C++/Objective-C completion from true compiler, not ugly method by tags.
In your .vimrc file, before adding the tag files, add the directory. So if you added the tage in $HOME/.vim/tags directory you need to add the following line
set tags=~/.vim/tags
The section (in your .vimrc) referred to OmniCppComplete may be something like this:
" configure tags - add additional tags here or comment out not-used ones
" Setting the directory...
set tags=~/.vim/tags
" Adding the tag files
set tags+=~/.vim/tags/cpp
set tags+=~/.vim/tags/gl
set tags+=~/.vim/tags/sdl
set tags+=~/.vim/tags/qt4
" set tags+=$HOME/.vim/tags/standard
" build tags of your own project with Ctrl-F12
map <C-F12> :!ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q .<CR>
" OmniCppComplete
let OmniCpp_NamespaceSearch = 1
let OmniCpp_GlobalScopeSearch = 1
let OmniCpp_ShowAccess = 1
let OmniCpp_ShowPrototypeInAbbr = 1 " show function parameters
let OmniCpp_MayCompleteDot = 1 " autocomplete after .
let OmniCpp_MayCompleteArrow = 1 " autocomplete after ->
let OmniCpp_MayCompleteScope = 1 " autocomplete after ::
let OmniCpp_DefaultNamespaces = ["std", "_GLIBCXX_STD"]
" automatically open and close the popup menu / preview window
au CursorMovedI,InsertLeave * if pumvisible() == 0|silent! pclose|endif
set completeopt=menuone,menu,longest,preview
Related
I work on a documentation that will be published in different languages. It is one of the reasons I use Sphinx.
I know how generate the translated version but with the setting described in the documentation, the resulting files replaces the ones that were generated before. Thus, when generating multiple translation, I have to move the files to another directory before doing anything else. It would be more practical (and easier to deploy) to generate the translations in separate directories.
Is there a way to tell Sphinx or the makefile that when I run
make -e SPHINXOPTS="-D language='(lang)'" (format)
the files have to be generated in /build/(format)/(lang) ?
For now, only the HTML build is used (and I doubt that something else will be used) so a specific solution would be accepted if it is not possible to do it globally.
Sphinx version is 1.4.6.
I found a working solution by replacing the Makefile by a custom Python script (build.py).
Using sys.argv, I emulate the make target behaviour. I added several options for the language. Using the subprocess module, precisely its call() function, I am able to run commands with a set of options. The script is based on a function that generates the command to be executed by subprocess.call():
def build_command(target, build_dir, lang=None):
lang_opt = []
if lang:
lang_opt = ["-D", "language='" + lang + "'"]
build_dir += "/" + lang
else:
build_dir += "/default"
return ["sphinx-build", "-b", target, "-aE"] + lang_opt + ["source", "build/" + build_dir]
It is the lang parameter that allows me to separate each language, independently of the target. Later in the code, I just run
subprocess.call(build_command(target, target, lang))
To build the documentation in the desired language with the specified target (usually, target = "html"). It can also emulate make gettext:
subprocess.call(build_command("gettext", "locale"))
And so on...
A better solution may exist, but at least this one will do the job.
I am keeping notes in console vim on my laptop, and
I want to add syntax highlighting to my notes in order
to enhance them. However, I don't want to add a
million different filetypes for every area of knowledge
(for example my notes on compilers would have different
keywords than my notes on the FHS), and I also want to
make it easy to share these notes. After doing some
research, I discovered that I can get the behavior I
want, but it doesn't seem like a very elegant solution.
I added the following lines to my .vimrc:
if (filereadable("./.custom_syntax.vim")
let mysyntaxfile = "./.custom_syntax.vim"
syntax enable
else
syntax enable
endif
I don't really like this solution because it still
requires me to ask them to modify their .vimrc, but I
suspect that there's no way to do this without changing
anything on their system. Additionally, if I have any
files in the directory that aren't notes, vim will still
highlight them with the .custom_syntax.vim file because
I don't know what the filetype is.
Is there any better way to accomlish this?
Instead of using the old mysyntaxfile variable, I'd just :syntax enable (once) and then :source the syntax file. You can define an :autocmd that looks for an eponymous Vimscript file next to the original:
" Automatically source an eponymous <file>.vim or <file>.<ext>.vim if it exists, as a bulked-up
" modeline and to provide file-specific customizations.
function! s:AutoSource()
let l:testedScripts = [expand('<afile>') . '.vim']
if expand('<afile>:e') !=# 'vim'
" Don't source the edited Vimscript file itself.
call add(l:testedScripts, expand('<afile>:r') . '.vim')
endif
for l:filespec in l:testedScripts
if filereadable(l:filespec)
execute 'source' fnameescape(l:filespec)
endif
endfor
endfunction
augroup AutoSource
autocmd! BufNewFile,BufRead * call <SID>AutoSource()
augroup END
You do need this or something like this in your Vim configuration, though.
I'm using Sphinx on Windows.
Most of my documentation is for regular users, but there are some sub-pages with content for administrators only.
So I want to build two versions of my documentation: a complete version, and a second version with the "admin" pages excluded.
I used the exclude_patterns in the build configuration for that.
So far, it works. Every file in every subfolder whose name contains "admin" is ignored when I put this into the conf.py file:
exclude_patterns = ['**/*admin*']
The problem is that I'd like to run the build once to get both versions.
What I'm trying to do right now is running make.bat twice and supply different parameters on each run.
According to the documentation, I can achieve this by setting the BUILDDIR and SPHINXOPTS variables.
So now I have a build.bat that looks like this:
path=%path%;c:\python27\scripts
rem BUILD ADMIN DOCS
set SPHINXOPTS=
set BUILDDIR=c:\build\admin
call make clean
call make html
rem BUILD USER DOCS
set SPHINXOPTS=-D exclude_patterns=['**/*admin*']
set BUILDDIR=c:\build\user
call make clean
call make html
pause
The build in the two different directories works when I delete the line set BUILDDIR=build from the sphinx-generated make.bat file.
However, the exclude pattern does not work.
The batch file listed above outputs this for the second build (the one with the exclude pattern):
Making output directory...
Running Sphinx v1.1.3
loading translations [de]... done
loading pickled environment... not yet created
Exception occurred:
File "C:\Python27\lib\site-packages\sphinx-1.1.3-py2.7.egg\sphinx\environment.
py", line 495, in find_files
['**/' + d for d in config.exclude_dirnames] +
TypeError: coercing to Unicode: need string or buffer, list found
The full traceback has been saved in c:\users\myusername\appdata\local\temp\sphinx-err-kmihxk.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>.
What am I doing wrong?
Is the syntax for exclude_patterns in the sphinx-build command line different than in the conf.py file?
Or is there a better way to build two different versions in one step?
My first thought was that this was a quoting issue, quoting being notoriously difficult to get right on the Windows command line. However, I wasn't able to come up with any combination of quoting that changed the behavior at all. (The problem is easy to replicate)
Of course it could still just be some quoting issue I'm not smart enough to figure out, but I suspect this is a Sphinx bug of some kind, and hope you will report it to the Sphinx developers.
In the meantime, here's an alternate solution:
quoting from here:
There is a special object named tags available in the config file. It can be used to query and change the tags (see Including content based on tags). Use tags.has('tag') to query, tags.add('tag') and tags.remove('tag') to change
This allows you to essentially pass flags into the conf.py file from the command line, and since the conf.py file is just Python, you can use if statements to set the value of exclude_patterns conditionally based on the tags you pass in.
For example, you could pass Sphinx options like:
set SPHINXOPTS=-t foradmins
to pass the "foradmins" tag, and then check for it in your conf.py like so:
exclude_patterns = blah
if tags.has('foradmins'):
exclude_patterns = []
That should allow you to do what you want. Good Luck!
I'm using Vim with a bunch of plugins (pathogen, ctags, snipmate, supertab, ...), and everything works fine for all kinds of file extensions.
However, when I'm try to edit .tex files it presents two problems which seem related. First, Vim starts to work really slow, and second, when I press "any letter + Tab", it tries to auto-complete with words previously written in the text.
One way which I tried to solve those issues, is by removing the supertab plugin from my bundle folder, but it's a not satisfactory solution.
The problem is due to the relativenumber option, when I turned it off the latex edit speed come back to normal.
The following relativenumber, cursorline and MatchParen can slow vim down a lot, especially when dealing with large latex files. When I turn them off then vim becomes much more responsive when dealing with large latex files.
To turn off relative number, type the following in editor mode:
:set nornu
To turn off cursorline, type the following in editor mode:
:set nocursorline
To turn off MatchParen, type the following in editor mode:
:NoMatchParen
If you still want regular line numbering then you can have
:set number
For a more permanent solution, you can also set latex specific settings in your ~/.vimrc file:
" Latex specification
au BufNewFile,BufRead *.tex
\ set nocursorline |
\ set nornu |
\ set number |
\ let g:loaded_matchparen=1 |
The \ and the | are there to allow you add the latex commands over multiple lines.
The other two possible problems are the following being active
cursorline
DoMatchParen
So to make your LᴬTᴇX editing experience much better, you can do something like the following in your ~/.vimrc
au FileType tex setlocal nocursorline
au FileType tex :NoMatchParen
After doing this my Vim is as fast with .tex files as it is with .cpp ones.
I know this is an old issue, but, to anyone seeing this now, it is better to use the ftplugin/ folder in your .vim directory to instruct Vim to enable certain options on a specific file type. Create a file ~/.vim/ftplugin/tex.vim with the following options:
set nocursorline
set nornu
let g:loaded_matchparen=1
This makes Vim load these options only on TeX files (*.tex and related) without resorting to an :autocommand like gloriphobia’s answer does.
Folding is another common source of slowdown. It is normally disabled by default, but perhaps you have enabled it. You can just disable it again:
" (1) if you use the builtin TeX support:
" comment the line in your vimrc that looks like this:
"let g:tex_fold_enabled = ...
" OR, just to be sure, do:
unlet! g:tex_fold_enabled
" (2) if you rather use VimTeX:
" comment the line in your vimrc that looks like this:
"let g:vimtex_fold_enabled = 1
" OR, just to be sure, do:
let g:vimtex_fold_enabled = 0
Note that folding must be enabled/disabled before TeX syntax is loaded in the buffer. Also, Vim option 'foldenable' (toggled by the normal-mode command zi) does not actually clear folding, it just hides it but it’s still there).
However, if you don’t want to give up on folding altogether, I found a single bottleneck in the builtin TeX folding that was responsible for most of the slowdown in my case: the document environment. Simple test: typing stuff just before \begin{document} is reasonably fast, but typing right after it is amazingly laggy. I guess it happens because that environment commonly spans hundreds of lines.
If you use the builtin TeX folding, you can prevent the folding of just the document environment by disabling the texDocZone matchgroup¹. Anyway, why would you want to fold the toplevel contents?
" put this in your vimrc :
au FileType tex :syntax clear texDocZone
" OR put this in ~/.vim/after/syntax/tex.vim :
syntax clear texDocZone
Alternatively, if you have VimTeX, you can replace the builtin TeX folding with the VimTeX’ one. I find it generally better, and it carefully avoids folding the document environment.
" put this in your vimrc :
unlet! g:tex_fold_enabled " just to be sure
let g:vimtex_fold_enabled = 1
VimTeX’ folding is nicely customizable, see :help vimtex-folding.
¹ As of version 121 (April 2022) of the builtin TeX syntax.
I've recently started using ctags on my projects. I currently have the following setup:
root/tags [contains all non-static tags]
root/foo/tags [contains static tags for the foo directory]
root/bar/tags [static]
root/something/else/tags [etc.]
...
I can set tags=./tags,tags,/path/to/root/tags and everything works perfectly.
However, my problem is that I work on several projects at once, so I have, for example, /path/to/root1, /path/to/root2, and /path/to/root3 all at once. I'd rather not manually set the tags each time I open a file; is there any way I can have tags to to the /path/to/rootX based on the file I'm editting? (i.e., if I'm editing /path/to/root3/foo/x.c, use the tags in root3/tags?
In my case, all of my projects share a common parent directory; what I really want is something like:
set tags=./tags,tags,substitute("%:p:h", "\(^\/path\/to\/.*/\).*$", "\1", "")
but I can't seem to get the right vimfu to make it work.
EDIT: I just realized that this won't work; I can't actually write to root*. Instead, I'd like to store my main ctags file in ~/ctags/root*/tags, where there's a 1:1 mapping between the subdirectories of ~/ctags/ and /path/to/ [For those who may be wondering, these are ClearCase UCM dynamic views; neither /view/XXX/ nor /view/XXX/vobs/ is writable]
If what you want is:
set tags=./tags,tags,substitute("%:p:h", "\(^\/path\/to\/.*/\).*$", "\1", "")
Try:
let &tags = './tags,tags,' . substitute(expand("%:p:h"), "\(^\/path\/to\/.*/\).*$", "\1", "")
There's no expansion in a :set command. Also, "%:p:h" won't be expanded automatically, so use expand(). See:
:help :let-option
:help expand()