[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. :-(
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, (continued)
bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, Dmitry Gutov, 2018/07/03
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, João Távora, 2018/07/03
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, Dmitry Gutov, 2018/07/03
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, João Távora, 2018/07/03
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, Dmitry Gutov, 2018/07/04
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, João Távora, 2018/07/04
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, Dmitry Gutov, 2018/07/04
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, João Távora, 2018/07/04
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations,
Dmitry Gutov <=
- bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations, João Távora, 2018/07/04