Tag search in ctrlp-py-matcher

@FelikZ ,

thanks for creating this plugin… it really sped up the file/MRU search.

However, when I tried to search tags, it didn’t really show any tags.

I added the following line:

let g:ctrlp_match_func = { 'match': 'pymatcher#PyMatch' }

to my .vimrc, and it led to fast fuzzy searching for files. However, when I tried to search tags using :CtrlPTag, with a tag Database from one of my files, it gave no results.

Then I commented out let g:ctrlp_match_func = { 'match': 'pymatcher#PyMatch' }, and did :CtrlPTag with a tag Database from one of my files. This time, it was slow to find that tag, but it did fine the tag.

Is there any additional settings I should use to enable tag search using this plugin?

[b4n]

@alphaCTzo7G misc.html is encoded in windows-1252, which obviously isn’t UTF-8. For various reasons uctags doesn’t translate any encodings (there are long topics you can find about that on uctags issue tracker, but the main reason is that it’s incredibly hard to do right – and there are some cases where there is no good solution), and sadly one of the possible issues arising is having an output tag file with mixed encodings when processing multiple files. ectags never did anything with encodings either (actually, way less), and the difference you see are improper truncation in uctags (whereas ectags didn’t truncate at all, and you can get this behavior in uctags with --pattern-length-limit=0) which is what I fixed in the linked PR. In the case of misc.html it’s likely that uctags is simply outputting more tags than ectags did. Anyway, be it ectags or uctags, they are likely to output non-UTF-8 tags if the source files are not already UTF-8. This is even becoming more and more prominent with languages allowing Unicode identifiers, and uctags parsers supporting those.

However, after all me saying uctags doesn’t handle encoding conversion, it actually partly does if you tell it to though the --input-encoding (and/or --input-encoding-<LANG>) and --output-encoding options. This support is not perfect yet (I didn’t follow this recently, but it used to be limited), and it requires the caller to decide on encodings, but it might help in some circumstances.

At any rate, you should probably find a way for invalid UTF-8 not to break your software, because it’s unfortunately unlikely to be “fixed” anytime soon, and it’s a fairly common thing (in most cases it’ll be because the source was ISO 8859-something or Windows-something or alike, and on rare occasions the source will actually be utter garbage with mixed things and random bytes here and there – been there, seen that).

[FelikZ]

@alphaCTzo7G

if you know of a replacement of vim.eval

None that I know. The only thing that comes to the mind, maybe its possible to convert BOM to non-BOM before eval takes place?