| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
A side effect of xolox#easytags#write_tagsfile() is that the entries argument is joined together. This then causes problems in s:cache_tagged_files_in(), where the filename element is addressed via entry[1]. When the entries have been flattened, this accesses a single character, and then the cache is corrupted.
To fix this, move the cache update before the writing of the tags file. This avoids the need to make a copy of the entries before flattening them.
|
| | | | |
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | | |
I turn off highlighting of tags (:let g:easytags_auto_highlight = 0), because I usually have very large tags databases. When I manually trigger an update via :UpdateTags, the highlighting is processed, though, resulting in the long delay or "regexp too long" error. The :UpdateTags command should honor the configuration setting.
|
| |\ \ \
| | |/
| |/| |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Reported here: https://github.com/xolox/vim-notes/pull/28
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 :-)
|
| | | |
| | |
| | |
| | |
| | | |
Integration of pull request #40:
https://github.com/xolox/vim-easytags/pull/40
|
| |\ \ \
| | | |
| | | |
| | | | |
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.
|
| | | |
| | |
| | |
| | | |
The pull request: https://github.com/xolox/vim-easytags/pull/43
|
| |\ \ \
| | | |
| | | |
| | | | |
git://github.com/inkarkat/vim-easytags into inkarkat-enh-fingerprint-avoids-update
|
| | | | |
| | | |
| | | |
| | | | |
When creating a tags file for an entire directory, the a:cfile variable is empty. In that case, the cache doesn't work. Avoid "E713: Cannot use empty key for Dictionary" by checking for that.
|
| | |/ /
| | |
| | |
| | |
| | | |
We can avoid the lengthy and blocking update of the tags database when the ctags output returns the same information as before; i.e. nothing tag-relevant has been changed since the last update.
Since 7.3.816, Vim has a sha256() function that allows us to quickly calculate a fingerprint over the ctags output. When that is not available, only handle the special case of a (covered) file that has no tags at all (as calculating a hash in Vimscript is costly and would probably defeat the intended speedup).
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
to system()
|
| | |
| |
| |
| |
| |
| |
| | |
While adding some debugging statements to analyze a probably unrelated
issue I found a serious bug in the support for file type specific tags
files :-(. This commit fixes the bug and adds more debugging output
(which would have made me aware of this problem much sooner).
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
(see inline comment about misuse of features :-\)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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...
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I was editing a file over SCP and after fixing the bug I found out
something really peculiar (at least to me). When the 'tags' option
instructs Vim to search upwards recursively and you're editing a
remote file, Vim's tagfiles() function will pretend as if every
possible file exists:
:echo tagfiles()
['sftp://vps//home/peter/bin/.tags', 'sftp://vps//home/peter/.tags',
'sftp://vps//home/.tags', 'sftp://vps//.tags', 'sftp://.tags',
'/home/peter/.vim/tags/filetypes/sh']
And of course the plug-in doesn't like this:
easytags.vim 2.6.1: Skipping unreadable tags file sftp://vps//home/peter/bin/.tags!
easytags.vim 2.6.1: Skipping unreadable tags file sftp://vps//home/peter/.tags!
easytags.vim 2.6.1: Skipping unreadable tags file sftp://vps//home/.tags!
easytags.vim 2.6.1: Skipping unreadable tags file sftp://vps//.tags!
easytags.vim 2.6.1: Skipping unreadable tags file sftp://.tags!
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Strahinja Marković)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The code became a bit uglier but it's more robust now.
Besides, the code was getting ugly for a while already
so what can you do? Rewrite everything! ... For now
I'll try to resist the urge, or at least
refactor it in small steps :-)
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
