¿Cómo puede un editor de código insinuar efectivamente el nivel de anidación de código, sin usar sangría? [cerrado]

233

He escrito un editor de texto XML que proporciona 2 opciones de visualización para el mismo texto XML, uno con sangría (virtualmente) y el otro justificado a la izquierda. La motivación para la vista justificada a la izquierda es ayudar a los usuarios a 'ver' los caracteres de espacios en blanco que están utilizando para sangrar el texto sin formato o el código XPath sin interferencia de la sangría, que es un efecto secundario automatizado del contexto XML.

Quiero proporcionar pistas visuales (en la parte no editable del editor) para el modo justificado a la izquierda que ayudará al usuario, pero sin ser demasiado elaborado.

Intenté simplemente usar líneas de conexión, pero eso parecía demasiado ocupado. Lo mejor que he encontrado hasta ahora se muestra en una captura de pantalla simulada del editor a continuación, pero estoy buscando alternativas mejores / más simples (que no requieren demasiado código).

indicación del nivel de anidamiento del editor de código

[Editar]

Tomando la idea del mapa de calor (de: @jimp) obtengo esto y 3 alternativas, etiquetadas como a, byc:

Ideas iniciales

La siguiente sección describe la respuesta aceptada como una propuesta, reuniendo ideas de una serie de otras respuestas y comentarios. Como esta pregunta ahora es wiki comunitaria, no dude en actualizarla.


NestView

El nombre de esta idea que proporciona un método visual para mejorar la legibilidad del código anidado sin usar sangría.

Lineas de contorno

El nombre de las líneas sombreadas de forma diferente dentro de NestView

ingrese la descripción de la imagen aquí

La imagen de arriba muestra el NestView utilizado para ayudar a visualizar un fragmento XML. Aunque se usa XML para esta ilustración, cualquier otra sintaxis de código que use anidamiento podría haberse usado para esta ilustración.

Una descripción general:

  1. Las líneas de contorno están sombreadas (como en un mapa de calor) para transmitir el nivel de anidación

  2. Las líneas de contorno están en ángulo para mostrar cuándo se abre o se cierra un nivel de anidamiento.

  3. Una línea de contorno vincula el inicio de un nivel de anidación al final correspondiente.

  4. El ancho combinado de las líneas de contorno da una impresión visual del nivel de anidación, además del mapa de calor.

  5. El ancho de NestView puede ser redimensionable manualmente, pero no debe cambiar a medida que cambia el código. Las líneas de contorno se pueden comprimir o truncar para mantener esto.

  6. Las líneas en blanco a veces se usan para dividir el texto en fragmentos más digeribles. Dichas líneas podrían desencadenar un comportamiento especial en NestView. Por ejemplo, el mapa de calor podría restablecerse o utilizarse una línea de contorno de color de fondo, o ambos.

  7. Se pueden resaltar una o más líneas de contorno asociadas con el código seleccionado actualmente. La línea de contorno asociada con el nivel de código seleccionado se enfatizaría más, pero otras líneas de contorno también podrían 'iluminarse' además de ayudar a resaltar el grupo anidado que lo contiene

  8. Se pueden asociar diferentes comportamientos (como plegado de código o selección de código) al hacer clic / doble clic en una línea de contorno.

  9. Las diferentes partes de una línea de contorno (borde inicial, medio o posterior) pueden tener diferentes comportamientos dinámicos asociados.

  10. La información sobre herramientas se puede mostrar en un evento de desplazamiento del mouse sobre una línea de contorno

  11. NestView se actualiza continuamente a medida que se edita el código. Cuando el anidamiento no está bien equilibrado, se pueden hacer suposiciones donde el nivel de anidación debe terminar, pero las líneas de contorno temporales asociadas deben resaltarse de alguna manera como advertencia.

  12. Se pueden admitir los comportamientos de arrastrar y soltar de las líneas de contorno. El comportamiento puede variar según la parte de la línea de contorno que se arrastre.

  13. Las características que se encuentran comúnmente en el margen izquierdo, como la numeración de líneas y el resaltado de color para errores y cambio de estado, podrían superponer NestView.

