Hello David,
Can I suggest support for these commands:
:set/setlocal/setglobal
:syntax
:highlight (and maybe :HiLink because it is so commonly used)
Some examples:
set foldmethod=syntax
setlocal formatoptions+=roq
setglobal completeopt-=preview
syntax keyword phpFunction ...
syn match phpIdentifier ...
syn region phpRegion ...
sy cluster phpClTop ...
syntax clear phpMethods
highlight String ...
hi clear Constant ...
hi link Number ...
hi! link Number ...
hi def link Function ...
HiLink Number ...
These are all pretty straightforward to find.
Also, for dictionary functions would it make sense to mark them twice, since
they get a new 'name' if the dictionary is copied to a new variable? For
example:
let foo = { }
function! foo.func1() dict
endfunction
let bar = foo
There is now a function called 'bar.func1()', so maybe func1 should be tagged
as:
Dictionary Functions
foo.bar /^function! foo.bar() dict/
.bar /^function! foo.bar() dict/
I wouldn't mind if mappings could be tagged as well.
Is there or will there be any way to toggle options for the way ctags scans vim
files?
regards,
Peter
--- David Fishburn <[EMAIL PROTECTED]> wrote:
>
> I have taken over maintenance of the VimL exuberant tags component.
>
> For the vim plugin writers, are there any outstanding bugs or new feature
> requests you have for ctags.exe?
>
> Hari just mentioned Vim7 introduces some additional syntax items to function
> names:
>
> function mydict.len() dict
> endfunction
>
> function autoloadFunc#subdirname#Funcname()
> endfunction
>
> Support for this has been added to the next version of ctags (possibly 5.7).
>
> I noticed a bug in variables which shows up in Vim7, since we introduced the
> for/endfo construct. Ctags starts generating variable tags for tags that
> are within functions after encountering an "endfo" since the short form for
> a endfunction is "endf".
> - Also fixed in the next version.
>
>
> These are the items ctags currently flags:
> "augroup", "autocommand groups"
> "function", "function definitions"
> "variable", "variable definitions"
>
> Does it make sense to also identify autocommands?
> Or possibly only autocommands if they are outside of an augroup?
>
>
> When variables are identified we strip off the scope:
> let s:ignoreNextCursorMovedI = 0 ==> ignoreNextCursorMovedI
> Should the scope be left on ==> s:ignoreNextCursorMovedI
>
>
> Instead of simply grouping everything under variables, should we distinguish
> between different types?
> let forms#form = {
> \ 'title': 'Address Entry Form',
> \ 'fields': [],
> \ 'defaultbutton': 'ok',
> \ 'fieldMap': {},
> \ 'hotkeyMap': {},
> \ }
>
> Right now this is identified as a variable, should we identify it as a
> Dictionary by adding another kind of tag?
>
>
> What about identifying commands:
> command! -nargs=+ Select :call s:DB_execSql("select " . <q-args>)
>
>
> What about [ion]maps (though we cannot give them a name really, but at least
> identifying where they are in the source?
>
>
> We could also pick up local variables (have this off by default) and produce
> something like this:
> function! s:DB_runCmd(cmd, sql)
> let l:display_cmd_line = 'blah'
> let display_shell = 'blah'
> endf
>
> Local variables
> s:DB_runCmd.display_cmd_line
> s:DB_runCmd.display_shell
>
>
>
> I am open to suggestions.
> If you have suggestions, please provide code snippets so I have examples to
> work from.
>
> We can add these tags and leave them on or off by default, so having that
> information is useful as well.
>
>
> At this point the sky is the limit, we can hash out details as we move
> forward. Somethings might not be worth the effort.
>
>
> TIA,
> Dave
>
>
____________________________________________________
On Yahoo!7
Caller tones: Replace your ring tone with your favourite sound clip!
http://callertones.yahoo7.mnetcorporation.com/ctonesmailtag
