bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Wed, 4 Jul 2018 18:08:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 7/4/18 5:53 PM, João Távora wrote:

I don't understand.  Will _successful_ navigation ever land me on a spot
where the identifier I looked for _isn't_ there?

A similar string in the buffer, yes. But it might be not its definition.

Like in the example I made up, clojure.core/cons -> "(defn cons".

And I *do* think, when a hint is not found, the method should raise an error. This will be helpful for the search-replace functionality.

Similarly if xref-file-location grows a new optional field which
defaults to nil.

Only in this case it's more code in the backend, and repeated across
backends.

Err, no? In particular, if the new code is in xref-file-location, any class inheriting from it could use it automatically. No need to repeat it.

So it would be a good idea to have this in grep/xref grep results after
all?

A good one, yes, but not so easily-implemented one.

If we use an optional field, we could call ignore-errors around
forward-char if that field is present (your proposal number 1).

I don't fully understand this, but I just remembered that it's better to
have a separate class for another, probably more interesting reason.  We
should just make it a mix-in: that way, we can give "hinted" semantics
to existing location classes, not just xref-file-location.

It sounds useful, but I'm not sure how useful it's going to be in practice. E.g. elisp locations already have their own logic for that. Etags does, too.

And if another backend decides not to use xref-file-location, it will likely do so for reasons incompatible with this mixin's implementation too.

Anyway, if you'd like to propose a patch, that could be easier to discuss.

Regarding ignore-errors, we should (quite independently of the remaining
discussion) first agree if xref-location-marker should be allowed to
error at all, and what should happen if it does.

I think it should.

  (cl-defmethod xref-location-marker ((l xref-bogus-location))
    (user-error "%s" (oref l message)))

is the canonical example.

And then xref-query-replace-in-results should catch them. I thought it's doing that already. :-(





reply via email to

[Prev in Thread] Current Thread [Next in Thread]