This pull request introduces a first iteration of the location API. Specifically, WorkTree will now support the following methods:
setActiveLocation(buffer: Buffer | null), which can be used to transmit the location of the local replica.
getReplicaLocations, which returns a Map<ReplicaId, Path> of the active path for every other replica that we have received a location operation for.
Future steps
In the future I believe we should enhance this API to also supply a SelectionSetId. This is because any given buffer could have an arbitrary number of selections (e.g., when multiple editors are backed by the same buffer), and we want to provide a way of determining which one is the one currently used by each replica.
A digression about paths
At some point I think we should do something about all these path-based APIs, as they prevent Memo from being used in contexts where untitled buffers can be created. Path-based APIs are nice in that they don't get invalidated when switching epochs, contrarily to FileIds which are tied only to a given epoch. I can think of different ways of solving this:
Generate stable synthetic file identifiers in WorkTree that span across epochs; this would be similar to what we do with buffer ids, but wouldn't require opening a text file (and thus retrieve its base text) to use it in the API. This could potentially require a lot of tracking, though, even for files that are never opened.
Don't try to hide the ephemerality of a FileId to clients, allowing them to decide what to do each time. Maybe these ids can literally include the epoch they belong to and memo could generate an error when trying to resolve one of them on a different epoch. We could still keep the path-based and buffer-based APIs, but we would return and accept FileIds in those contexts where it makes sense (such as the new location API proposed in this pull request).
This pull request introduces a first iteration of the location API. Specifically,
WorkTreewill now support the following methods:setActiveLocation(buffer: Buffer | null), which can be used to transmit the location of the local replica.getReplicaLocations, which returns aMap<ReplicaId, Path>of the active path for every other replica that we have received a location operation for.Future steps
In the future I believe we should enhance this API to also supply a
SelectionSetId. This is because any given buffer could have an arbitrary number of selections (e.g., when multiple editors are backed by the same buffer), and we want to provide a way of determining which one is the one currently used by each replica.A digression about paths
At some point I think we should do something about all these path-based APIs, as they prevent Memo from being used in contexts where untitled buffers can be created. Path-based APIs are nice in that they don't get invalidated when switching epochs, contrarily to
FileIds which are tied only to a given epoch. I can think of different ways of solving this:WorkTreethat span across epochs; this would be similar to what we do with buffer ids, but wouldn't require opening a text file (and thus retrieve its base text) to use it in the API. This could potentially require a lot of tracking, though, even for files that are never opened.FileIdto clients, allowing them to decide what to do each time. Maybe these ids can literally include the epoch they belong to and memo could generate an error when trying to resolve one of them on a different epoch. We could still keep the path-based and buffer-based APIs, but we would return and acceptFileIds in those contexts where it makes sense (such as the new location API proposed in this pull request).