user-interface - textos - tipos de editor de texto
¿Cómo se implementan generalmente los editores de texto? (4)
Dependiendo de la cantidad de texto que debe estar en el editor a la vez, una cadena para todo el enfoque del búfer probablemente estaría bien. Creo que el Bloc de notas hace esto. ¿Alguna vez se da cuenta de lo lento que resulta insertar texto en un archivo grande?
Tener una cadena por línea en una tabla hash parece ser un buen compromiso. Haría navegar a una línea particular y eliminar / pegar eficientemente sin mucha complejidad.
Si desea implementar una función de deshacer, querrá una representación que le permita volver a las versiones anteriores sin almacenar 30 copias del archivo completo para 30 cambios, aunque de nuevo eso probablemente estaría bien si el archivo fuera lo suficientemente pequeño.
Esta pregunta probablemente me hará parecer bastante despistado. Eso es porque yo soy.
Solo estoy pensando, si estuviera hipotéticamente interesado en diseñar mi propio editor de texto, control de GUI, widget, o como quieras llamarlo (que no soy), ¿cómo lo haría?
La tentación para un novato como yo sería almacenar el contenido del editor de texto en forma de cadena, lo que parece bastante costoso (no es que esté demasiado familiarizado con la forma en que las implementaciones de cadenas difieren entre un idioma / plataforma y el siguiente ; pero sé que en .NET, por ejemplo, son inmutables, por lo que la manipulación frecuente, como lo que necesitaría apoyar en un editor de texto, sería un desperdicio magnífico, construir una instancia de cadena tras otra en una sucesión muy rápida).
Es de suponer que en su lugar se utiliza una estructura de datos mutable que contiene texto; pero descubrir cómo se vería esta estructura me parece un desafío. El acceso aleatorio sería bueno (me gustaría pensar , de todos modos, después de todo, ¿no quieres que el usuario pueda saltar a cualquier parte del texto?), Pero luego me pregunto sobre el costo de, por ejemplo, navegar a algún lado en medio de un gran documento y comenzando a escribir de inmediato. Una vez más, el enfoque novato (digamos que almacena el texto como una matriz redimensionable de caracteres) llevaría a un rendimiento muy pobre, estoy pensando, ya que con cada carácter escrito por el usuario habría una gran cantidad de datos para "cambiar" encima.
Entonces, si tuviese que adivinar, supongo que los editores de texto emplean algún tipo de estructura que divide el texto en partes más pequeñas (¿líneas, quizás?), Que individualmente comprenden arreglos de caracteres con acceso aleatorio, y que son ellos mismos aleatoriamente accesibles como trozos discretos. Sin embargo, incluso parece que debe ser una simplificación excesiva bastante monstruosa, si es remotamente cercana para empezar.
Por supuesto, también me doy cuenta de que puede que no haya una manera "estándar" de implementar editores de texto; tal vez varía drásticamente de un editor a otro. Pero pensé, ya que es claramente un problema que ha sido abordado muchas, muchas veces, quizás un enfoque relativamente común ha surgido a lo largo de los años.
De todos modos, me interesa saber si alguien tiene algún conocimiento sobre este tema. Como dije, definitivamente no estoy buscando escribir mi propio editor de texto; Tengo curiosidad.
La forma más simple sería usar algún tipo de clase de buffer de cadena proporcionada por el lenguaje. Incluso una simple serie de objetos de char haría en una pizca.
Anexar, reemplazar y buscar texto son relativamente rápidos. Por supuesto, otras operaciones consumen más tiempo, por supuesto, con la inserción de una secuencia de caracteres al comienzo del buffer siendo una de las acciones más costosas.
Sin embargo, esto puede ser perfectamente aceptable en términos de rendimiento para un caso de uso simple.
Si el costo de las inserciones y eliminaciones es particularmente significativo, me sentiría tentado a optimizar creando una clase contenedora de búfer que mantuviera internamente una lista de objetos de búfer. Cualquier acción (excepto el reemplazo simple) que no ocurrió en la cola de un búfer existente daría lugar a que el búfer en cuestión se divida en el punto relevante, por lo que el búfer podría modificarse en su cola. Sin embargo, el envoltorio externo mantendría la misma interfaz que un simple buffer, por lo que no tuve que reescribir, por ejemplo, mi acción de búsqueda.
Por supuesto, este enfoque simple terminaría rápidamente con un búfer extremadamente fragmentado, y consideraría tener algún tipo de regla para unir los búferes cuando sea apropiado, o para diferir la división de un búfer en el caso de, por ejemplo, una inserción de un solo carácter. Tal vez la regla sería que solo tendría como máximo 2 búferes internos, y los combinaría antes de crear uno nuevo, o cuando algo me pidiera una vista de todo el búfer a la vez. No es seguro.
El punto es que comenzaría de forma simple, pero accedería al buffer mutable a través de una interfaz cuidadosamente elegida, y jugaría con la implementación interna si los perfiles me mostraran que lo necesitaba.
Sin embargo, ¡ definitivamente no comenzaría con objetos String inmutables!
Una técnica que es común (especialmente en editores más antiguos) se llama búfer dividido. Básicamente, "divide" el texto en todo antes del cursor y todo después del cursor. Todo lo anterior va al comienzo del búfer. Todo lo que sigue va al final del buffer.
Cuando el usuario ingresa texto, ingresa en el espacio vacío sin mover ningún dato. Cuando el usuario mueve el cursor, mueve la cantidad apropiada de texto de un lado del "corte" al otro. Por lo general, se mueve mucho en un área determinada, por lo que generalmente solo se están moviendo pequeñas cantidades de texto a la vez. La mayor excepción es si tiene un tipo de capacidad de "ir a la línea xxx".
Charles Crowley ha escrito una discusión mucho más completa sobre el tema . También puede consultar The Craft of Text Editing , que cubre los búferes divididos (y otras posibilidades) con mucha mayor profundidad.
Hace un tiempo, escribí mi propio editor de texto en Tcl (en realidad, robé el código de algún lugar y lo extendí más allá del reconocimiento, ah las maravillas del código abierto).
Como mencionaste, realizar operaciones de cadena en cadenas muy, muy grandes puede ser costoso. Por lo tanto, el editor divide el texto en cadenas más pequeñas en cada nueva línea ("/ n" o "/ r" o "/ r / n"). Así que todo lo que me queda es editar pequeñas cadenas a nivel de línea y hacer operaciones de lista cuando me muevo entre líneas.
La otra ventaja de esto es que es un concepto simple y natural para trabajar. Mi mente ya considera que cada línea de texto debe ser separada, reforzada por años de programación donde las nuevas líneas son estilísticas o sintácticamente significativas.
También ayuda que el caso de uso para mi editor de texto sea como editor de programadores. Por ejemplo, implementé la sintaxis hilighting pero no el ajuste de palabras / líneas. Entonces, en mi caso, hay un mapa 1: 1 entre las nuevas líneas en el texto y las líneas dibujadas en la pantalla.
En caso de que quiera echar un vistazo, aquí está el código fuente de mi editor: http://wiki.tcl.tk/16056
No es un juguete por cierto. Lo uso a diario como mi editor de texto de la consola estándar a menos que el archivo sea demasiado grande para caber en la RAM (En serio, ¿qué archivo de texto es? Incluso novelas, que normalmente son de 4 a 5 MB, caben en la RAM. Solo he visto archivos de registro crecer a cientos de MB).