Code Monkey home page Code Monkey logo

Comments (17)

majutsushi avatar majutsushi commented on May 22, 2024

Both things work fine for me, I explicitly tested those conditions. What version are you using? What exactly happens, do you get an error message? What Vim version do you have?

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

Ok, here is more info:

$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Apr 3 2011 18:45:05)
MS-Windows 32-bit console version
Included patches: 1-154
Compiled by Yongwei@Shanghai
Big version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +float +folding -footer +gettext/dyn -hangul_input +iconv/dyn
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +lua/dyn +menu +mksession +modify_fname +mouse -mouseshape
+multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra
+perl/dyn +persistent_undo -postscript +printer -profile +python/dyn
+python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects
+title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
+viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim
-xterm_save -xpm_w32
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME_vimrc"
2nd user vimrc file: "$VIM_vimrc"
user exrc file: "$HOME_exrc"
2nd user exrc file: "$VIM_exrc"
Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DWINVER=0x0400 -D_WIN32_WINNT=
0x0400 /Fo.\ObjCULYHTR/ /Wp64 /Ox -DNDEBUG /Zl /MT -DFEAT_MBYTE -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC
TCL -DDYNAMIC_TCL_DLL="tcl84.dll" -DDYNAMIC_TCL_VER="8.4" -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL="lua51.dll"
-DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL="python27.dll" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3

DLL="python31.dll" -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL="perl512.dll" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_
RUBY_VER=191 -DDYNAMIC_RUBY_DLL="msvcrt-ruby191.dll" -DFEAT_BIG /Fd.\ObjCULYHTR/ /Zi
Linking: link /RELEASE /nologo /subsystem:console oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32
.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib libcmt.lib user32.lib /nodefaultlib:lua51.lib /nodefaultlib:p
ython27.lib /nodefaultlib:python31.lib C:\Tcl\lib\tclstub84.lib /PDB:vim.pdb -debug
$
$ whence ctags
C:/Program Files/Tools/ctags/ctags.exe

$ ctags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
Compiled: Jul 9 2009, 17:05:35
Addresses: [email protected], http://ctags.sourceforge.net
Optional compiled features: +win32, +regex, +internal-sort
$

I tried all of the following in _vimrc

"let g:tagbar_ctags_bin='C:\Program Files\Tools\ctags\ctags.exe'
"let g:tagbar_ctags_bin="C:/Program Files/Tools/ctags/ctags.exe"
"let g:tagbar_ctags_bin="C:/Program\ Files/Tools/ctags/ctags.exe"
"let g:tagbar_ctags_bin="C:/PROGRA~1/Tools/ctags/ctags.exe"

Each leads to the same error from vim:

"Tagbar: Exuberant ctags not found in specified place, skipping plugin"

By the way, taglist plugin works with the following setting:

let Tlist_Ctags_Cmd="C:/PROGRA~1/Tools/ctags/ctags.exe"

and probably others. I have not played too much with this setting there.

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

Oh, and this is on Windows 7 64bit Enterprise, SP1. I'm also using MKS Toolkit , which is a port of POSIX UNIX APIs, shells and standard UNIX utilities (something like Cygwin, except nicer :D).

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

Sorry for the late reply, I've been very busy recently. Anyway, there must be something strange going on with your system, all the setting that you tried worked perfectly fine for me (on Windows Server 2003). The only thing that I tried that didn't work was using backslashes together with double quotes (and it's not surprising that that didn't work).

What's the value of your shell option?

Near the top of the file autoload/tagbar.vim there should be something that looks like this:

else
    let g:tagbar_ctags_bin = expand(g:tagbar_ctags_bin)
    if !executable(g:tagbar_ctags_bin)
        echomsg 'Tagbar: Exuberant ctags not found in specified place,'
              \ 'skipping plugin'
        finish
    endif
endif

Does the plugin work if you comment out the if !executable() part? Or if you disable the shellslash option?

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

I'm using MKS Toolkit Korn Shell as my default shell, so shell=ksh in my _vimrc.

In any case the problem seems to be with the if statement at the top of the tagbar.vim file

if I remove the quotes around the g:tagbar_ctags_bin variable when passing it to exists function, so the line becomes

if !exists(g:tagbar_ctags_bin)
    if executable('ctags-exuberant')
        let g:tagbar_ctags_bin = 'ctags-exuberant'
    elseif executable('exuberant-ctags')
        let g:tagbar_ctags_bin = 'exuberant-ctags'
    elseif executable('exctags')
        let g:tagbar_ctags_bin = 'exctags'
    elseif executable('ctags')
        let g:tagbar_ctags_bin = 'ctags'
    elseif executable('ctags.exe')
        let g:tagbar_ctags_bin = 'ctags.exe'
    elseif executable('tags')

then everything works.

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

But by removing the quotes around the variable the test will do something entirely different: it will check whether there's a variable with the name of the path you configured (i.e. a variable named C:\Program Files\...), and that should of course always be false. If it works because of that it means that your ctags should already be in your $PATH so you wouldn't even need to set the variable.

Just in order to check what the actual problem is, could you please still test whether it works if you disable shellslash (without changing anything else)? Thanks!

from tagbar.

kien avatar kien commented on May 22, 2024

