Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

vi mode using vim-spyder

Abierto
  • ¿Algo no está bien?
#424 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python, vim
Área
desktop

Línea de trabajo

Comienza revisando la prueba de concepto existente, el plugin vim-spyder y los componentes internos de cq-editor implicados en su editor y en la UI de sus ventanas acoplables. Se considera terminado cuando se haya seleccionado una de las tres vías de integración y definido un alcance concreto que se pueda fusionar para la compatibilidad con la edición al estilo de vi.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I've been toying with ways to add vi-style editing support to the editor. To reduce duplication of work I've focused on re-using as much as possible from the vim-spyder plugin for Spyder. I've gotten a proof of concept mostly working, most of what remains is filling in boilerplate. Before I move ahead on this though I'd like to discuss how to go about it and whether it's worth investing my time (if there's no chance this will ever get merged anyway, I won't).

Getting this Spyder plugin to work with cq-editor is not difficult, the options revolve around the trade off between whether one wants to be able to use the plugin as-is, without any changes, which would require changes to the cq-editor internals; or a way that is less invasive but would require changes to the plugin, breaking compatibility, which is mostly an 'in the future' issue (and fwiw the last update to this plugin is from 6 months ago).

Roughly I see three paths:

  • 'Full compatiblity' - this basically entails emulating Spyder's full plugin system in cq-editor. It would allow more plugins to be used as is (although I don't know of any, especially not ones relevant to cq-editor's use case, then again I'm not well versed in Spyder's ecosystem). It would require fairly significant changes to cq-editors internals as in Spyder, everything is a plugin (including things like the editor, debugger etc). Those changes constitute adding interfaces so that most/all parts of cq-editor can be accessed and modified by plugins from the outside. Code complexity think hundreds of lines over many/almost all of the code.

  • 'Halfway' - with some minor modifications to both cq-editor's internals and (a fork of) the spyder-vim plugin, most of the functionality of the plugin could be unlocked. This is mostly adding the very basics of Spyder's plugin system to cq-editor (adding a plugin registry for external plugins, instantiating and initializing plugins, some basic callbacks/notifications) and some changes to the UI (basically, adding a QVBoxLayout to all docking windows that don't have it so that the UI can be customized from plugins). Code complexity think dozens/low hundreds of lines across a few files. This is most closely to what I have now in my prototype.

  • Forget about plugins and just copy the required functionality from spyder-vim. This would require the same UI changes as above but the rest could be copied over from the plugin and integrated into cq-editor where needed. I think it would still be possible to keep some files verbatim from spyder-vim so that if they make any changes, it would only be a matter of copying over those files again to get the benefit of the upgrades. Complexity think a few dozen/low hundreds across a few files.

I would appreciate feedback on this matter, even if negative so that I know if I should continue thinking about this. Thanks.

Lenguaje dominante
Python
Estrellas
1.3k
Forks
211
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CadQuery/CQ-editor

Todos los issues de CadQuery/CQ-editor

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.