Format-on-save action doesn't re-save the buffer?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- typescript
- Área
- tooling
Línea de trabajo
Inspecciona src/CodeFormatManager.ts alrededor del flujo de onDidSave y applyTextEditsToBuffer, y después lee los casos relacionados en spec/CodeFormatManager-spec.ts en las líneas 80-115. Verifica si aplicar las ediciones del proveedor deja el buffer como dirty y si se espera un segundo TextBuffer::save; se considera terminado cuando el comportamiento está cubierto por las specs y coincide con la semántica de guardado prevista.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I know this repo is somewhat dormant, but I wanted to check in as a first step:
Suppose you've got a language server that can reformat an entire document on save. This package listens for onDidSave, debounces the event, then asks a provider to format the buffer. The edits are applied, and then… the buffer is not saved to disk again. The applyTextEditsToBuffer function delegates to a library function that explicitly says “the changes will be applied to the buffer but not saved.”
Judging by the specs, I don't think this was intentional behavior. This spec seems to verify that, when a provider has no edits to suggest, there are no further calls to TextBuffer::save; I think the implication there is that a second save would happen if the provider did supply edits, but it's hard to say.
Meanwhile, this spec verifies that a provider is invoked when an editor is saved, and that the resulting text matches expectations, but it does not check if the buffer is dirty.
If this was merely an oversight, I can submit a PR. If it's intentional behavior, perhaps it could be governed by a config setting? And if this package is unmaintained, that's fine, but I figured I'd ask before forking.
- Lenguaje dominante
- TypeScript
- Estrellas
- 5
- Forks
- 3
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de atom-community/atom-ide-code-format
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
atom-community/atom-ide-code-format#15 · 4 comentarios ·
Todos los issues de atom-community/atom-ide-code-format
Issues similares
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
components-web-app/docs#260 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
521xueweihan/HelloGitHub#4025 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
ctrf-io/playwright-ctrf-json-reporter#117 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
voidzero-dev/void#478 ·
Los mantenedores suelen responder en 1 día