Cómo crear una diferencia útil de una iteración de proyecto de escritura de rebajas

Escribí una obra de teatro que presenté este verano y he hecho reescrituras significativas para una próxima segunda presentación. Para ayudarme a volver a aprender mis líneas, creo que sería útil ver cuáles se cambiaron/eliminaron/añadieron todas juntas, en lugar de simplemente leer la nueva versión y esperar que se mantenga.

Escribí mi obra en Markdown (usando iaWriter). y tengo ambas versiones guardadas por separado.

También soy programador y estoy acostumbrado al control de versiones, así que intenté crear un repositorio git donde comencé con un archivo txt que tenía la versión original, y luego pegué la nueva versión encima y cometí los cambios. Esperaba que la diferencia fuera más útil de lo que fue... ¡pero al menos es algo! (Esperaba, por ejemplo, ver un 95 % de líneas idénticas identificadas como la misma línea, pero a menudo no lo eran... porque aparecen varias líneas entre ellas.

Entonces, me pregunto si puede haber una mejor manera de obtener una diferencia útil de 2 archivos de texto sin formato que se mejoraría en términos de identificar más diferencias basadas en palabras en lugar de líneas.

Y si es así (incluso solo para git diffs) si habría una manera de generar esto de una manera que pueda guardarse en formatos de lectura útiles.

Respuestas (2)

Supongo que ya ha probado las banderas --minimal y --ignore-all-space.

Si los saltos de línea debido a palabras añadidas/eliminadas/modificadas están causando el problema con diff (haciendo que parezca que aparecieron cambios que son solo cambios de formato), sugeriría (ya que puede programar esto usted mismo fácilmente) preprocesar ambos archivos, para producir dos nuevos archivos para la comparación.

La idea es tener UNA línea para que diff procese por elemento : Entonces, si fuera solo una historia, diría que combine todas las líneas en cada párrafo como una sola línea, incluso si tiene miles de caracteres, entonces lo que hace diff es comparar cada párrafo para los cambios, no cada línea .

(Para diff, use el indicador --width=nnn para asegurarse de que se emitan todos los caracteres, establecería --width=16384 más o menos).

Tendrá que reconocer, en función de su formato, dónde comienza y termina cada tipo de elemento . No estoy familiarizado con el formato de las obras de teatro, pero en un guión me gustaría comparar las líneas de slug (escenario), los párrafos de exposición, las etiquetas de los diálogos de los personajes y el diálogo de los personajes en sí.

En un guión, creo que estas identificaciones probablemente podrían hacerse contando los espacios iniciales y/o verificando TODO EN MAYÚSCULAS o palabras clave (INT., EXT., etc.), y usando líneas en blanco como señales (si está a doble espacio, luego ignore una sola línea en blanco, pero dos seguidas señalan el final de un elemento). Escribiría una máquina de estado simple (cada estado es el tipo de elemento que estoy creando para la salida, o que estoy buscando texto para el inicio de otro elemento, etc.), pero la lógica es bastante simple sin importar cómo lo codifiques.

Entonces, cinco líneas de diálogo se convierten en una sola línea en el archivo de salida. Entonces, en la salida, una nueva escena podría tener saltos de línea como este:

EXT. Parque Parque, NOCHE

[cinco líneas de exposición combinadas aquí, configurando a DIANE y EDGAR trotando, a punto de ser asaltados]

DIANE

[diez líneas de diálogo combinadas en esta línea, una historia sobre el trabajo]

EDGAR

[dos o tres líneas combinadas aquí]

Eso debería ignorar los cambios de reflujo que hizo el editor e identificar solo dónde ocurrieron los cambios de palabras.

Sin embargo, se vuelve más difícil identificar en qué parte de los archivos originales apareció el texto. Para resolver eso, agregaría más al archivo de salida y usaría otra marca de diferencia: --ignore-matching-lines=RE

RE aquí es una expresión regular. Entonces, la idea es, antes (o después, según su elección) de generar cualquier elemento construido, informar en una línea separada los números de línea originales del archivo original y el archivo modificado, con un marcador que no se encontrará en el texto: Me gusta el hashtag '#', o un par de ellos. Como sabe que comenzará en el primer carácter de la línea de 'notación', establezca su expresión regular en '^#' y esas líneas se ignorarán. Así que la línea en la salida podría verse como

# 1023 1027

es decir, la línea 1023 en el primer archivo, la línea 1027 en el segundo. Si lo prefieres, hazlo más complejo contando páginas también. No lo he probado, pero creo que estos deberían aparecer como parte del contexto al informar una línea modificada.

También puede decirle a diff que solo genere cambios, --suppress-common-lines .

Puede que eso no sea exactamente lo que quieres; pero una vez que identifique los cambios, es posible que pueda resaltarlos de alguna manera en el nuevo guión (color, negrita o lo que sea) como un guión de práctica.

Dado que está identificando elementos y, en particular, desea aislar el diálogo modificado, sería fácil en su código hacer todo esto pero suprimir la salida (en los dos archivos para comparar) de cualquier cosa MENOS el diálogo de su personaje. El hashtag para los números de línea del archivo original seguiría siendo el mismo.

Si hace que el nombre del personaje sea una variable o un argumento para el programa de preprocesamiento que escribe, puede hacer guiones de práctica para cada personaje.

Diviértete codificando.

No estoy seguro de usar la confirmación de Git. No lo uso mucho.

¿Qué tal tokenizar tu texto en Python? Luego calcula la entropía por oración. Esto mostraría la diferencia entre oraciones. Alternativamente, puede hacer esto para palabras o ngramas. La salida se puede almacenar en una lista y un archivo txt.

# py3 algo for calculating entropy
# import math
from collections import Counter
p, lns = Counter(s), float(len(s))
return -sum( count/lns * math.log(count/lns, 2) for count in p.values())

O tal vez use uno de los algoritmos de búsqueda aproximada para encontrar oraciones que no sean exactas pero que sean una coincidencia aproximada (por ejemplo, un carácter sustituido).

Quizás aún más fácil, pero no tan poderoso, Google Docs tiene un historial de versiones donde puede ver todas las ediciones de cada día que ha editado el archivo. También es posible exportar a Markdown.

Háganos saber su solución.