Redesign ExtensionService to use granular feature interfaces
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 20/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- csharp, powershell
- Domínio
- api, developer-experience
Direção de pesquisa
Comece lendo ExtensionService, IEditorOperations, IEditorWindowFeature e EditorObject para entender a API atual do editor e o modelo de registro. A issue estará concluída quando recursos granulares puderem ser registrados de forma independente, APIs não compatíveis forem tratadas conforme descrito e os chamadores puderem consultar recursos de alto nível compatíveis.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Right now all editor features are exposed through a monolithic interface IEditorOperations. I think it would be better to go with a model that depends on more granular interfaces like IEditorWindowFeature which can be registered with the ExtensionService at runtime to light up that feature in the $psEditor API.
An editor integration may not want or need to expose all of the possible $psEditor features (like the $psEditor.Window section). If the editor did not register the feature interface of a particular part of the API, we would throw a NotImplementedException when the methods of that API are called. To allow callers to know whether the API is supported or not, we could provide an object on $psEditor which indicates which high-level parts of the API are supported.
This will also help with registering editor-specific feature APIs. For instance, if there are APIs which are only relevant to the VS Code editor, a feature interface could be registered for that only when the PSES language server is launched from VS Code. For any other editor, those APIs wouldn't be visible to the PowerShell session (only exposed via a "note property" added at runtime). Any developer interacting the EditorObject at runtime via C# could be able to query for the VS Code feature interface to see if those APIs are available.
Still thinking this through...
- Linguagem predominante
- C#
- Estrelas
- 767
- Forks
- 266
- Merge médio
- 3d 16h
- PRs com merge (30d)
- 1
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de PowerShell/PowerShellEditorServices
-
[Bug] None of the string overloads of `EditorExtensionServiceProvider.GetService()` work on .NET. Aberta
PowerShell/PowerShellEditorServices#2331 · 1 reação · 2 responsáveis ·
-
Area-Language Server Issue-Enhancement
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
PowerShell/PowerShellEditorServices#2315 · 1 comentário ·
-
Area-Debugging Issue-Enhancement
PowerShell/PowerShellEditorServices#2294 · 1 reação · 2 responsáveis ·
-
Issue-Bug Needs: Triage
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
PowerShell/PowerShellEditorServices#2293 · 1 comentário ·
-
PowerShell/PowerShellEditorServices#2282 · 1 comentário · 1 reação · 2 responsáveis ·
Todas as issues de PowerShell/PowerShellEditorServices
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
-
:watch: Not Triaged 11.0 fundamentals/subsvc
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 92/100
dotnet/AspNetCore.Docs#37699 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
SubtitleEdit/subtitleedit#15108 · 1 comentário ·
-
area/docs-content Bug pulumi/docs
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 94/100
-
agentic-workflows untriaged
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100