bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 7/3/18 6:43 PM, João Távora wrote:
>
> Maybe it's not in a docstring, but in some macro definition, or passed
> verbatim in some other language construct. Maybe it's part of some
> other definition name (separate definitions for methods in C++ come to
> mind).

Still better than failing randomly.  Especially if you hint that the
match was approximate (much like the way diff tell you about "fuzz").

Anyway, those totally hypothetic future users of the class could well
and polish the default behaviour if they decided it's worth it.

> It can certainly become outdated if the user has added or deleted a
> couple of lines there.

But then, in that case, isn't it much better to find an actual match
(and perhaps warn) than to land the user in nowhereland?

Sure it won't probably won't beat the etags backend in the percentage of
times it gets it right.  But that's a quantitative difference, not
qualitative.

> I'm not sure we really need a subclass if a new optional field would
> work just as well.

Because I want something with some default behaviour.  Behaviour that is
admittely half-decent, but nevertheless better than current behaviour.
But since you showed that xref-location-marker is used by your grep
substitute, I don't want to cause any regressions in its existing,
broken behaviour, whatever that may be exactly.

> It might be shorter implementation-wise, too.

This is how I imagine the implementation:

   (defclass xref-hinted-location (xref-file-location)
     ((hint :initarg :hint))))
    
   (cl-defmethod xref-location-marker :around ((l xref-hinted-location))
      <...code to search around...>)

Compared to the "add optional field" approach, there would be about 1 extra line,
the defclass one.

João