RFC for Open in Atom #1525
RFC for Open in Atom #1525
Conversation
There was a problem hiding this comment.
There are a few implementation details I'm musing about here, but nothing that's super ambiguous and important to resolve before we accept this.
Thanks for writing this up! 😍 Shipping something on .com has been on my "bucket list" for a while now, maybe this is my chance :-D
|
|
||
| In various places on github.com a user has the option to "Open in Atom". It's the same idea as the "Open in Desktop" that already exists. | ||
|
|
||
| > Note: Out of simplicity, GitHub Desktop or other editors are not shown in the mockups. If multiple options are available, a dropdown could be used to make a choice. |
There was a problem hiding this comment.
Does .com already handle this case where you have multiple "open in..." applications active? I'd imagine they have to, and it'd be nice to be able to take advantage of preexisting work.
There was a problem hiding this comment.
Based on https://github.com/github/atom-log/issues/425#issuecomment-261125392, we should be able to add more clients. But that might only be for cloning a repo and not for all the other places.
|
|
||
|  | ||
|
|
||
| Once a user authenticates the GitHub package in Atom with their GitHub login, an "Open in Atom" option will be available on github.com in the following places: |
There was a problem hiding this comment.
What happens if the user is on a different machine than the one that they have Atom installed on? Is it a no-op?
I'm guessing that Desktop, Xcode, and all the others have to handle the same problem too, though, so it should be fine. 👍
There was a problem hiding this comment.
Heh.. good question. 🤔
| ### Repo | ||
|
|
||
| 1. Clones the repo to Atom's "Project Home" (config) directory | ||
| 2. Opens a new Atom window with the repo as its project |
There was a problem hiding this comment.
Would we want to offer a config option for new window / add to most recent window?
Personally, I use atom -a pretty heavily from the command-line, and organize my project roots into a single Atom window per monitor. I'm sure there's some variance in usage here though.
There was a problem hiding this comment.
Would be nice. I think if you clone in Atom, it adds a new project to the current window.
Personally, I use the same Atom window, but try to switch between projects with packages like https://atom.io/packages/project-switcher2. So it replaces the current project in the current window. 😄
| ### Pull Request | ||
|
|
||
| 1. Clones the repo (if needed) | ||
| 2. Checks out the branch of the PR |
There was a problem hiding this comment.
Note that this'll take a special refspec to fetch PR refs (in the common case of checking out a PR from a fork). We'll already need to cross that bridge to implement "checkout PR" anyway, though.
| - Or focuses the window if the repo already exists as an opened project | ||
| 4. Opens the Git panel (showing all conflicting files) | ||
| 5. Opens the (first) conflicting file | ||
| 6. Scrolls to the (first) conflict |
There was a problem hiding this comment.
Related: we should also be doing this when you open a file from the Git tab, but we aren't yet; see #812.
| ### File | ||
|
|
||
| 1. Clones the repo (if needed) | ||
| 2. Checks out the branch |
There was a problem hiding this comment.
After each of these "checks out the branch" steps, we'll also need to do a fetch if the commit can't be found locally.
Also, we'll need to make sure we choose the branch with a fetch upstream remote and ref matching the one on .com - they don't have to be named the same thing. There are some trailing edge cases to consider like "you already have multiple branches in your local repo that all fetch from the same place".
|
|
||
| ### Line | ||
|
|
||
| 1. Clones the repo (if needed) |
There was a problem hiding this comment.
Similarly, for the "clone the repo (if needed)" steps - do you have any insight into how we can determine if the repo already exists or not? I'd rather not be too prescriptive about the way users organize their filesystems if we can avoid it. Maybe we can store a mapping of repository URL or nwo 👉 project path in a file under ATOM_HOME and use that to find them?
There was a problem hiding this comment.
Maybe we can store a mapping of repository URL or nwo 👉 project path in a file under
ATOM_HOMEand use that to find them?
Is ATOM_HOME the "Project Home" config?
I'd rather not be too prescriptive about the way users organize their filesystems
Yeah, it would become pretty annoying if you would have to tell Atom where to find the repo each time. I guess Desktop gets around that by having an index of all projects/repos so it knows their local path.
There was a problem hiding this comment.
Is
ATOM_HOMEthe "Project Home" config?
Nah, it's ~/.atom by default - the location where Atom looks for its config, user init scripts, package installs, things like that. We already have a github.cson file there that we could use for this.
There was a problem hiding this comment.
I guess Desktop gets around that by having an index of all projects/repos so it knows their local path.
🤔 I wonder if it's stored somewhere we could read and write?
There was a problem hiding this comment.
I wonder if it's stored somewhere we could read and write?
Probably not from another application?
Ohh.. now I just remembered.. Atom has this "Reopen Project":
Maybe we could check that list? Could be like:
- Check "Reopen Project" list if the repo exists.
- Check "Project Home" directories if the repo exists. Maybe even nested?
- If the repo is not found, show a dialog where you can choose the local path.
- But you can also choose an existing directory that contains the repo. Atom then should add that directory to the "Reopen Project" list so it will find it automatically the next time.
Not sure where "Reopen Project" gets stored, but might be neat to have it as .atom/projects.cson so that you can make a backup or also edit it by hand. I think https://atom.io/packages/project-manager does something like that.
Scope creep! 😝
| - More contributions. | ||
| - If a reviewer tests something locally and makes edits, they might commit the changes and push it back to the PR. 👉 Reviewers that can easily edit and test a PR more likely become collaborators. | ||
| - Better integration with other applications. | ||
| - Be able to open files, lines, merge conflicts etc. in Atom isn't just limited to github.com, it's also possible for other applications. For example if there is a merge conflict in GitHub Desktop, instead of manually switching and trying to find the conflict, GitHub Desktop could send you to Atom in a more seamless way. |
|
|
||
| An alternative is to let users discover PRs/issues or get notified about changes **within** Atom. This would certainly be nice to have, but it will be a very long road until a "never have to leave Atom" is reached. Especially for our tiny team. We also don't have to pick one or the other and both approaches can complement each other. | ||
|
|
||
| An alternative to have an Atom integration directly build into github.com would be to create a **browser extension**. A benefit is that it can be extended to other web sites/apps. For example an "Open in Atom" link inside Gmail for GitHub notifications. Downside: Users have to first install the extension. |
There was a problem hiding this comment.
Yah, I much prefer this to writing browser extensions, I think - much more discoverable.
There was a problem hiding this comment.
This functionality could be easily implemented as a bookmarklet.
For example the following pseudo-link would send any URL to the git-client protocol (which is used by Visual Studio):
javascript:window.location="git-client://clone?repo="+document.URL
This might be useful for prototyping or for users who want this functionality close at hand. Just a crazy idea. 😉
|
|
||
| - [ ] Is github.com interested in adding an "Open in Atom" option? And possibly other editors? There is already a [Clone in Xcode](https://blog.github.com/2017-06-05-clone-in-xcode/) option. | ||
| - [ ] Are there any security risks that need to be investigated beforehand. | ||
| - [ ] What could the API (URI) look like? E.g. `atom://github/open?pull=1234` |
There was a problem hiding this comment.
Hmm, let's see. How about:
atom://github/open/smashwilson%2Fremote-repo?pull=1234&line=456
And from an Enterprise instance, we'd encode the full remote URL:
atom://github/open/https%3A%2F%2Fgithub.enterprise.com%2Fsmashwilson%2Fremote-repo?ref=branchname&sha=abc123&file=some%2Fpath%2Fsource.js&line=456
Hard to say until we start implementing it though, I'm sure there's more info I won't realize we need until we're neck-deep in code 😆
There was a problem hiding this comment.
we'd encode the full remote URL:
Or in all cases? Would this be possible: Keep it exactly the same as .com URLs, except replace https://github.com with 👉 atom://github/open
- .com URL:
https://github.com/atom/github/pull/1525/files#diff-7e96b28649369913c5e87f137813ade5R131 - Atom:
atom://github/open/atom/github/pull/1525/files#diff-7e96b28649369913c5e87f137813ade5R131
This would make it easier to turn a .com URL into an Atom URI. By hand or by other apps, browser extensions etc.
Also, as a first step, Atom could offer an "Open from GitHub URL" like in Visual Studio. Then later consider adding "Open in Atom" buttons to .com for an even better UX.
There was a problem hiding this comment.
Or even simpler:
atom://github?open=https://github.com/atom/github/pull/1525/files#diff-7e96b28649369913c5e87f137813ade5R13
You'd need to escape the #, but apart from that I think it would work.
|
Just FYI: I gave this another try:
Then it lets me switch between projects.. super fast! 🐎
But I think that's as far as my skills (and time) let me go.. 😅 Potentially clone the repo, check out the right branch, open the file, move the cursor to the right line.. would still need to be added. Plus probably tons of edge cases. |
A quick way to switch from github.com to Atom.
✨ Rendered ✨