There's no built in support for highlighting your own macros and enums
etc. Have a look at my plugin
(http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highlighting),
which adds this feature (using ctags). If you have any problems
getting it setup, please let me know.
Al
stone wrote:
> "A. S. Budden" wrote:
>> stone wrote:
>>
>> > Hi. vim_use
>> > I use GVIM in windows to edit C/C++ program,
>> > But the MACRO and ENUM I have defined can not highlight.
>>
>> > I have set the : sy on and sy enable in my vimrc file.
>>
>> There's no built in support for highlighting your own macros and enums
>> etc. Have a look at my plugin
>> (http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highl...),
>> which adds this feature (using ctags). If you have any problems
>> getting it setup, please let me know.
>
> Very Thanks.
>
> Your plugin is the one which I want.
> I have download the ctags-highlight plugin.
>
> But , when I input the command: UpdateTypeFile.
>
> There are some errors like:
>
> Error detected while processing function UpdateTypesFile:
> line 23:
> E684: list index out of range: 0
> E15: Invalid expression: split(globpath(&rtp,"ctags.exe"))[0]
> line 29:
> E605: Exception not caught: Cannot find ctags
>
> what this means?
This means that the plugin isn't looking for ctags.exe in PATH (which
may be a bug?). Instead, it's looking in &runtimepath. Try running the
command
:set runtimepath?
to see the list of directories that the plugin is looking in to find
ctags.exe, and put it in one of those directories (probably
$HOME/vimfiles is the best choice).
> I use Gvim 7.2 in windows XP. and I have put ctags.exe in c:\Windows
> \System32, so I can use ctags in command console.
~Matt
The plugin looks first for ctags.exe in the path and if it doesn't
find it there, it looks in the runtimepath.
I have ctags.exe installed in the \vim\vimfiles directory (so that it
works if I copy it to a USB stick and I don't have to put ctags on the
path of every machine I use) and it's been while since I tested it
with ctags in a normal path. I won't have access to a Windows machine
until Monday, but I'll do some more testing when I'm there and will
make sure that this works correctly.
As an aside, the fact that the exception isn't caught is a bug (and a
simple one to fix), but I'm surprised it doesn't find ctags in the
path if it's in C:\Windows\System32.
If you could let me know the output of:
:echo substitute($PATH, ';', ',', 'g')
then I can probably work out what's happening a bit quicker.
Al
Please bottom post on this list. Quote a small (relevant) part
of the message you are replying to, and put your text underneath.
See
http://groups.google.com/group/vim_use/web/vim-information
Find out what the above means before posting on this list.
I've just added a preliminary test version (with a few bug fixes) to
my site (http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highlighting).
Please could you download this version and see whether it works (I've
only updated ctags_highlighting.vba)? If it doesn't, it would be
useful to see the debugging output that this version includes: enter
the following:
:redir > ctags_hl_output.txt
:let g:CTagsHighlighterDebug = g:DBG_Information
:call UpdateTypesFile(1,0)
:redir END
This will create a file called ctags_hl_output.txt in the current
directory with some useful debugging information. If you could post
this file then I should be able to work out where it's going wrong.
Thanks,
Al
I've just added a preliminary test version (with a few bug fixes) to
my site (http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highlighting).
Please could you download this version and see whether it works (I've
only updated ctags_highlighting.vba)? If it doesn't, it would be
useful to see the debugging output that this version includes: enter
the following:
:redir > ctags_hl_output.txt
:let g:CTagsHighlighterDebug = g:DBG_Information
:call UpdateTypesFile(1,0)
:redir END
This will create a file called ctags_hl_output.txt in the current
directory with some useful debugging information. If you could post
this file then I should be able to work out where it's going wrong.
Thanks,
>I've just added a preliminary test version (with a few bug fixes) to
>my site (http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highlighting).
> Please could you download this version and see whether it works (I've
>only updated ctags_highlighting.vba)? If it doesn't, it would be
>useful to see the debugging output that this version includes: enter
>the following:
This is indeed very strange. The problem is coming from globpath( )
as far as I can tell: it doesn't think that the file exists. Your
path looks correct (and in the right format for globpath), so it's
bizarre that it can't find ctags.exe. Please can you try the
following?
:redir > logfile.txt
:let path = substitute($PATH, ';', ',', 'g')
:echo "Bare Path:"
:echo $PATH
:echo "Path:"
:echo path
:echo "Path Glob:"
:echo globpath(path, 'ctags.exe')
:echo "Winsys Glob:"
:echo globpath('c:\windows\system32', 'ctags.exe')
:echo "Path Glob for xcopy.exe:"
:echo globpath(path, 'xcopy.exe')
:echo "Winsys Glob for xcopy.exe:"
:echo globpath('c:\windows\system32', 'xcopy.exe')
:echo "Readable?"
:echo filereadable('c:\windows\system32\ctags.exe')
:redir END
Sorry for the tedious entry: as an alternative, save all of that to a
file (e.g. c:\testfile.vim) without the leading colons and do:
:source c:\testfile.vim
We'll get to the bottom of this in the end!
> PS:
> I have make the tag file for all symbol by use awk command. And save these
> symbols to the tag_highlight.hi file.
> Then in my _vimrc I add thiese sentences:
> if filereadable("tag_highlight.hi")
> autocmd BufRead,BufNewFile * so tag_highlight.hi
> endif
> So I can highlight my symbols in my code. But I feel some slowly when I open
> my code file.
> How about your plugin?
> Is it using the same method?
> Will it create a tag symbol file?
> Will it make it slowly when open code file?
My plugin uses a similar method (it runs ctags, then parses it using
python to generate a symbol file). It probably adds a little delay
opening the code file, but I don't really notice it. It obviously
depends on the number of symbols and how you are doing the
highlighting. It's important that you use "syn keyword" instead of
"syn match" (as the latter is much slower) and it is beneficial to put
multiple keywords on one line (although there is a line length limit
that must be obeyed as well) in order to reduce the size of the
highlight file.
Hope that helps,
Al
Removing the colons isn't necessary, so - for the purpose of easy
copy-pasting of a one-off script - I would just leave them in
c:\testfile.vim
~Matt
Okay! I think I've figured out what's going on. Please can you
download the latest version from
http://sites.google.com/site/abudden/contents/Vim-Scripts/ctags-highlighting
and let me know whether it works?
There's a note (that I'd previously missed) in :help globpath() that
says "Note that on MS-Windows a directory may have a trailing
backslash, remove it if you put a comma after it.". I think that the
first entry in your path (which ends in a backslash) was being treated
as a single path: "C:\Program Files\PC Connectivity
Solution,C:\WINDOWS\system32", which doesn't make sense. As a result,
C:\WINDOWS\system32 wasn't being searched. Therefore, I've changed
the path substitution to:
let path = substitute($PATH, '\\\?;', ',', 'g')
which removes any trailing backslash at the same time as adding the
comma. Hopefully this will fix the problem.
>> My plugin uses a similar method (it runs ctags, then parses it using
>> python to generate a symbol file). It probably adds a little delay
>> opening the code file, but I don't really notice it. It obviously
>> depends on the number of symbols and how you are doing the
>> highlighting. It's important that you use "syn keyword" instead of
>> "syn match" (as the latter is much slower) and it is beneficial to put
>> multiple keywords on one line (although there is a line length limit
>> that must be obeyed as well) in order to reduce the size of the
>> highlight file.
>> Hope that helps,
> Thank you for your advise. And How about one line length limit?
I think it's 512 characters (based on re-reading mktypes.py).
Hopefully with the fixed version of my plugin, you won't need it
though!
Al
There are three possibilities that I can think of:
1) The problem may be that you don't have the various colour groups
defined in your colour scheme. If I'm correct, entering the following
should help:
:hi Type guifg=blue ctermfg=blue
A quick test would be to enter: ":hi DefinedName" and see whether it
reports an error. See ":help ctags_highlighting-colours" for more
information.
The above will, of course, only highlight types, but it's a good way
of quickly testing it. If this works, the full list of highlight
groups that need to be defined are:
ClassName
DefinedName
Enumerator
Function
EnumerationName
Member
Structure
Type
Union
GlobalConstant
GlobalVariable
A quick (but not necessarily appealing to you) way of getting all of
these defined is to download my "Bandit" colour scheme from:
http://sites.google.com/site/abudden/contents/Vim-Scripts/bandit-colour-scheme
(save to vimfiles/colors and enter :colorscheme bandit). Of course,
this will override your colour scheme and you may not like mine!
2) A second possibility is that the generated types file isn't being
read correctly. If this is the case, ":source types_c.vim" will fix
the problem temporarily, but we'll need to look in a bit more detail
to identify why it isn't being read automatically.
3) The other possibility is that types_c.vim doesn't contain the
necessary entries (check by opening it in vim). The most common
reason for this is that the source and header files are spread over
multiple directories and the recursive option wasn't selected. If
your files are all in one folder, make sure you run ":cd %:p:h" before
you run :UpdateTypesFile (to make sure you're in the correct working
directory). If they're spread out like this:
c:/path/to/ProjectDir/Source/*.c
c:/path/to/ProjectDir/Headers/*.h
or something like that, do ":cd c:/path/to/ProjectDir" then ":e
Source/MyFile.c" followed by ":UpdateTypesFile!" (note the exclamation
mark for recursive operation). Alternatively you do ":let
b:TypesFileRecurse = 1" for each buffer and then you won't need the
exclamation mark. If you use the project plugin, the CD= and in=
parameters make all of this very easy. Hopefully I'll tidy up the
options system in the ctags highlighting plugin very soon.
Please let me know how you get on: I'm really keen to see this working for you!
Regards,
Al
You don't have to use my colour scheme, but you will have to modify
the colour scheme to add the extra highlight groups. A very simple
way of doing this would be to add the following lines to the end of
desert.vim (it's probably better to copy it to your vimfiles/colors
directory):
hi link ClassName Statement
hi link DefinedName Statement
hi link Enumerator Statement
hi link Function Statement
hi link EnumerationName Statement
hi link Member Statement
hi link Structure Statement
hi link Type Statement
hi link Union Statement
hi link GlobalConstant Statement
hi link GlobalVariable Statement
> 2.
> I can not find types_c.vim in my directory.I guess the file should not been
> created.
> So How can I create this file.
This file should have been created by :UpdateTypesFile - the fact it's
not there is rather strange. How are your projects structured? Are
all the files in one directory or are they in a number of
subdirectories. If the latter, make sure you :cd to the bottom level
directory of the project and use :UpdateTypesFile! (note the
exclamation mark) to run recursively and include subdirectories.
Perhaps you could run the following and let me know the output:
:redir @+>
:call UpdateTypesFile(1,0)
:redir END
(this will redirect the output into the system clipboard, so you can
then paste it into an email).
> 3.I have not tried yet.
Please let me know how you get on with the above.
Al
Excellent, I'm really pleased!
> It is a very good plugin. The tags file it created run faster than my tags
> file.
> I add the "hi link" and run the command UpdateTypeFile!. So it can work. It
> is my mistake do not prepare the color scheme.
[snip]
> One question. When I add or modify my define such as MACRO. Should I need
> run the UpdateTypeFile! again?
Yes, it only works if you tell it to update the files.
> Do you have good way to run the command auto or timely?
At the moment, no. I tend to find that I only occasionally add new
macros etc, so I tend to run it manually (it is quite slow) after each
significant change. It would be fairly easy to integrate into the
make process if you're using make and wanted to do that. Basically
run:
c:\path\to\vimfiles\extra_source\mktypes\dist\mktypes.exe
--ctags-dir="C:\WINDOWS\system32" -r
from the project root directory as part of the make process. Then you
just need something in vim to run :ReadTypes on any open files.
> And do your plugin used cscope?
Yes and no. It doesn't use cscope at all, but (for my purposes), I
have configured it to run cscope in the background to regenerate the
cscope.out database (so I can update the tags, types and cscope
database in one go). It only does this if both of the following
conditions are true:
1) There is a file in the current directory called cscope.files
2) The buffer-local variable b:CheckForCScopeFiles is set to 1.
All the best,
Al
The short answer is: I don't know.
What is the lookup file plugin and what exactly strange is happening?
Al
Yes! Most of the testing has been done on (embedded) C code, but it
should support C++ code with no problems at all.
> I used this command to create my tags file:
> ctags -R --c++-kinds=-f-n-v -o ../tag_highlight
> And do you had same command?
I call ctags with (if memory serves me correctly):
ctags --recurse --exclude=docs --exclude=Documentation --languages=c,c++ .
This generates a file called tags, which is then parsed to generate types_c.vim.
It treats C and C++ files as equivalent, but it has always seemed to
work for me. Are you having trouble with C++ code?
Al