* bug#31027: 27.0.50; xref, tags-location-ring equivalent @ 2018-04-02 18:06 Charles A. Roelli 2018-04-03 7:15 ` Robert Pluim 2018-04-03 20:32 ` Dmitry Gutov 0 siblings, 2 replies; 13+ messages in thread From: Charles A. Roelli @ 2018-04-02 18:06 UTC (permalink / raw) To: 31027 tags-location-ring seems to have no replacement in xref.el. from etags.el: (defvar tags-location-ring (make-ring xref-marker-ring-length) "Ring of markers which are locations visited by \\[find-tag]. Pop back to the last location with \\[negative-argument] \\[find-tag].") We should add a "xref-location-ring" (or similar) that stores the locations visited by "xref-find-definitions", and we can allow jumping to them with C-u - M-., in the same way as "find-tag" does. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-02 18:06 bug#31027: 27.0.50; xref, tags-location-ring equivalent Charles A. Roelli @ 2018-04-03 7:15 ` Robert Pluim 2018-04-03 17:58 ` Charles A. Roelli 2018-04-03 20:32 ` Dmitry Gutov 1 sibling, 1 reply; 13+ messages in thread From: Robert Pluim @ 2018-04-03 7:15 UTC (permalink / raw) To: Charles A. Roelli; +Cc: 31027 charles@aurox.ch (Charles A. Roelli) writes: > tags-location-ring seems to have no replacement in xref.el. > > from etags.el: > (defvar tags-location-ring (make-ring xref-marker-ring-length) > "Ring of markers which are locations visited by \\[find-tag]. > Pop back to the last location with \\[negative-argument] \\[find-tag].") > > We should add a "xref-location-ring" (or similar) that stores the > locations visited by "xref-find-definitions", and we can allow jumping > to them with C-u - M-., in the same way as "find-tag" does. xref has a marker stack. The following is bound to "M-," by default. (defun xref-pop-marker-stack () "Pop back to where \\[xref-find-definitions] was last invoked." (interactive) Robert ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-03 7:15 ` Robert Pluim @ 2018-04-03 17:58 ` Charles A. Roelli 0 siblings, 0 replies; 13+ messages in thread From: Charles A. Roelli @ 2018-04-03 17:58 UTC (permalink / raw) To: Robert Pluim; +Cc: 31027 > Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com > From: Robert Pluim <rpluim@gmail.com> > Cc: 31027@debbugs.gnu.org > Mail-Copies-To: never > Gmane-Reply-To-List: yes > Date: Tue, 03 Apr 2018 09:15:33 +0200 > Content-Type: text/plain > > charles@aurox.ch (Charles A. Roelli) writes: > > > tags-location-ring seems to have no replacement in xref.el. > > > > from etags.el: > > (defvar tags-location-ring (make-ring xref-marker-ring-length) > > "Ring of markers which are locations visited by \\[find-tag]. > > Pop back to the last location with \\[negative-argument] \\[find-tag].") > > > > We should add a "xref-location-ring" (or similar) that stores the > > locations visited by "xref-find-definitions", and we can allow jumping > > to them with C-u - M-., in the same way as "find-tag" does. > > xref has a marker stack. The following is bound to "M-," by default. > > (defun xref-pop-marker-stack () > "Pop back to where \\[xref-find-definitions] was last invoked." > (interactive) The xref marker stack (in xref--marker-ring) is a different beast: it stores the list of places where xref-find-definitions was invoked. I suggest having another marker stack that tracks the list of places jumped to by xref-find-definitions. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-02 18:06 bug#31027: 27.0.50; xref, tags-location-ring equivalent Charles A. Roelli 2018-04-03 7:15 ` Robert Pluim @ 2018-04-03 20:32 ` Dmitry Gutov 2018-04-04 18:37 ` Charles A. Roelli 1 sibling, 1 reply; 13+ messages in thread From: Dmitry Gutov @ 2018-04-03 20:32 UTC (permalink / raw) To: Charles A. Roelli, 31027 On 4/2/18 9:06 PM, Charles A. Roelli wrote: > tags-location-ring seems to have no replacement in xref.el. > > from etags.el: > (defvar tags-location-ring (make-ring xref-marker-ring-length) > "Ring of markers which are locations visited by \\[find-tag]. > Pop back to the last location with \\[negative-argument] \\[find-tag].") > > We should add a "xref-location-ring" (or similar) that stores the > locations visited by "xref-find-definitions", and we can allow jumping > to them with C-u - M-., in the same way as "find-tag" does. What about 'M-x previous error'? Or 'C-u - M-x next-error', to mirror your example. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-03 20:32 ` Dmitry Gutov @ 2018-04-04 18:37 ` Charles A. Roelli 2018-04-04 18:57 ` Dmitry Gutov 0 siblings, 1 reply; 13+ messages in thread From: Charles A. Roelli @ 2018-04-04 18:37 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 31027 > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Tue, 3 Apr 2018 23:32:26 +0300 > > On 4/2/18 9:06 PM, Charles A. Roelli wrote: > > tags-location-ring seems to have no replacement in xref.el. > > > > from etags.el: > > (defvar tags-location-ring (make-ring xref-marker-ring-length) > > "Ring of markers which are locations visited by \\[find-tag]. > > Pop back to the last location with \\[negative-argument] \\[find-tag].") > > > > We should add a "xref-location-ring" (or similar) that stores the > > locations visited by "xref-find-definitions", and we can allow jumping > > to them with C-u - M-., in the same way as "find-tag" does. > > What about 'M-x previous error'? Or 'C-u - M-x next-error', to mirror > your example. That's useful, but also different in nature and scope to a global ring, which would not use a local variable (`next-error-function') to navigate to other "errors". An "xref-location-ring" would be simpler. By the way, I didn't know previous-error/next-error worked with xref. Is that documented in the manual? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 18:37 ` Charles A. Roelli @ 2018-04-04 18:57 ` Dmitry Gutov 2018-04-04 19:25 ` Eli Zaretskii 2018-04-04 20:59 ` Juri Linkov 0 siblings, 2 replies; 13+ messages in thread From: Dmitry Gutov @ 2018-04-04 18:57 UTC (permalink / raw) To: Charles A. Roelli; +Cc: 31027 On 4/4/18 9:37 PM, Charles A. Roelli wrote: >> What about 'M-x previous error'? Or 'C-u - M-x next-error', to mirror >> your example. > > That's useful, but also different in nature and scope to a global > ring, which would not use a local variable (`next-error-function') to Whether next-error-function is going to be local or not, is subject to discussion, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674. > navigate to other "errors". An "xref-location-ring" would be simpler. What's simpler about that? You'd need some new commands to use it as well, right? > By the way, I didn't know previous-error/next-error worked with xref. > Is that documented in the manual? Not sure. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 18:57 ` Dmitry Gutov @ 2018-04-04 19:25 ` Eli Zaretskii 2018-04-04 20:59 ` Juri Linkov 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2018-04-04 19:25 UTC (permalink / raw) To: Dmitry Gutov; +Cc: charles, 31027 > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Wed, 4 Apr 2018 21:57:49 +0300 > Cc: 31027@debbugs.gnu.org > > > By the way, I didn't know previous-error/next-error worked with xref. > > Is that documented in the manual? > > Not sure. It is not documented, because this feature is still in flux. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 18:57 ` Dmitry Gutov 2018-04-04 19:25 ` Eli Zaretskii @ 2018-04-04 20:59 ` Juri Linkov 2018-04-04 22:14 ` Dmitry Gutov 1 sibling, 1 reply; 13+ messages in thread From: Juri Linkov @ 2018-04-04 20:59 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Charles A. Roelli, 31027 >>> What about 'M-x previous error'? Or 'C-u - M-x next-error', to mirror >>> your example. >> >> That's useful, but also different in nature and scope to a global >> ring, which would not use a local variable (`next-error-function') to > > Whether next-error-function is going to be local or not, is subject to > discussion, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489 and > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674. I have a wish to close these overgrown bugreports and redesign this feature from scratch ;) >> navigate to other "errors". An "xref-location-ring" would be simpler. > > What's simpler about that? You'd need some new commands to use it as > well, right? Is the idea to use a ring of next-error capable buffers? So that the next-error command in the current buffer will return a list of all potentially next-error capable buffers and allow the user to select the required one. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 20:59 ` Juri Linkov @ 2018-04-04 22:14 ` Dmitry Gutov 2018-04-05 18:56 ` Charles A. Roelli 2018-04-07 20:56 ` Juri Linkov 0 siblings, 2 replies; 13+ messages in thread From: Dmitry Gutov @ 2018-04-04 22:14 UTC (permalink / raw) To: Juri Linkov; +Cc: Charles A. Roelli, 31027 On 4/4/18 11:59 PM, Juri Linkov wrote: >> Whether next-error-function is going to be local or not, is subject to >> discussion, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489 and >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674. > > I have a wish to close these overgrown bugreports and redesign this feature > from scratch ;) The newer one is not so overgrown yet. I do wish we revert the part where next-error-function is buffer local, though, and then you could design this possibility as a user option. We discussed the approaches, but it comes out pretty complex no matter the way you look at it. >>> navigate to other "errors". An "xref-location-ring" would be simpler. >> >> What's simpler about that? You'd need some new commands to use it as >> well, right? > > Is the idea to use a ring of next-error capable buffers? > So that the next-error command in the current buffer > will return a list of all potentially next-error capable buffers > and allow the user to select the required one. Umm, I don't think the request is anything so ambitious. Charles has been asking for a ring to store the navigation locations visited by xref only. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 22:14 ` Dmitry Gutov @ 2018-04-05 18:56 ` Charles A. Roelli 2018-04-05 21:05 ` Dmitry Gutov 2018-04-07 20:56 ` Juri Linkov 1 sibling, 1 reply; 13+ messages in thread From: Charles A. Roelli @ 2018-04-05 18:56 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 31027, juri > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Thu, 5 Apr 2018 01:14:14 +0300 > > >> What's simpler about that? You'd need some new commands to use it as > >> well, right? > > > > Is the idea to use a ring of next-error capable buffers? > > So that the next-error command in the current buffer > > will return a list of all potentially next-error capable buffers > > and allow the user to select the required one. > > Umm, I don't think the request is anything so ambitious. > > Charles has been asking for a ring to store the navigation locations > visited by xref only. Exactly, this feature request is only about xref. Nevertheless, the idea of a "ring of next-error capable buffers" does sound like it could be useful in its own right -- if anybody wants to open up a bug for that, feel free. Anyway, I suggest we follow the etags implementation of "tags-location-ring". This is all there is to it, in simplified terms: (defun find-tag-noselect ... ... (if (eq '- PREFIX-ARG) ;; Pop back to a previous location. (if (ring-empty-p tags-location-ring) (user-error "No previous tag locations") (let ((marker (ring-remove tags-location-ring 0))) (prog1 ;; Move to the saved location. (set-buffer (or (marker-buffer marker) (error "The marked buffer has been deleted"))) (goto-char (marker-position marker)) ;; Kill that marker so it doesn't slow down editing. (set-marker marker nil nil)))) ;; Else, we jump to wherever we wanted to go, and record and add a ;; marker to tags-location-ring. (let ((marker (make-marker))) (with-current-buffer (find-tag-in-order ...) (set-marker marker (point)) (run-hooks 'local-find-tag-hook) (ring-insert tags-location-ring marker) (current-buffer)))))) ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-05 18:56 ` Charles A. Roelli @ 2018-04-05 21:05 ` Dmitry Gutov 2018-04-08 9:14 ` Charles A. Roelli 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Gutov @ 2018-04-05 21:05 UTC (permalink / raw) To: Charles A. Roelli; +Cc: 31027, juri On 4/5/18 9:56 PM, Charles A. Roelli wrote: > Anyway, I suggest we follow the etags implementation of > "tags-location-ring". This is all there is to it, in simplified > terms: You mean, supporting a negative argument to xref-find-definitions? As well as successive invocations that move between matches? Not sure we really want to do that: after all, the xref interface already provides the means to select among the locations. And we have previous/next-error More opinions welcome, of course. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-05 21:05 ` Dmitry Gutov @ 2018-04-08 9:14 ` Charles A. Roelli 0 siblings, 0 replies; 13+ messages in thread From: Charles A. Roelli @ 2018-04-08 9:14 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 31027, juri > Cc: 31027@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Fri, 6 Apr 2018 00:05:01 +0300 > > On 4/5/18 9:56 PM, Charles A. Roelli wrote: > > Anyway, I suggest we follow the etags implementation of > > "tags-location-ring". This is all there is to it, in simplified > > terms: > > You mean, supporting a negative argument to xref-find-definitions? Yes. > As > well as successive invocations that move between matches? Successive invocations wouldn't be handled specially, I think; they would just show entries further back in the location ring. > Not sure we really want to do that: after all, the xref interface > already provides the means to select among the locations. Can you clarify what you mean by this? How can I use xref to navigate among the N previous locations that have been jumped to? If that functionality already exists, then this discussion is moot. > And we have > previous/next-error It's difficult to say whether "next-error" can do what this request is asking for, when "next-error" and its relation to xref have yet to be defined. From what I can see, it looks like a different ball game. For example, the doc of "next-error-function" says it's the Function to use to find the next error in the current buffer. But this request is asking for a way to navigate among the locations jumped to in any buffer, not just one. Additionally, there's no guarantee that the "next' or "previous error" in the current buffer would happen to coincide with the previous location jumped to globally. I don't see how those two things relate to each other, since an "error" can be one of many different things: a compiler error, a search result, a changed part of a buffer, or with the xref package, a symbol definition. The scope of "errors" is very broad. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#31027: 27.0.50; xref, tags-location-ring equivalent 2018-04-04 22:14 ` Dmitry Gutov 2018-04-05 18:56 ` Charles A. Roelli @ 2018-04-07 20:56 ` Juri Linkov 1 sibling, 0 replies; 13+ messages in thread From: Juri Linkov @ 2018-04-07 20:56 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Charles A. Roelli, 31027 >>> Whether next-error-function is going to be local or not, is subject to >>> discussion, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489 and >>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674. >> >> I have a wish to close these overgrown bugreports and redesign this feature >> from scratch ;) > > The newer one is not so overgrown yet. I do wish we revert the part where > next-error-function is buffer local, though, and then you could design this > possibility as a user option. We discussed the approaches, but it comes out > pretty complex no matter the way you look at it. I'll post a request for comments to emacs-devel shortly. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-04-08 9:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-04-02 18:06 bug#31027: 27.0.50; xref, tags-location-ring equivalent Charles A. Roelli 2018-04-03 7:15 ` Robert Pluim 2018-04-03 17:58 ` Charles A. Roelli 2018-04-03 20:32 ` Dmitry Gutov 2018-04-04 18:37 ` Charles A. Roelli 2018-04-04 18:57 ` Dmitry Gutov 2018-04-04 19:25 ` Eli Zaretskii 2018-04-04 20:59 ` Juri Linkov 2018-04-04 22:14 ` Dmitry Gutov 2018-04-05 18:56 ` Charles A. Roelli 2018-04-05 21:05 ` Dmitry Gutov 2018-04-08 9:14 ` Charles A. Roelli 2018-04-07 20:56 ` Juri Linkov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).