TODO

LEGEND
  - todo; + in progress; * done; / obsolete, do not want, or can't repro
  ? open question; . note; bug: marks bugs.

* seems like adjacent-suppression works for emacs but not vi?
  . No, it's that emacs get the module, but not the function.

- adjacent-suppression probably not good for tagbar type stuff, allow to turn
it off

* I'm getting _ as a tag when it's a parameter.
  . Probably being mistaken for an operator.

multiple roots:
  . One way is to maintain a tags for each package, merge to the local tags,
    and then merge all tags to the global one.
    . The reason to use multiple tags files is that I can avoid recreating the
      ones for packages that don't change often, e.g. hackage modules.
  . This needs a slightly fancier init-tags script, and a "merge tags" mode.
  . This is assuming people start vim in the repo root, which is probably not
    what they do.
  . But it seems like vim should be able to use tags in a parent directory,
    e.g. go up until getting to tags, and then resolve as if it's in that
    directory.
  * But I also need tags to recognize a non-module prefix, e.g.
    src/A/B.hs --> A.B.c src/A/B.hs
    . In fact, this is just for --qualified and --fully_qualified, unqualified
      doesn't care.
    . So maybe I can just drop non-capitalized directories?  Better to have an
      explicit flag, because people might use capitalized directories for
      whatever reason.
  - merge tags from separate places
    . If I merge tags from different roots, I have to add a common prefix,
      because presumably the editor is running in a common ancestor.

medium scale:
  . check-in keeps a global tags, local changes are an overlay on that.
  . I think multiple tags files woud have that effect, just do incremental
    tags on save, and don't initialize the first time.
  . If I can keep local overlay per-branch then I can have accurate branch
    switching too.
  . I could make tags as a build product, then just import based on head, but
    I worry that the nix overhead would be greater than rebuilding from
    scratch.  If it is, I could have it copy to NFS by commit hash.
  . But I don't want fallback tags to be in NFS.  I want to copy over the data
    on sync, so as if it were in the repo, but not actually checked in.  The
    problem with actually checking in is noise in every commit, and spurious
    conflicts.
  . This is a general problem of wanting a generated file in the repo, which
    comes up again and again.

large scale:
  . I think I'll have to stop using text files.  The problem is I want to
    merge unchanged and changed tags, but with a text tags file I have to
    rewrite the entire file every time.
  . I could use multiple tags files in vim, but I assume as that list grows,
    search time becomes linear.
  . But this means I have to basically reimplement tags entirely... which is
    maybe not a problem, because I could do it much simpler.  Say keep
    a sqlite db.  All I have to do is delete by filename, add new entries,
    and search by symbol name.
  . I might want some reimplementation of the "static" local tags thing, where
    I favor tags in the local file.  However, if I can do "accurate unqualified"
    then I might not need it much.

accurate unqualified:
  . Can I get accurate symbols without fully-qualified?
  . When searching for an unqualified symbol, first look in the local file.
    Then look through the import block for unqualified imports with that
    explicit import.  If not found, try the ones without explicit imports
    until one matches.
  . I'll need a fancier import block parser, and I probably want to do it in
    haskell.  So fast-tags could have an orthogonal mode to parse import
    blocks, and qualified_tag.py invokes that.
  . Or do the extension in haskell, but I think only neovim supports that?
  . Searching for a plain tag where I don't know where it is is still
    valuable, because unimported tags can occur in comments and strings.

re-exports:
  * The easiest approximation is to try without qualification if qualified
    doesn't match.
    . :echo taglist('^Textioe$', expand('%'))
  . If I see `module X` in the export list, find an `import ... as X`, and
    re-export its symbols.
    . This has to be recursive, in case that module also re-exports.
  . For any symbol in the export list, see if it's imported from someplace
    else, and use that module as above.

  . I guess if I see 'module Xyz' in the export list, I should go get the tags
    from Xyz.
  . To be accurate, I'd want only the imported tags.
  . And of course we can also export just by writing the symbol name.
  . So the fully accurate version would be look at the export list.  Any
    symbols imported from someplace else have to be chased to that module.
  . This is actually two things:
    1 - one is to only make tags for exported symbols.  I'd want to emit those
      as qualified tags, and the rest as static tags.  However, I don't know
      that this really helps, because it's not like having too many qualified
      tags hurts anything, since by nature they won't conflict.  You're just
      unlikely to follow them.
      . The problem with this is that it can get messed up by my
        #ifdef TESTING export all habit.  Let's not do 1 then.
    2 - The other thing is to be able to chase imported symbols.  Possibly
      recurse multiple times.
  . If I do 2, I still have to do full parsing of the export and import
    blocks:
      exports = parseExports module :: [Either Symbol ModuleName]
      imports = parseImports module :: Map ModuleName (Either [Symbol] All)
      imports = [either id (exportsOf module) imports | (module, imports) <- imports]
      exportsOf = parse module

      resolve (Right module) = chase module (Map.lookup module imports)
      resolve (Left sym) = chase module [sym]
      in
      resolve exports
    . So this seems doable, but nontrivial.
  . I also need to remember the constructors of a data, for X(..) syntax.
  . First I should see what the haskell ide guys have done.

* Implement --fully_qualified
  . This is like --qualified except that it uses full qualification, for use
    with qualified_tag.py.

- Is \ continuation in strings is parsed correctly?

* I'll need to sort them again.  Why not just pay no mind to sorting except to
  a full sort as the last step?  I think 100k elements should sort quickly.
  . Time old and new versions against ghc source.
  . Do emacs tags need to be sorted?  Apparently not.

* I get scrambled warning output, probably due to threads not locking the
output.

/ Lots of parse errors on ghc source.
  . Looks like it's just weird primitive syntax like data (a, b) = (a, b).

* Implement --qualified flag.
  . The only reason to have static is that the same name is prioritized if
    local.  But with qualified names, none are local.  No wait, I still have
    all the unqualified ones for local jumping.  But vim already knows the
    filename, so won't it already prioritize that?  Yes, it will.
  . Verify that local definitions get priority.  They do.
  * Write vim binding to bind to ^] and expand to keyword + '.', without
    having to modify iskeyword.
    . Problems with adding '.' to iskeyword:
      . 'w' is unexpected, so I'm surprised when cw deletes past the '.'.
      . * and # also include the qualification, which means I can't check
        spelling with * and search highlighting.  It also breaks my habit of
        finding a definition by doing *, switching to its file, then n.  But
        maybe I should be using tags for that!

* Option to collapse different typed tags on the same line.  Didn't I add
something like this long ago?
  - I think I can get rid of RepeatedTag now, but I should probably implement
    merging for emacs tags.

- Would it make a difference to use Vector for tags instead of lists?