Funcionalidad adicional

La propuesta aborda una serie de cuestiones adicionales: muchas están fuera del alcance de la pregunta original, pero son un efecto secundario útil.

Vincular visualmente el inicio y el final de una región anidada

Las líneas de contorno conectan el inicio y el final de cada nivel anidado.

Destacando el contexto de la línea seleccionada actualmente

A medida que se selecciona el código, se puede resaltar el nivel de nido asociado en NestView

Diferenciar entre regiones de código en el mismo nivel de anidamiento

En el caso de XML, se pueden usar diferentes tonos para diferentes espacios de nombres. Los lenguajes de programación (como c #) admiten regiones con nombre que podrían usarse de manera similar.

División de áreas dentro de un área de anidación en diferentes bloques visuales

Las líneas adicionales a menudo se insertan en el código para facilitar la legibilidad. Tales líneas vacías podrían usarse para restablecer el nivel de saturación de las líneas de contorno de NestView.

Vista de código de varias columnas

El código sin sangría hace que el uso de una vista de varias columnas sea más eficaz porque es menos probable que se requiera el ajuste horizontal o el desplazamiento horizontal. En esta vista, una vez que el código ha llegado al final de una columna, fluye a la siguiente:

ingrese la descripción de la imagen aquí

Uso más allá de simplemente proporcionar una ayuda visual

Como se propone en la descripción general, NestView podría proporcionar una gama de características de edición y selección que estarían en línea con lo que se espera de un control TreeView. La diferencia clave es que un nodo TreeView típico tiene 2 partes: un expansor y el ícono del nodo. Una línea de contorno NestView puede tener hasta 3 partes: un abridor (inclinado), un conector (vertical) y un cierre (inclinado).


En sangría

NestView se presenta junto con complementos de código sin sangría, pero es poco probable que reemplace la vista de código con sangría convencional.

Es probable que cualquier solución que adopte un NestView proporcione un método para cambiar sin problemas entre vistas de código con sangría y sin sangría sin afectar el texto del código, incluidos los espacios en blanco. Una técnica para la vista con sangría sería 'Formato virtual', donde se utiliza un margen izquierdo dinámico en lugar de caracteres de tabulación o espacio. Los mismos datos de nivel de anidamiento utilizados para renderizar dinámicamente el NestView también podrían usarse para la vista con sangría de aspecto más convencional.

Impresión

La sangría será importante para la legibilidad del código impreso. Aquí, la ausencia de caracteres de tabulación / espacio y un margen izquierdo dinámico significa que el texto puede ajustarse en el margen derecho y aún así mantener la integridad de la vista con sangría. Los números de línea se pueden usar como marcadores visuales que indican dónde se envuelve el código y también la posición exacta de la sangría:

ingrese la descripción de la imagen aquí

Screen Real-Estate: Flat Vs Sangría

Abordar la pregunta de si NestView usa bienes inmuebles de pantalla valiosos:

Las líneas de contorno funcionan bien con un ancho igual al ancho de caracteres del editor de código. Por lo tanto, un ancho de NestView de 12 anchos de caracteres puede acomodar 12 niveles de anidamiento antes de que las líneas de contorno sean truncadas / comprimidas.

Si una vista con sangría usa 3 anchos de caracteres para cada nivel de anidación, entonces el espacio se guarda hasta que la anidación alcance 4 niveles de anidación, después de este nivel de anidación, la vista plana tiene una ventaja de ahorro de espacio que aumenta con cada nivel de anidación.

Nota: A menudo se recomienda una sangría mínima de 4 anchos de caracteres para el código, sin embargo, XML a menudo se gestiona con menos. Además, el formato virtual permite que se use menos sangría porque no hay riesgo de problemas de alineación

A continuación se muestra una comparación de las 2 vistas:

ingrese la descripción de la imagen aquí

Con base en lo anterior, es probable que sea justo concluir que la elección del estilo de vista se basará en otros factores además del espacio real de la pantalla. La única excepción es cuando el espacio de la pantalla es escaso, por ejemplo, en una Netbook / Tablet o cuando se abren múltiples ventanas de código. En estos casos, el NestView redimensionable parecería ser un claro ganador.

Casos de uso

Ejemplos de ejemplos del mundo real donde NestView puede ser una opción útil:

  1. Donde la propiedad inmobiliaria de pantalla es muy importante

    a. En dispositivos como tabletas, blocs de notas y teléfonos inteligentes

    si. Al mostrar código en sitios web

    C. Cuando múltiples ventanas de código necesitan estar visibles en el escritorio simultáneamente

  2. Donde la sangría consistente de espacios en blanco del texto dentro del código es una prioridad

  3. Para revisar código profundamente anidado. Por ejemplo, donde los idiomas secundarios (por ejemplo, Linq en C # o XPath en XSLT) pueden causar altos niveles de anidamiento.

Accesibilidad

Se deben proporcionar opciones de cambio de tamaño y color para ayudar a las personas con discapacidad visual y también para adaptarse a las condiciones ambientales y las preferencias personales:

ingrese la descripción de la imagen aquí

Compatibilidad del código editado con otros sistemas.

Idealmente, una solución que incorpore una opción NestView debería ser capaz de eliminar los caracteres de tabulación y espacio iniciales (identificados como que solo tienen una función de formateo) del código importado. Luego, una vez despojado, el código podría representarse perfectamente en las vistas con sangría y justificadas a la izquierda sin cambios. Para muchos usuarios que confían en sistemas como herramientas de fusión y diferencia que no son conscientes de los espacios en blanco, esto será una gran preocupación (si no un completo show-stopper).


Otros trabajos:

Visualización de marcado superpuesto

La investigación publicada por Wendell Piez , fechada en 2004, aborda el tema de la visualización de marcas superpuestas, específicamente LMNL . Esto incluye gráficos SVG con similitudes significativas con la propuesta NestView, como tal, se reconocen aquí.

Las diferencias visuales son claras en las imágenes (a continuación), la distinción funcional clave es que NestView está diseñado solo para XML o código bien anidados, mientras que los gráficos de Wendell Piez están diseñados para representar anidamiento superpuesto.

ingrese la descripción de la imagen aquí

Los gráficos anteriores se reprodujeron, con el amable permiso, de http://www.piez.org

Fuentes:

  1. Hacia el marcado hermenéutico
  2. Medio paso hacia LMNL
pgfearo
fuente
66
No tengo una respuesta real para ti, solo una opinión. Mirando sus ejemplos, B es mi opción preferida. Se destaca para mí porque el "mapa de calor" en realidad sigue la sangría en lugar de reflejarla como el primer ejemplo y C hace. A también sigue la sangría real, pero B es más parecido a lo que vería cuando el xml real estuviera sangrado. El segundo ejemplo es simplemente demasiado "sólido" para mi gusto.
Marjan Venema
44
Prefiero el código sangrado yo mismo. ¿No está seguro de cuál sería el beneficio de esto? ¿Me estoy perdiendo algo obvio? (Realmente no tengo la intención de que esto suene negativo.)
Chris
99
No veo cómo tomar un margen enorme en el 100% de las líneas es mejor que tomar solo el margen que necesita cada línea.
John Gietzen
1
@John Gietzen. El objetivo no es guardar el espacio en pantalla (aunque este puede ser el efecto en muchos casos). Es para permitir un control más estricto de los caracteres de espacio en blanco cuando eso es importante: aún se proporcionaría una vista con sangría (pero virtual, sin usar caracteres de relleno).
pgfearo
3
Estoy votando para cerrar esta pregunta como fuera de tema porque es una pregunta UX pero demasiado vieja para migrar.
Ratchet Freak

Respuestas:

104

He intentado responder mi propia pregunta aquí, pero esto está incorporando la idea del mapa de calor de @jimp y también la idea de 'hacer que sea más XML-ish' de @Andrea:

ingrese la descripción de la imagen aquí

Con suerte, los colores en el mapa de calor junto con las líneas angulares ayudan a dibujar el ojo entre las etiquetas de inicio y fin; quitar los separadores de línea horizontal mejora el "flujo" de principio a fin. A medida que el usuario selecciona con un elemento, la parte correspondiente en el mapa de calor se puede resaltar de alguna manera, tal vez con un borde brillante (como se muestra).

Editar He decidido seguir con esto, probablemente tendrá que haber opciones de usuario para los colores. Una captura de pantalla 'producción lista':

ingrese la descripción de la imagen aquí

Y para comparar ... la vista alternativa con sangría:

ingrese la descripción de la imagen aquí

Editar ahora, para el caso más anidado: probar mis habilidades de dibujo ...

ingrese la descripción de la imagen aquí

revs pgfearo
fuente
1
Se ve genial ! Buen trabajo. Pero, ¿cómo se verá cuando haya más sangría?
Loïc Lopes
1
@Louhike ¡Gracias! Sí, está al máximo en 4 niveles y no quiero estirar el margen izquierdo para obtener más, por lo que comprimiré el ancho de las barras verticales cada vez más en niveles de anidación más altos, un poco como un mapa de contorno con suerte.
pgfearo
2
@Louhike. Agregué una imagen adicional para mostrar cómo se verían las cosas con 9 niveles de anidamiento; después de unos 15 niveles, probablemente sería necesario fusionar las barras del medio, tal vez usando un relleno de degradado.
pgfearo
10
Esto es simplemente asombroso. +1 para llevar la edición de código y la interfaz de usuario al siguiente nivel. Alguien con una cuenta debe publicar esto en Hacker News, /.o r / programación.
Konrad Rudolph
2
Me
pregunté
24

Una idea podría ser intentar agregar 3D al texto. Aumenta / disminuye el tamaño de la fuente en función de su nivel.

Por ejemplo, este código:

ingrese la descripción de la imagen aquí

Se vería así:

ingrese la descripción de la imagen aquí

Puede resultar molesto trabajar con él, ya que pierde la alineación fija del tamaño del texto en diferentes niveles. Otra idea; cambiar la saturación de cada nivel:

ingrese la descripción de la imagen aquí

¿Qué tan bien se sostiene eso para algo realmente profundo? No es seguro...

De hecho, me gusta mucho tu idea de visualización de canalones; Es fácil agrupar las cosas. Quizás combinado con una de estas ideas se verá aún mejor, o mucho más horrible. ;)


Hace un tiempo, hice un mapa de calor que mostraba el alcance en C. Puede ser divertido observar una lluvia de ideas:

ingrese la descripción de la imagen aquí

Alineado a la izquierda:

ingrese la descripción de la imagen aquí

Dave Gallagher
fuente
2
Es tentador hacer algo con el texto, pero esto es difícil de hacer sin distraer al desarrollador mientras escribe o justo después. Los cambios que afectan la altura de la fuente causan problemas: posiblemente toleramos que nuestro código suba y baje incluso menos que de lado a lado. Me gusta su idea de sombrear el código, pero esto tendría que ser sutil ya que quiero tratar de mantener las cosas ordenadas.
pgfearo
2
¡Pero esto sería genial para entornos de enseñanza!
jcolebrand
La sugerencia de tamaño de fuente es extrañamente convincente, aunque puedo ver sus desventajas. ¿Por qué no hacer que la fuente más pequeña que el alcance es más profundamente anidado - esto ayudaría a desalentar la anidación profunda (aunque había causan problemas en los que anidación profunda es en realidad una solución sensata)
Peter
2
el mapa de calor es en realidad mucho mejor para visualizar el alcance que la visualización del alcance alineado a la izquierda (solución de @ pfgearo)
Sandeep
@Sandeep. Estoy de acuerdo en que esta es en muchos casos una mejor solución, especialmente cuando se revisa el código en lugar de editarlo. Las limitaciones técnicas (como se explica en la pregunta) me dificultan modificar el color de fondo con el control actual que estoy usando. Efectivamente, he usado el lado izquierdo del mapa de calor en esta respuesta, pero con los bordes inclinados hacia el área editada para ayudar a atraer la atención. Un problema con un fondo de texto en color es que la legibilidad / contraste se pierde a mayor niveles de anidamiento.
pgfearo
21

Simplemente modifica tu idea original y cambia de cuadrados a cápsulas. Creo que estas versiones (incluida la original) son más fáciles de leer porque son menos complejas que la que muestra el anidamiento a través de los elementos de visualización. Creo que los elementos de árbol transmiten la información de una manera más simple e intuitiva.

cápsulas

Creo que la izquierda es excelente para mostrar directamente la sangría, mientras que la derecha es mejor para transmitir una relación anidada.

Jeremy Giberson
fuente
2
Prefiero la suavidad de sus cápsulas, sin embargo, parecen demasiado separadas del texto, necesito algo que sea más coherente y que dé una visión más clara de cuáles son las partes que las contienen.
pgfearo
9

Mi idea:

El anidamiento se parece más a anidar. El ancho horizontal de cada capa no necesita ser tan ancho.

broc7
fuente
Creo que lo que estás proponiendo es esencialmente el mismo que la respuesta (inspirada por otros) que di pero sin las líneas inclinadas. Creo que las líneas inclinadas ayudan a dibujar mejor el ojo entre abrir y cerrar. El ancho no es un problema real porque (como se muestra en la imagen de 9 niveles) el ancho de la línea vertical es independiente del ancho de la línea inclinada, por lo que las líneas verticales se pueden comprimir.
pgfearo
Sí, pág. Lo noté después de publicar. Son topográficamente idénticos, para hacerse más elegantes. Supongo que es cuestión de gustos, pero mi versión simplemente me grita "anidando" de una manera que su versión no lo hace. Tal vez esta característica podría tener ambos y permitir que el usuario elija.
broc7
8

Me encanta la idea Mi sugerencia para mantener el "ocupado" sería utilizar gradientes en lugar de cuadrados. Reduciría las líneas. Quizás diferentes colores para una sangría extrema.

Yo diría que todo lo que tienes es genial, aunque un poco bloqueado para mis gustos.

Mis comentarios: He estado luchando constantemente con la forma en que el IDE de Visual Studio hace sangría. Me encantaría usar algo como esto o una variación.

Así que imagine ese enlace sin las líneas e inline con su código xml / actual.

Gauthier
fuente
Sí, las ideas siguen evolucionando. Las imágenes en la respuesta que envié (en lugar de mi pregunta) son menos cuadradas porque tienen pendientes iniciales / finales, estoy considerando usar gradientes (pero ligeramente diferentes) también para atenuar un poco las cosas. Estoy con ustedes en los diferentes colores, para una sangría alta, pero también para resaltar cosas como comentarios o errores. Y luego está el resaltado dinámico, para mostrar el contexto / depuración actual ... la dificultad será juzgar cuándo detenerse.
pgfearo
5

Dado que usted dijo que la visualización debe existir en el margen no editable (¿izquierdo?), Creo que eso significa que la visualización no puede mezclarse o estar detrás del código.

¿Quizás un mapa de calor en la columna izquierda, con colores más brillantes que indican una sangría más profunda? Haga que el margen sea de un tamaño fijo, con una visualización como la que tiene (espere ir de izquierda a derecha como lo haría la sangría) que utiliza dinámicamente todo el espacio dado de acuerdo con la sangría máxima determinada por la profundidad DOM.

Si estuviera dispuesto a pasar a la región del editor, sugeriría algo muy similar, pero como antecedentes del documento. El área sombreada sería donde estaría el espacio en blanco si se habilitara la sangría. En este caso, usaría un color sólido y claro que contrasta con el resaltado del texto.

pobre
fuente
@jimp Sí, la visualización no puede ser con o detrás del código; por mucho que me encantaría probar esto, mis habilidades / plataforma de codificación lo harían demasiado complejo. Los colores de fondo en el editor en sí son nuevamente difíciles, pero eso me da la idea de que podría probar diferentes tonos de color de primer plano. Probaré una barra de izquierda a derecha y un mapa de calor también como sugieres.
pgfearo
+1 para la idea del mapa de calor (Y) ... y puedo sugerir que el nivel de anidación esté dentro del color para personas con necesidades visuales especiales (como daltonismo).
M.Sameer
@pobre. Actualizado mi pregunta para ilustrar su idea mapa de calor, que me gusta, pero yo creo que tengo la cosa de izquierda a derecha mal ...
pgfearo
@pgfearo ¡Me alegra que mis ideas hayan sido útiles! Según lo que veo que has hecho, creo que me gusta más el L&F de derecha a izquierda. Lo siento, no tuve la oportunidad de volver antes (fin de semana ocupado). Como has hecho tanto progreso, solo comentaré la respuesta que publicaste anteriormente.
jimp
@pgfearo ¡Vaya, no tengo suficiente reputación para comentar tu respuesta! Publicaré algunas reflexiones sobre su respuesta una vez que obtenga ese privilegio, ¡con suerte pronto!
jimp
3

jGRASP hace esto usando un marcador visual en el margen:

ingrese la descripción de la imagen aquí

Incluso reconoce cuando está usando un bucle y usa un tipo diferente de línea para representar ese bucle interno.

Solo pensé en señalar cómo lo hace un editor existente.

ceniza
fuente
55
Demasiado ruidoso en mi opinión, pero sigue siendo una buena idea.
Konrad Rudolph
He buscado esto, y la documentación del sitio implica que la captura de pantalla es de un visor de código, es un diagrama, no un editor de código. Además, dado que no hay caracteres de relleno, sigue siendo una vista con sangría. Estoy buscando soluciones simples que no requieran una sangría del código, por las razones dadas en la pregunta. Dicho esto, JGrasp parece una excelente herramienta para mejorar la comprensión del código.
pgfearo
Se supone que JGrasp es un editor de código en mi escuela, lo usamos en nuestra clase de introducción a la informática, fue el editor de código recomendado. Tiene herramientas para ayudar a compilar y ejecutar su programa, pero no es tan elegante como Eclipse o Netbeans. Pero está un poco alejado de lo que describió como no es realmente un propósito general y solo es muy consciente de la sintaxis de Java.
ash
3

No es una mala idea, pero tener que hacer referencia al margen izquierdo para ver claramente mis bloques puede ser un poco molesto. Eso ni siquiera está pensando en el espacio de la pantalla o en cómo podrían comenzar a verse las cosas si la estructura se vuelve muy profunda.

Dado que la motivación es ayudar a los usuarios a "ver" los caracteres de espacios en blanco que están utilizando para la sangría, puede mostrarles los caracteres de espacios en blanco.

No estoy hablando de caracteres visuales especiales como marcadores de párrafo, solo aspectos destacados. Espacios en amarillo, pestañas en verde (o lo que sea)

Para el problema de margen / anidamiento, puede mover el margen para cada bloque. No hay nada que diga que el margen debe ser una línea recta.

Estoy seguro de que esta no es una idea nueva.

Algo como esto:

muestra xml que muestra el margen izquierdo en movimiento y el espacio en blanco resaltado

Justin Ohms
fuente
Con la vista con sangría, el plan es iluminar espacios en blanco dinámicamente, similar a su idea. Además, recuerde que en una vista plana 30 niveles de anidamiento ocupan el mismo espacio que 1 nivel, sangrado, estaría fuera del borde de su pantalla, esa es una razón por la cual los desarrolladores tienen la opción de vistas.
pgfearo 01 de
1
Sí, por eso dije que no era una idea nueva. Sin embargo, si el nivel de sangría es logarítmico o dinámico según el nivel en el que estoy editando actualmente, no tendría el problema del que está hablando. Incluso si simplemente se fijara en 1 espacio, no estaría fuera de la pantalla. Ni siquiera estarías a la mitad de una pantalla de 80 caracteres. Sí, con algunas de estas ideas, 30 niveles ocupan el mismo espacio que 1 nivel, pero cuando miras algunos de estos, no ahorras espacio solo con la sangría, simplemente sangran todo y agregan algunos gráficos elegantes.
Justin Ohms
Ohmios Ahora hay una sección en pantalla de bienes raíces en la pregunta (esto es un wiki de la comunidad y todo), esto incluye una comparación de captura de pantalla. Si pudiera actualizar esta sección con sus propias observaciones, sería genial. Acepte que soy un gran fanático de las vistas con sangría (trabajando en el mundo XML y todo eso), es por eso que he pasado los últimos 6 meses o más perfeccionando la técnica para el formato virtual donde el sistema administra la sangría. Sin embargo, si hay algo que he aprendido, es que a los desarrolladores les gusta elegir, de ahí la vista plana.
pgfearo 01 de
En la primera lectura, extrañé sus ideas sobre los anchos de sangría dinámicos; esta podría ser una característica poderosa. Plantea la posibilidad incluso de tener algún código sangrado mientras que el resto es plano, no estoy seguro de cómo funcionaría esto en la práctica, pero se prueba fácilmente: con mi proyecto, la lógica de sangría aún se invoca incluso para la vista plana, es solo que el multiplicador se establece en 0. Por lo tanto, es solo este multiplicador que debe ajustarse. Buena llamada.
pgfearo
2

¿Por qué no abrir y cerrar paréntesis?

  1. La sangría significa contención: (y) significa exactamente eso para los programadores.
  2. (y) son cada uno un solo carácter: la barra izquierda se mantendrá muy delgada.
  3. Los elementos vacíos se ven fácilmente: use () en la misma línea.
  4. El contenido de un elemento no necesita una pista visual: un espacio en blanco es mucho mejor.
  5. La posición del cursor a la derecha puede coincidir con el bloque contenedor a la izquierda: agregue dinámicamente un color a los caracteres en la columna con (y)
  6. Podría hacerlo más XML-ish usando <y>, que se ven mejor desde la distancia.
Ando
fuente
Algunas ideas útiles: intentaremos incorporarlas, especialmente el bit XML-ish. Además, hay muchas cosas que suceden dinámicamente, y probablemente podría agregar algo más, sin que sea demasiado dominante.
pgfearo
2

Vim ya puede hacer algo similar, aunque no tan bonito.

Hay varias formas de hacer "plegado de código" en Vim. Uno de ellos se basa en una sintaxis de reglas de plegado. Cuando se hace esto, el código se puede plegar usando una estructura de esquema anidada, y la "FoldColumn" se puede usar para dar una representación gráfica (en realidad "basada en caracteres" con caracteres "|" y "-") del "nivel de plegado" .

La columna de plegado puede proporcionar la representación de anidación independientemente del método de plegado, pero el método basado en sintaxis es el que probablemente sea apropiado para lo que desea. No estoy seguro de si existen reglas de plegado basadas en sintaxis prefabricadas para xml en alguna parte, supongo que puede haberlas.

Herbert Sitz
fuente
El editor que estoy diseñando se integrará en un sistema mucho más grande con una GUI donde Vim, o cualquier herramienta de terceros no se está considerando, por razones técnicas y de licencia. Sin embargo, estoy interesado en cómo Vim aborda esto, así que investigará, espero que tengan capturas de pantalla en la documentación. Sí, los gráficos basados ​​en personajes pueden funcionar hasta cierto punto: me he burlado de uno para la investigación. El plegado del código se puede hacer desde el margen izquierdo, pero también se proporciona una vista de árbol de esquema sincronizado.
pgfearo
@pgfearo: Puede mirar el protocolo NetBeans de Vim. Está destinado a usarse para incrustar Vim dentro de un IDE, sin ningún problema de licencia.
greyfade
@greyfade: me temo que hay problemas de licencia, al menos con mi proyecto actual, porque es de código cerrado y necesitaría la facilidad (incluso si no lo usé) para modificar la fuente de Vim sin preocupaciones de GPL. Aparte de eso, el protocolo parece interesante.
pgfearo
1

Creo que estás en el camino correcto con las opciones B y C: incluye ancho y colores de mapa de calor. Me gusta la opción B más que C en este momento, porque es menos intrusiva (ya sea amplia y diluida, o estrecha e intensa, en lugar del bloque muy pesado en el medio de C) Una desventaja es que con esa opción tienes que reconstruya todo el gráfico si inserta un nivel en alguna parte. Creo que podría hacer los bloques mucho más pequeños, 1 o 2 px probablemente sería suficiente. No tiene que ser mucho, solo tiene que ser distinguible. Especialmente cuando se espera que las personas usen el editor muchas veces, es más fácil trabajar con los efectos discretos y más sutiles porque no distraen tanto.

Sin embargo, una cosa que es importante cuando se usa un tipo de editor es resaltar el alcance actual: al seleccionar una línea en el editor, debe ver exactamente qué elementos contiene y dónde se detiene. Incluso podría resaltar el árbol (de qué elementos es hijo). Creo que es un tema separado que debe abordarse y reflexionarse, y tendrá más influencia sobre cómo los usuarios calificarán su experiencia con el editor.

Inca
fuente
Ahora he enviado una respuesta que creo que se cruzó con la suya, pero casualmente coincide con su idea de resaltar el alcance actual (con un borde brillante). Estoy de acuerdo en que los bloques deben ser menos molestos, los efectos se exageran aquí para ayudar con mi dibujo y también para que se muestren bien en una captura de pantalla reducida.
pgfearo
1

Una cosa que no he visto mencionado es lo que puede hacer con el tono además del efecto de saturación en el que parece haberse asentado. Mi sugerencia es cambiar el color del nido en el que se encuentra el puntero. Esto facilitaría al usuario distinguir qué líneas son parte del nido, en comparación con los hermanos a lo largo del camino.

Cuando implemente material basado en tonos, tenga en cuenta el daltonismo y seleccione colores que sean universalmente distinguibles u ofrezca algunas opciones para que las personas elijan.

Phil Miller
fuente
Creo que esto resalta que todavía hay mucho por hacer para agregar detalles a la implementación de este patrón. Sí, me siento más cómodo usando tonos para evitar problemas de conciencia del color, pero si hay opciones disponibles, estoy de acuerdo en que ayudará a agregar una dimensión adicional. Como esta pregunta ahora es un wiki de la comunidad, intentaré enviar una estructura alámbrica para ver si otros desean contribuir con imágenes que sean variaciones del tema; las preferencias probablemente variarán según las diferentes clases de uso, sintaxis del lenguaje y contexto dinámico.
pgfearo
0

Una opción, que podría usarse junto con las otras sugerencias hasta el momento, sería utilizar una información sobre herramientas en el margen izquierdo que muestra la ruta a la línea utilizando la notación XPath. Las herramientas de "inspeccionar elementos" del navegador (por ejemplo, Firebug, la que está integrada en Chrome) a menudo hacen algo similar pero en una barra de estado.

Peter Taylor
fuente
Me estaba concentrando en este control, pero una 'Barra de ubicación XPath' con el navegador 'breadcrumb' funciona y está incorporada en el editor, al igual que una vista de árbol de elementos sincronizados.
pgfearo
0

Posiblemente podría tener una vista contraída para el mapa de calor (de la publicación original) con solo una columna de colores y los números de profundidad. Esto les permitiría saber qué tan profundos son y les daría más espacio en pantalla para el xml. Parece una victoria ganar para mí.

Me preocupa si habrá suficientes diferencias de color para anidar las cosas profundamente.

rev. Mattimus
fuente
El soporte para altos niveles de anidamiento es una prioridad. Pero, solo hay tanto que el ojo necesita ver (y puede asimilar) en cualquier momento, por lo que más allá de cierto nivel, estoy considerando mezclar colores, para dar una impresión de profundidad y solo resaltar los niveles clave. Así que comprobaré tu idea para cuando los niveles de anidación son altos.
pgfearo