Helmut Eller writes: > I don't mind. Rewrites welcome! Ok, thanks. The modified proposal attached. To be honest, now I can better see the appeal of using the classes here. For instance, in the modified API a backend has to return `:none' in its identifier-at-point implementation if not found, because otherwise the default implementation will be called (and it's hard to implement the overriding otherwise). Although we could use a plist (or alist) instead of a function-with-multiple-calling-conventions. Suppose we end up using your implementation, do you think there could be a reasonable case where a xref-backend-function creates a non-trivial instance of its backend class, with instance vars, etc? Because otherwise it'll remain an odd wart. Then the variable can just hold the class symbol, and instantiation can be performed on-demain, or even each time it's used: it's cheap anyway. > Actually, the location stuff was the primary reason I started using > EIEIO. In SLIME we have quite a zoo of location variants (not based on > EIEIO), e.g. file+byteoffset, file+charoffsets, search-strings, and > something that we call "source-paths". A source-path describes a path > in the SEXP tree; sounds weird but works surprisingly well for Lisp > syntax. > > Just want to say that locations should be very flexible. Right, I can see how EIEIO can be useful in this case, so this is the part I mostly left untouched, for now. However, it could be simplified: * I'm pretty sure the default implementation of `xref-location=' will cover 99% of all cases. * There's no real need for the above and `xref--unique-location'. We can just require the implementations to return lists without duplicates. I would think that most would do that even without being asked. * What is `xref--show-location' for? Why do we want to allow certain types to override this behavior? I think `xref--show-xref-buffer' is also suspect at this stage of implementation. `xref-location-group' is quite neat, though. But depending on whether we really want to make this lighter-weight, the class hierarchy here can be replaced with some ad-hoc polymorphism (so we could say that a location can either be a (buffer position) (file line column), or, say, a closure for the most general case). - I kept `etags--xref-read-identifier', but I don't particularly like it: in other places, when we want to use a regexp, that's usually a different command, or a prefix argument, etc. Inputting quotes to make the contents work as a regexp is... odd. - The "identifier at point" and "read identifier" makes me wonder how it would work with more complex languages, where we delegate a lot of logic to an external server process. Will a two-request workflow become usual? First ask the server what's at point, and then send it back with a specific question. I guess some existing packages would be hard to adapt to that. - We should probably port Jorgen's tests.