| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
explodey otherwise; enough to know that the thing is installed, since
old versions don't really exist anywhere now
|
|
|
|
|
| |
Refer to issue 123 on GitHub for details:
https://github.com/xolox/vim-easytags/issues/123
|
|
|
|
|
|
| |
See also issue 92 and issue 116 on GitHub:
- https://github.com/xolox/vim-easytags/issues/92
- https://github.com/xolox/vim-easytags/issues/116
|
|\ |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to prevent confusion like in issue #92 on GitHub by @oryband:
I had to comment out the auto_update/highlight lines in order for
easytags to create the local .tags file. I thought that these
options were meant only for on_cursorhold. The documentation
regarding this is quite ambiguous: If on_cursorhold is off,
why does auto_update/highlight also apply to events?
Events aren't auto - I set them manually.
For details: https://github.com/xolox/vim-easytags/issues/92
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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:
https://github.com/xolox/vim-easytags/pull/111
Which came forth from issue 102:
https://github.com/xolox/vim-easytags/issues/102
|
|/
|
|
|
|
|
| |
whenever g:easytags_by_filetype and g:easytags_dynamic_files are both
set, easytags now writes to the dynamic tags file.
fixes #102
|
| |
|
| |
|
|
|
|
|
| |
See also issue #98 on GitHub:
https://github.com/xolox/vim-easytags/issues/98
|
|
|
|
|
| |
As suggested in issue #97, for details see:
https://github.com/xolox/vim-easytags/issues/97
|
|
|
|
|
|
|
|
| |
When a canonical Vim file type mapped to a group of file types,
the group was returned without the canonical file type :-s
See also issue #91 on GitHub:
https://github.com/xolox/vim-easytags/issues/91
|
|
|
|
|
|
|
|
|
|
|
| |
It should be given a canonical file type and since I just changed the
canonical file type for C to be C++ the invocations should be updated
as well. This should really have been part of the change set with id
9b6e7d125c660f31091f59b52de9b1e425cbcb64. That's what I get for not
testing properly...
See also issue #91 on GitHub:
https://github.com/xolox/vim-easytags/issues/91
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Please refer to the inline comments for more details.
This will hopefully fix issue #91 on GitHub:
https://github.com/xolox/vim-easytags/issues/91
PS. I've completely removed the objc/objcpp grouping because I don't know
these languages so I don't know what grouping would be correct anyway.
Until a user with an informed opinion chimes in it's better to just
remove this grouping.
|
|
|
|
|
|
|
| |
issue #97)
See issue #97 on GitHub:
https://github.com/xolox/vim-easytags/issues/97
|
|\ |
|
|/ |
|
|
|
|
|
|
|
|
| |
See issue 90 on GitHub:
https://github.com/xolox/vim-easytags/issues/90
This was caused by the async refactor:
https://github.com/xolox/vim-easytags/pull/84
|
| |
|
|
|
|
|
|
|
| |
See also https://github.com/xolox/vim-easytags/pull/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!
|
|
|
|
|
|
|
|
|
|
| |
This is a bug fix / improvement to the new syntax keyword usage
introduced in b6f8757d004d5f4ef7280fd111a21821e6bee79a.
Also relevant is issue #68 on GitHub, see
https://github.com/xolox/vim-easytags/issues/68
@tarmack: Thanks for the feedback earlier today, it's now fixed! :-)
|
|
|
|
|
|
|
|
| |
This is a bug fix / improvement to the new syntax keyword usage
introduced in b6f8757d004d5f4ef7280fd111a21821e6bee79a.
Also relevant is issue #68 on GitHub, see
https://github.com/xolox/vim-easytags/issues/68
|
|
|
|
|
|
|
|
| |
This is a bug fix / improvement to the new syntax keyword usage
introduced in b6f8757d004d5f4ef7280fd111a21821e6bee79a.
Also relevant is issue #68 on GitHub, see
https://github.com/xolox/vim-easytags/issues/68
|
|
|
|
|
|
|
|
|
|
|
| |
See the following issues on GitHub:
- https://github.com/xolox/vim-easytags/issues/68
- https://github.com/xolox/vim-easytags/pull/80
Please note that right now this 'feature' is not integrated with
the "accelerated Python syntax highlighting" feature, because I'm
considering ripping that out and replacing it with a *fast* Vim
script implementation (if I can build one :-).
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is part 1/2 of speeding up the vim-easytags plug-in. Refer to the
pull request for details: https://github.com/xolox/vim-easytags/pull/84
In part 2/2 I want to speed up the dynamic syntax highlighting.
Potentially related open issues on GitHub (probably missed a few):
- https://github.com/xolox/vim-easytags/issues/32
- https://github.com/xolox/vim-easytags/issues/41
- https://github.com/xolox/vim-easytags/issues/68
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | | |
I had a degenerate tags file that had *two* tabs separating the tag from the filespec column; parsing that yields an empty filespec, which caused E713. There used to be an explicit check for that; with your recent refactorings, one instance of that check was lost. Here it is again!
|
| |\ \ |
|
| | |/
| | |
| | |
| | | |
On Windows, tagfiles() can return a filespec that is absolute to the current drive (i.e. \foo\bar\tags). In async mode, the forked Vim process may have another current drive, so it should be ensured that the filespec is a full one, including the drive letter: D:\foo\bar\tags.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change is related to pull request #83 however that pull request
wasn't merged here (and won't be merged at all) because it was based on
the old/dead `async-cleanup' feature branch (see pull request #49 on
GitHub) instead of the new `async-take-two' feature branch (see pull
request #84 on GitHub). This change set implements the equivalent on the
new feature branch (without introducing another option).
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change is related to pull request #82 however that pull request
wasn't merged here (and won't be merged at all) because it was based on
the old/dead `async-cleanup' feature branch (see pull request #49 on
GitHub) instead of the new `async-take-two' feature branch (see pull
request #84 on GitHub). This change set implements the equivalent on the
new feature branch.
In addition to Ingo's comments in pull request #82, the asynchronous
message frequently disturbs me while typing a Vim command, which is kind
of annoying. If everything goes well and we can get the async mode to be
stable enough to become the default mode then the status messages will
only be interesting when debugging a problem anyway.
|
|/
|
|
|
| |
See also pull request #49 for my previous and failed attempt:
https://github.com/xolox/vim-easytags/pull/49
|
|\ |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> The back reference \g<0> substitutes in the entire substring
> matched by the RE.
> http://docs.python.org/2/library/re.html#re.sub
The documentation does not mention \0 as an alias to it.
Although \1 to \9 works.
I guess this alias (\0 <=> \g<0>) existed in old python version,
but it is not the case any more.
In python 2.7 and 3.3:
> import re; re.compile(r'123').sub(r'@\0@',"ab123cd")
'ab@\x00@cd' # KO
> import re; re.compile(r'123').sub(r'@\g<0>@',"ab123cd")
'ab@123@cd' # OK
|
|
|
|
|
| |
See issue #62 on GitHub:
https://github.com/xolox/vim-easytags/issues/62
|
|\
| |
| |
| |
| | |
See pull request #63 on GitHub:
https://github.com/xolox/vim-easytags/pull/63
|
|/
|
|
|
|
| |
unescaped ++ is invalid regex causing easytag to fall back to the
vimscript highlighting which does not split the regex into small chunks
that vim can handle.
|