fast-tags icon indicating copy to clipboard operation
fast-tags copied to clipboard

get fast-tags to work with other editors, e.g. Atom

Open wolftune opened this issue 10 years ago • 9 comments

Currently, for reasons I don't understand (but haven't deeply investigated), fast-tags tags files don't work fully with Atom. Atom does allow browsing by tags but not jumping to tag under cursor. By contrast, hasktags -x -c works fully with Atom. The Hasktags option also works fully with Vim without trouble. I like using fast-tags so I get easy updates with Vim, but would want to have it work for Atom too, both for me on occassion and for others who don't use Vim.

Whatever the difference, it seems we should be able to figure out what's happening and fix it to make it work. I was hoping the 1.1.1 update would do it, but apparently not (by my testing).

wolftune avatar Sep 14 '15 04:09 wolftune

Here's what hasktags -x generates:

!_TAG_FILE_FORMAT   2   /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED   1   /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_NAME  hasktags
f   Test.hs /^f x = 10$/;"  fi  line:3

fast-tags generates this:

!_TAG_FILE_SORTED   1   ~
$   Test.hs 1 ;" o
f   Test.hs 3 ;" f

So there are lots of differences. I don't have atom, so I don't know what it doesn't like, but it would be easy to test by editing the hasktags output until it looked like the fast-tags one and seeing where atom stops liking it. If you do the testing I'd be happy to implement the change.

elaforge avatar Sep 25 '15 01:09 elaforge

Ok, here's the answer: the only part of the hasktags output that Atom needed, the part that made all the difference was /^f x = 10$/ i.e. the funny /^ and the function line in questions and $/ before the finishing ;". It also failed if I removed any part of the line, it needed the whole line…

The headers at the top of the tags file seem irrelevant

wolftune avatar Sep 25 '15 01:09 wolftune

The part between the filename and ;" is interpreted as a command by vim. Numbers are commands; they take you to the line number they indicate. But searches are also commands.

Atom must not be understanding number-as-command.

chreekat avatar Sep 25 '15 01:09 chreekat

ah, well, knowing that then, could be simple to file a bug with Atom to recognize number-as-command as an alternative option. Of course, search works too and for Vim as well…

wolftune avatar Sep 25 '15 01:09 wolftune

Strange that atom would implement the hard one but not the easy one. I think historically /.../ syntax was added because it was less likely to be wrong when a line is added above, but that doesn't really apply to fast-tags, since it's intended to be run after every edit.

If atom doesn't want to add this feature I can add it to fast-tags, but it wouldn't be entirely trivial. It already saves a bit of the line for emacs tags (I don't really understand how those work), so I'd have to extend that to save the whole line.

elaforge avatar Sep 25 '15 02:09 elaforge

Here's the real Atom ticket already existed: https://github.com/atom/symbols-view/issues/92

wolftune avatar Sep 26 '15 03:09 wolftune

Perhaps related, TAGS generated by fast-tags don't work with xref, the new TAGS navigator in recent versions of Emacs (I'm using Emacs 25.3.2). Searching for <name> with M-. / xref-find-definitions fails with No definitions found for: <name>. In contrast, TAGS generated by hasktags do work with xref.

This thread discusses how xref-find-definitions is stricter than find-tag: https://groups.google.com/forum/#!topic/gnu.emacs.bug/G3DResYSSVE

ntc2 avatar Jun 27 '18 00:06 ntc2

@ntc2 This should fix your problem, give it a try.

I'm leaving the issue open because it's for a different thing, namely that atom supports "/search" syntax but not ":linenumber" syntax.

elaforge avatar Jul 09 '18 00:07 elaforge

it is possible that #43 will fix this, if these editors use Emacs formatted TAGS

fommil avatar Sep 27 '18 22:09 fommil