Re: xref-find-matches and stuff

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Tue, 12 May 2015 14:08:20 +0300
> 
>     I don't see the difficulty.  Can you explain why you think it's more
>     than a few lines of code needed to produce the tags for accessors and
>     predicates "out of thin air", given just the name of the defstruct,
>     immediately after we produce the tag for the defstruct itself?
> 
> Upon encountering cl-defstruct foo, you'll need to collect the list of its 
> slots, and create a tag for a function named foo-slotname for each.

If the symbols generated by a macro are highly dynamic and there are a
lot of them, and if we indeed want to tag all the slots, then it might
be a bit more complex, indeed.  But the alternative is no better,
since AFAICT it only supports interned symbols, i.e. only loaded
packages.

> Is there a sexp parser in etags already?

There's no need for a full-fledged sexp parser, I think, just for
something that can find and extract values of a fixed list of
keywords from a parenthesized list.  Hardly rocket science.

> Also handle constructors, but those could be taken care of with a regexp, I 
> think, without a lot of false positives.

Rules for creating names of constructors and other fixed symbols could
be simply known to etags, so it could generate them given the name of
the defstruct.

>     If we decide that's what we want, then why won't we write that?  The
>     number of constructs that need to be handled might be large, but it's
>     finite.
>
> Maybe because it's not really finite. Anyone can define a new construct like 
> this, with different syntax.

I see no problem here, we already have a few Emacs-specific tricks in
etags, a few more won't hurt.  The question is do we want that?  If
most people are happy with having access only to symbols they have
interned, then I guess it isn't worth our while to make etags
especially smart in this regard.

One thing we could do is provide a way for the user to ask for looser
matches if the exact ones failed.  Then foo-mode will be considered a
potential match for foo-mode-abbrev-table, which is exactly what is
needed in these cases.