[Tracking] RFC-001: Allow guests to collaborate on multiple remote buffers

[jasonrudolph]

We intend to implement RFC-001 via a series of pull requests. This will allow developers to start benefiting from the completed RFC-001 functionality without having to wait for all of RFC-001 to be completed. We'll use this issue to track progress.

TODO

• When following the host, any time they switch to a new buffer, a new editor for that remote buffer is automatically added to your workspace and focused. Existing editors for previous remote buffers are not automatically closed when this switch occurs. (Allow guests to collaborate on multiple remote buffers (Part 1) #262) (v0.3.0)
• When a host closes a buffer, it is removed from all guest portals. (Allow guests to collaborate on multiple remote buffers (Part 1) #262) (v0.3.0)
• When you are following a guest and the guest navigates to a different buffer in the same portal, you follow them to that buffer. (Allow guests to collaborate on multiple remote buffers (Part 1) #262) (v0.3.0)
• Show site position avatars for participants that are in non-portal pane items (Enhance site position avatar UI/UX for RFC-001 #332)
• Allow guests to use fuzzy-finder to open any remote editor shared by the host (Allow guests to use fuzzy-finder to open any remote editor shared by the host #323)
• Once the fuzzy-finder support is in place, consider removing the logic that causes guests to automatically re-follow the host when the portal goes from n to zero remote items. (If the guest is working in a local editor when the portal goes from n to zero remote items, and we automatically re-follow the host, it will yank the guest away from their current editor. We'd like to avoid that. 😬) (Allow guests to use fuzzy-finder to open any remote editor shared by the host #323)
• Close remote buffers on guest when portal gets closed or disconnected (Close remote buffers on guest when host closes portal #319)

---

Refs: #231 (which introduced RFC-001)

[nathansobo]

I'd like to explore our handling of the host closing a buffer. Currently, I think we're planning on warning hosts when they close buffers while guests are editing. Another option could be to go ahead and remove the editor from the host's workspace, but maintain a reference to the buffer in the host's pool (keep it's ref count above zero). This would allow guests to continue to edit and save the buffer.

One downside of this is that the host might not be aware of continued changes to particular buffers, although as we improve visibility of participant buffers this could be mitigated. I think it could be worth it though, because it prevents the need to prompt the host when closing buffers and could make it easier to bridge to a world where guests can open any file from the host's file system via the fuzzy finder.

[jasonrudolph]

Teletype v0.3.0 is now available. It adds support for the first set of enhancements noted in the issue body:

• When following the host, any time they switch to a new buffer, a new editor for that remote buffer is automatically added to your workspace and focused. Existing editors for previous remote buffers are not automatically closed when this switch occurs.
• When a host closes a buffer, it is removed from all guest portals.
• When you are following a guest and the guest navigates to a different buffer in the same portal, you follow them to that buffer.

[jasonrudolph]

@simurai: Because other collaborators in the portal might be viewing a different part of the editor than you're viewing, or they might be viewing a completely different editor, we're looking for a way to visually represent where other collaborators are working, and we'd love to hear what you think. 😄

Here's what we have so far:

A. Top-right: Collaborators in the same editor but in a row above your viewport. Clicking on avatar will take you to that collaborator's location and start following them.

B. Middle-right: The collaborator you're currently following (if any). This collaborator is working inside the current viewport. If they move elsewhere in the editor, your editor scrolls accordingly. If they move to a different editor, you follow them to their new editor.

C. Middle-right: Other collaborators in the same editor and inside your viewport. Clicking on avatar start following that collaborator.

D. Bottom-right: Collaborators in the same editor but in a row below your viewport or a column outside of your viewport. Clicking on avatar will take you to that collaborator's location and start following them.

E. Bottom-right: Collaborators in a different editor in the portal. Clicking on avatar will take you to the editor that the collaborator is working in, scroll to their location in that editor, and start following them.

F. (Not Yet Implemented) Bottom-right: Collaborators in a different pane item not associated with the portal. Since the collaborator is working on something that's not part of the portal, you can't click on them to go to their location.

We'd like a way to visually distinguish D, E, and F. Can you share any thoughts you might have on ways to visually represent this distinction?

[simurai]

👋 @IbisLiven kindly started a new issue 👉 #286

[simurai]

Allow guests to use fuzzy-finder to open any remote editor shared by the host

I have a couple questions re ☝️ :

• Do guests have to know the file name of a shared remote editor in order to fuzzy find it?
• "any remote editor". Does that mean only tabs/files that the host currently has opened?
• How many files are typically edited in a collaboration session. I guess just a handful, right?

Because it might be easier to discover what everyone is currently working on by showing all the remote files in the tooltip. Together with the avatars. So you can open files or follow somebody from there.

Read somewhere that the plan is to share the whole project (in the tree-view?). So this might only be a stop-gap.

[haacked]

FWIW, I found the behavior to add all open files to the portal a bit surprising. It may be because my particular workflow is more focused on note taking than on pair programming.

I tend to have a lot of buffers open in Atom. Sometimes I want to pair with someone on a single file and don't want them to see all the others I have open. It's not immediately clear to me when I share a workspace what exactly is being shared. Previous behavior of Teletype lead me to believe it's just the file I'm working on.

And after sharing the file, I might need to work on something unrelated to the pairing session in private. I don't want to accidentally share that file by simply opening it. I think it needs to be crystal clear what's being shared, what's not being shared.

Not to prescribe solutions, but here's one idea in the interest of generating better ideas. 😄 If we had the Teletype icon in the tab for shared buffers, that'd make it clear what buffers are being shared. The icon could be in the tree view too if you allow people to edit files that are not open. You could click on the icon in the tab to unshare. Then whether opening a new file adds it to the shared workspace or not could depend on user settings or the type of Teletype session (Share a workspace vs share a file).

[simurai]

Previous behavior of Teletype lead me to believe it's just the file I'm working on.

Even that was a bit risky. For example when closing a buffer, the buffer to the left will become active (and shared). Which might show something you didn't intend to share. 🙈

And with the fuzzy-finder integration and maybe later the tree-view too, you have to assume that people can find anything in your workspace.

Opt-out

You could click on the icon in the tab to unshare.

Yeah, that could be an option. As a host, after sharing your workspace, but before telling other people your Portal ID, you could look through your tabs and projects/folders to see if there is anything you want to hide from collaborators.

Although that could be a bit of a chore and anxiety inducing having to think what to exclude every time you want to share your workspace. What about the opposite?

Opt-in (new window)

For people with a lot of secrets, it might be easier to opt-in what to share. I guess you could right-click your current file and then choose "Open In New Window" (although currently it opens all files, which I think is a bug). Then start to share that workspace. Now you're free to add new files and folders as needed.

Downsides:

• Takes a while to open a new window.
• You can't drag + drop files between windows that don't have the same root folder.

Opt-in (tree-view)

Or it could be part of the tree-view. Similar to those packages that show opened files:

Then you can add/remove files/folders and have more control what exactly people can see.

---

After talking to @ampinsk, @venetucci and @donokuda, here a few more ideas:

Show what gets shared

Could be a list of folders/files, or a warning like:

More prominent "is sharing" mode

Currently only the colored status-bar icon is a reminder that you're currently sharing your workspace. There could be stronger indication, like a border (like when screen sharing in Zoom):

A setting to exclude certain patterns

Matching files/folders will get greyed-out in the tree-view.

[jasonrudolph]

• Allow guests to use fuzzy-finder to open any remote editor shared by the host

@simurai: Thanks for the thoughts in #268 (comment). @as-cii and I were looking into this today, and we wanted to share some additional context.

Responding to questions from #268 (comment)

Do guests have to know the file name of a shared remote editor in order to fuzzy find it?

The fuzzy-finder shows a maximum of 10 items at a time.

We're using the fuzzy-finder's buffer view (command+b on macOS), which currently shows all your local buffers. With that in mind, if a guest has no local buffers open, and they're collaborating in a single portal, and that portal has 10 or fewer remote files in the portal, then the guest will see a list of all 10 remote files. However, if the guest has several local buffers open, and/or if they're participating in a portal with more than 10 total remote files, and/or if they're participating in multiple portals, there may be more than 10 total buffers available, and the fuzzy finder will only show 10 items at a time.

"any remote editor". Does that mean only tabs/files that the host currently has opened?

That's right.

How many files are typically edited in a collaboration session. I guess just a handful, right?

I don't have any hard data available, but from using Teletype to build Teletype, I can say that we commonly collaborate on 5-20 files in a single collaboration session. Sometimes more.

I think the design in #268 (comment) would struggle to scale to this many files, so I'd love to explore other options. We're currently thinking that the fuzzy-finder would be a good fit, but we're open to other ideas.

UI/UX goals for finding and opening remote files

We think that the UI should satisfy the following goals:

• Distinguish remote files vs. local files - When choosing files to open (e.g., with the fuzzy-finder UI), clearly distinguish local files from remote files
• Discover available remote files - When working locally, the fuzzy-finder is only useful when you know that a specific file exists, and then you can use the fuzzy-finder to locate it. You might know which files exist based on your familiarity with the project or by seeing files in the tree-view. As a guest in a portal, the fuzzy-finder will allow you to open any buffers that the host is sharing, but that set of buffers isn't necessarily the full set of files in a project. With that in mind, how can we best allow a guest to discover the set of remote files that they can open?
• Maybe: Distinguish between multiple portals - Because you can be a guest of multiple portals, we may also want to distinguish portal A's files from portal B's files when choosing files to open via the UI

@simurai: Would you be willing to put together some fuzzy-finder mockups that attempt to satisfy those goals? (Note: If you think that something other than the fuzzy-finder would be a better fit for satisfying these goals, definitely let us know.)

[simurai]

Here some ideas:

1. Teletype fuzzy-finder keybinding

Currently the fuzzy-finder has these keybindings:

• cmd-t or cmd-p to open the file finder
• cmd-b to open the list of open buffers
• cmd-shift-b to open the list of Git modified and untracked files

Teletype could introduce a new modifier key to find remote files, e.g. alt:

• cmd-alt-t to find any remote file
• cmd-alt-b to find only remote buffers that the host has open
• cmd-alt-shift-b to find remote Git modified and untracked files

Concerns: Yet another keybinding to remember. Could be mitigated by adding some hints/links in the Teletype popup.

• Solved: Distinguish remote files vs. local files. 👉 Because it's a different keybinding, local and remote would never get mixed in the same list and are nicely separated.
• Unsolved: Discover available remote files. 👉 You could cmd-alt-t to find any file, but you still have to know the file name.
• Unsolved: Distinguish between multiple portals. 👉 There could be a chord with a number involved. Like k1 cmd-b, k2 cmd-b etc. But might be cramp inducing.

2. It's just a (remote) project

Currently Atom allows to add multiple root projects. When joining a portal, it could be treated just like adding another root project. Then if you open the fuzzy-finder it shows local and remote files with a different path. Like @simurai/teletype/package.json. Or teletype/package.json (Shared by @simurai) to make it look less like it's a remote repo:

A new root project will appear in the tree-view that can be used to discover files. Remote projects and files get an (@username) added:

• Solved: Distinguish remote files vs. local files. 👉 Remote files show a @username.
• Solved: Discover available remote files. 👉 Tree-view can be used to find files even if you're not familiar with a project.
• Solved: Distinguish between multiple portals. 👉 There will be multiple root projects. Tabs and fuzzy-finder show different @usernames.

Open question: What happens if the host has multiple root projects. Would a guest get all of them added to the tree-view?

2B. with avatars

To make remote projects visually even more distinct, the host's avatar could be used instead of the @username.

3. custom panel

Teletype could have its own panel in a dock. With a buddy list. After joining a portal, you can drill down and open a file filter/browser:

• Unsolved: Distinguish remote files vs. local files. 👉 A panel alone wouldn't solve it, remote buffers would still need a @username in the tab title, like in option 2.
• Solved: Discover available remote files. 👉 Has its own tree-view.
• Solved: Distinguish between multiple portals. 👉 Each portal has their own sub-view.

---

Personal opinion: Option 3 could be slick because everything is custom made and optimized for this use-case. At the same time it feels less integrated and more like "tacked on". Therefore I would give option 2 a try first by reusing existing ways (fuzzy-finder, tree-view).

Some people probably don't like having local and remote projects mixed. In that case they can open a new (empty) window before joining a portal. Then everything is separated and the local project stays untouched.

[jasonrudolph]

Here some ideas:

Thank you, @simurai! 🙇⚡

With #323, we're pursuing the option you described in 2B:

Regarding the tree-view integration:

A new root project will appear in the tree-view that can be used to discover files. Remote projects and files get an (@username) added: ...

We're focused on the fuzzy-finder integration for this initial implementation, but I like the idea of also integrating with the tree-view. We'll keep that in mind as a future enhancement.

[nathansobo]

🎉