Inconsistency between single-folder workspace and multi-root workspace

[Vivecccccc]

I was aware that adding the 1st folder to an empty workspace will not fire any event to trigger the onDidChangeWorkspaceFolders listener. This can be explained by:

Note: this event will not fire if the first workspace folder is added, removed, or changed, because in that case, the currently executing extensions (including the one that listens to this event) will be terminated and restarted so that the (deprecated) rootPath property is updated to point to the first workspace folder.

Since I set activationEvents with "workspaceContains:**", the activate function would be [expectedly] executed after the 1st folder is selected. However, when I added a 2nd folder to the workspace, the activate function was again [unexpectedly] executed. Adding a 3rd folder to the workspace would not execute the activate function anymore; instead, it would trigger the onDidChangeWorkspaceFolders listener, which was [expected].

My idea was that the "inconsistency" was due to the difference between a "single-folder" workspace and a "multi-root" workspace. But it still introduces some unexpected cases when trying to listen to the changes of the workspace folders.

Kindly seek more insights and much appreciated for the advice.

[isidorn]

Are you still facing this issue? If yes, I see you have documented the behavior. Where you able to handle the events in such a way that you achieve what you want? Thanks

[Vivecccccc]

Hi, thanks for replying. This issue still exists, and interestingly I find that the changing between single-folder workspace and multi-root workspace seems won't really trigger deactivate function - I have a badge recursively counting the number of opened folders from a treeview, and when changing to multi-root workspace, the badge will still be there, remaining the same count as before - though I dispose the treeview provider in deactivate function.

Though this little glitch still annoys me a bit, I guess fixing this might be not as easy as it seems. My solution could only be regarded as some workarounds to reduce the impact and may not be a good reference to others encounting the similar issue.

[isidorn]

@bpasero might be able to help

[bpasero]

When a single-folder workspace turns into a multi-root workspace, we forcefully restart the extension host because some API changes as a matter of that and this was the only way to not break our API.

See microsoft/vscode#69335

[Karliz24]

Sabía que agregar la primera carpeta a un espacio de trabajo vacío no activaría ningún evento para activar el onDidChangeWorkspaceFoldersdetector. Esto se puede explicar de la siguiente manera:

Nota: este evento no se activará si se agrega, elimina o modifica la primera carpeta del espacio de trabajo, porque en ese caso, las extensiones que se están ejecutando actualmente (incluida la que escucha este evento) se finalizarán y reiniciarán para que la propiedad rootPath (obsoleta) se actualice para apuntar a la primera carpeta del espacio de trabajo.

Como configuré activationEventscon "workspaceContains:**", la activatefunción se [ esperaba ] ejecutar después de seleccionar la primera carpeta. Sin embargo, cuando agregué una segunda carpeta al espacio de trabajo, la activatefunción se ejecutó nuevamente [ inesperadamente ]. Agregar una tercera carpeta al espacio de trabajo activateya no ejecutaría la función; en cambio, activaría al onDidChangeWorkspaceFoldersoyente, lo cual era [ esperado ].

Mi idea era que la "inconsistencia" se debía a la diferencia entre un espacio de trabajo de "una sola carpeta" y un espacio de trabajo de "múltiples raíces". Pero aún así, se presentan algunos casos inesperados al intentar escuchar los cambios de las carpetas del espacio de trabajo.

Por favor, busque más información y agradeceré mucho el consejo.