This sounds like there's a wildignore+=*.exe or similar in mario's _vimrc, since you use expand() on the g:tagbar_ctags_bin (expand() just makes it blank thus fail the next executable() check).

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

Interesting, I didn't know expand() fails for ignored patterns -- thanks for the hint! Now I'm curious whether one of those two things actually was the culprit.

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

Ignore my previous comment. Yes, removing quotes around the variables allows vim to start without errors but the plugin doesn't actually work.

So, expand call it seems is the real culprit here. First of all the reason I'm defining g:tagbar_ctags_bin variable in the first place is because I got multiple ctags executables in my path:

$ which ctags
C:/mks/tk9.4/mksnt/ctags.exe
$ whence ctags
C:/Program/ Files/Tools/ctags/ctags.exe
$ type ctags
ctags is an alias for C:/Program\ Files/Tools/ctags/ctags.exe

However, the wrong ctags (one that comes with MKS Toolkit) is first in path, so I have aliased ctags to exuberant ctags. However, if you execute ctags from gVim, it sees the one first in path as expected.

It looks like expand(g:tagbar_ctags_bin) returns empty string. So just commenting out the line

   "let g:tagbar_ctags_bin = expand(g:tagbar_ctags_bin)

actually solves the problem. After that vim starts without errors and plugin actually works.

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

OK, that's good to know that expand() is really where it goes wrong. Now I'm just curious what exactly the reason for that is so that I can hopefully fix it without removing expand() -- I would like to keep it so that users can specify a path that includes for example ~ and have it work automatically. So could you please tell me whether you ignore *.exe files in your wildignore variable like @kien suspected, or whether it's caused by shellslash by disabling it temporarily (and re-enabling the expand() call of course)? Thanks!

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

Yes, I have *.exe in my wildignore

wildignore=*/obj/*,*/dest/*,*/images/*,*.pj,*.jpg,*.gif,*.obj,*.lib,*.dll,*.exe

However, even if I comment out this line in my _vimrc, so wildignore has its default value I still get the following error:

Error detected while processing function <SNR>16_OpenWindow..<SNR>16_CheckForExCtags..<SNR>16_ExecuteCtags:
line   13:
E484: Can't open file C:/Users/mgrgic/AppData/Local/Temp/VIo5CAC.tmp
Error detected while processing function <SNR>16_OpenWindow..<SNR>16_CheckForExCtags:
line    9:
Tagbar: Ctags doesn't seem to be Exuberant Ctags!
GNU ctags will NOT WORK. Please download Exuberant Ctags from ctags.sourceforge.net and install it in a directory in your $PATH or set g:tagbar_ctags_bin.
Executed command: ""C:/Program Files/Tools/ctags/ctags.exe" --version "

My shellslash is set to default value (I believe it is \ on Windows).

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

Now I'm a bit confused, didn't you just say it worked for you? Do you mean it works when commenting out the expand(), but not when commenting out wildignore? That sounds rather strange. I assume the ctags being called is the one you specified manually, right? Could you tell me what the output of

$ "C:/Program Files/Tools/ctags/ctags.exe" --version

is?

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

It works only when I uncomment expand line. It does not work if I uncomment only wildignore and still use expand line.

Here is the output of the ctags --version (ctags is the alias to exuberant ctags in program files).

$ ctags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
Compiled: Jul 9 2009, 17:05:35
Addresses: [email protected], http://ctags.sourceforge.net
Optional compiled features: +win32, +regex, +internal-sort
$

So, to recap, if I uncomment expand line, everything works (wildignore has no effect). If expand line is present, the plugin does not even start with wildignore line as above. If expand line is present and wildignore is commented out, then vim stars with no errors but I get the error in my previous post only when I actually try to :TagbagOpen

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

That is really weird, the ctags version looks perfectly fine. I wonder if it has anything to do with the file it's trying to open in your error message above -- it shouldn't really open any files. Is that a file you were trying to edit? If not, could you check what kind of file it is or what's in it? Also, could you tell me what the output of both of the following commands is (with wildignore commented out)?

:echo g:tagbar_ctags_bin
:echo expand(g:tagbar_ctags_bin)

Sorry for asking so many questions, but I'd really like to get to the bottom of this to fix it properly :). Thanks for helping out!

from tagbar.

mario-grgic avatar mario-grgic commented on May 22, 2024

Here is the output of the above two commands:

C:/Program Files/Tools/ctags/ctags.exe
C:/Program Files/Tools/ctags/ctags.exe

By the way the temp file it's complaining about in the error message does not exist. I think this is just VIM executing ctags to get its output in a temp file. But it does not succeed, so temp file does not get created and VIM complains.

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

So the value with and without expand() is the same, but the behaviour is different? Now that is really strange. I'm afraid I'm running out of ideas here ... It would probably be best if I recreate your setup myself so I can have a look at it directly, but I don't have a Windows 7 machine at the moment and I'm not sure how soon I'll have time to set something up. For the time being it's probably best for you to just comment out the expand() line until I have found a better solution -- sorry about that!

I'll commit a small change that will reset the wildignore setting temporarily for the expand() call, though, in case other people include *.exe in there, too.

from tagbar.

majutsushi avatar majutsushi commented on May 22, 2024

Hi, are you still having this problem? If not I would prefer to close this issue so it doesn't clutter up the list. Thanks!

from tagbar.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.