Does this actually support Emacs compatible TAGS files?

[dertuxmalwieder]

I'm currently creating my Ctags files with "ctags -Re" - this creates a TAGS file in the current folder. The README says the plug-in requires a .tags file. Now what?

[EdVanDance]

Use Ctrl-T, Ctrl-R within sublime to create your tags :)

[dertuxmalwieder]

Well, I was hoping anyone would answer my question what about already existing TAGS files... :/

[stephenfin]

Ah - missed that :) Far as I'm aware the regex matching won't match on etags (since they're formatted differently, right?). If you can suggest an alternative regex and (possibly) searching "algorithm" I'll be happy to merge it in.

[dertuxmalwieder]

Well, yes, the differences are:

1. The file name (TAGS) ;-)
2. etags uses a "Header" for all tags.

The differences are explained here. Not sure if it would be a simple regex, but I would actually appreciate a solution. :-/

[stephenfin]

Fair enough. I'll try to get to this sooner rather than later. However, if you're any way comfortable with Python atal I'd suggest taking a look at this yourself. You'll most likely be able to get it resolved much sooner than I will :)

I'll reopen for now nonetheless.

[dertuxmalwieder]

Python is one of the few languages I'm not familiar with. It lacks brackets.

[stephenfin]

:+1:

[stephenfin]

Had a look at this. You're right - it's not a small change (in fact it's quite a large one). Off the top of my head, here's some thing that would have to be changed to add support for this feature:

• New search "algorithm": The existing binary search won't work. A binary search requires the file to be sorted from beginning to end and this isn't true for ETAGS: the tags for each file are contained in their own section in the file. This means either the file would have to be broken up on the sections into multiple tag files (allowing us to keep the binary search but littering your drive with loads of small files) or it'd have to resort to a linear search (no new files but poor performance for larger files).
• Change tag parsing functions: ETAGS don't seem to indicate whether a tag is an import, function, class etc. This isn't going to play well with a fair few functions. Additionally the format of the tags is changed. An alternative regex plus some helper functions would be needed to parse the tags (not all information, i.e. filename, is contained on one line as detailed in my first point).
• Others: There's surely some other changes which I've missed.

All in all, it seems adding ETAGS support is going to take a good deal of work and won't perform as well as ctags. As a result it's going to be pretty low on my priority list. If someone else wants to take a look at this feel free but I doubt I'll get around to it I'm afraid. :( My best advice would be to convert the tags somehow or rebuild new tags using this plugin or the shell.

[dertuxmalwieder]

Of course I am right.

ad 1.): The new algorithm would also improve speed for CTAGS, I'd assume.

ad 2.): The regex would probably be rather similar, so this is not "so" much work, I guess. OTOH I'm not familiar with Python regex, so I can't really help :(

[stephenfin]

At least you're modest :)

(1) No. Binary search is pretty much the best search algorithm for this kind of irregular, sorted data. A linear search will almost certainly be slower. emacs might have a more efficient search algorithm implemented but finding out how it works would involve delving into emacs source code - something I'm not willing/capable of doing. (2) Yes it would be similar but a lot more would have to change - check my previous reply. On this note though, there's never a bad time to learn a new language?

[dertuxmalwieder]

1.) Hmm, the Emacs sources are largely written in Emacs Lisp, another language I'm only scraping the surface of (yet)... ;-)

2.) But it has no brackets!