Atom-ide-ui: Expose goToLocation activity as an Atom service

Created on 19 Sep 2017  Â·  9Comments  Â·  Source: facebookarchive/atom-ide-ui

Description

Hyperclicking is easy and satisfying, but it's not so easy to return from a hyperclick.

Symbols View solved this with symbols-view:return-from-declaration. I really like that keystroke.

Maybe hyperclick could push its locations onto the sybmols view stack?

Or would there another way to make it easier to jump back from a hyperclick? I'm happy to bang together a package or a PR but I'm not quite sure how to solve this.

Most helpful comment

Nuclide's navigation stack hooked into the goToLocation function to only apply to those moves, which was quite a bit better. We should be able to provide that as an Atom service.. let me do that, actually, so that you can hook into that.

https://github.com/facebook-atom/atom-ide-ui/blob/master/modules/nuclide-commons-atom/go-to-location.js

All 9 comments

https://atom.io/packages/last-cursor-position is another package that solves this.
In Nuclide we had a 'navigation stack' package that would allow you to easily jump back and forth.. maybe we can consider releasing that as a separate package.

Well, last-cursor-position operates on every cursor move. That's not really like symbols-view:return-from-declaration (unless I'm missing a way to configure last-cursor-position?)

Same question for the navigation stack package you refer to... Did it apply to every cursor move, or just to hyperclicks / symbol navigation?

Nuclide's navigation stack hooked into the goToLocation function to only apply to those moves, which was quite a bit better. We should be able to provide that as an Atom service.. let me do that, actually, so that you can hook into that.

https://github.com/facebook-atom/atom-ide-ui/blob/master/modules/nuclide-commons-atom/go-to-location.js

This sounds like a thing that is much better solved in a separate package.

Here's my concept:

  • Every _file activation_ should be added to the stack.
  • A _cursor move_ should update the current files "cursor" in the stack
  • A _:go-back command should move up the stack
  • A _:go-forward command should move down the stack
  • A new file activation would cause the stack to remove all items past the current stack index

That'd be a neat and medium difficulty package to make.

I do think that atom-ide-ui should provide this functionality (as its very common in IDEs). I just want it to be "all the way" and not just "return from declaration". It'd probably make more sense to have a separate package that is either inline like the rest of the packages or installed with atom-package-deps.

We should be able to provide that as an Atom service.. let me do that, actually, so that you can hook into that.

Do we actually need a service you need to know about and use or can we just observe events?

Where can we fire the events from? I guess it’d have to be somewhere that
other packages can access freely.

On Tue, Sep 19, 2017 at 7:29 PM Matthew Dapena-Tretter <
[email protected]> wrote:

We should be able to provide that as an Atom service.. let me do that,
actually, so that you can hook into that.

Do we actually need a service you need to know about and use or can we
just observe events?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/facebook-atom/atom-ide-ui/issues/50#issuecomment-330727335,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjPYpeySWigUIL5NlSugX8SxyO2_sviks5skHhugaJpZM4Pc-wO
.

Oh I meant can we observe existing events. So instead of calling gotoLocation(), you'd just open an editor as normal and we'd notice it and add it to the stack.

(Sorry for the inactivity here) I've thought a bit more about the 'navigation stack' feature recently and it does seem like there doesn't really have to be any special-casing for goToLocation -- tracking all cursor changes and active editor switches really does seem like the best general solution. It's helpful to also look at how VSCode implements its history functionality as a starting point: https://github.com/Microsoft/vscode/blob/ab1669f8987c585c260e824584e3bf79c82fc064/src/vs/workbench/services/history/electron-browser/history.ts#L104

After reading through this thread I don't quite understand the outcome? Is there a centralized navigation stack somewhere? If so, how is it used?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

wottpal picture wottpal  Â·  7Comments

Arcanemagus picture Arcanemagus  Â·  4Comments

tiagonervis picture tiagonervis  Â·  4Comments

niccolomineo picture niccolomineo  Â·  6Comments

Arcanemagus picture Arcanemagus  Â·  7Comments