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

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).

[Editar]

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

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

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:

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:

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:

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:

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.

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

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:

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':

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

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

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:

Se vería así:

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:

¿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:

Alineado a la izquierda:

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.

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

Mi idea:

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

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.

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.

jGRASP hace esto usando un marcador visual en el margen:

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.

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:

¿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.

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.

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.

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.

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.

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.