…e by filetype I rewrote quite a bit of code in this pull request but I didn't change the behavior introduced by @cornerman (at least it was not my intention to do so). The main reason for rewriting was that the name xolox#easytags#get_global_tagsfile() "was a lie" because it could select either a file type specific tags files or the global tags file. I like functions whose name captures what they do so had to change things around in order to merge pull request 111 without having that name bother me :-). See also pull request 111 on GitHub: #111 Which came forth from issue 102: #102
See also #80 where I suggested to add accurate timing to the vim-easytags plug-in. Here it is :-). This is still quite rudimentary but it's already an improvement over what was there before!
…ately from now on)
This should hopefully resolve the following issues and pull requests: #31, #33, #42. I tried several of their suggestions in Vim 7.2 & 7.3 but it didn't work as it should IMHO. All of the issues and pull requests seem to imply that CursorHold events fire continuously when you set a low enough updatetime, but in my testing on Vim 7.2 and 7.3 this is not true. The event fires once, then Vim waits for user input before any new events fire. I'm not sure exactly what user input is required; moving the text cursor is not always enough but mode switching is. So what happens (in my testing) with all of the proposed solutions is that you stop typing for 'updatetime' milliseconds, the event fires, the plug-in simply increments or decrements a counter and then Vim just sits there doing absolutely nothing expect blinking the cursor... What I'm now trying instead is to remember the last time the plug-in was executed (the result of localtime()) and not acting on the CursorHold event until the following condition holds true: localtime() > (last_automatic_run + (easytags_updatetime_min/1000)) I hope this provides a reliable solution. In any case it should be better than the previous annoying behavior :-)
…s into inkarkat-enh-languages
Implement this via a new configuration option g:easytags_languages, a Dictionary that contains the ctags languages as keys, and corresponding special cmds, args, etc. as values.
While trying to fix issue #20 I decided to refactor the code that handles ignored syntax groups: Previously the list of excluded groups was hard coded in two places, now it's a configuration option. Then it turned out that including shFunction* in the list of excluded syntax groups didn't fix the reported issue...
Some users want the plug-in to use existing project specific tags files but fall back to the global tags file or a file type specific tags file if a project specific tags file does not exist. Other users want the plug-in to automatically create project specific tags files. Both are reasonable options to have. I hope with this change we can all be happy :-) (see also issue #15 and issue #16 on GitHub).