Generating animation data

Abstract

A computer-implemented method comprises comparing first data (132), representative of a first state of a text-based work, with second data (134), representative of a second state of the text-based work, to determine a set of differences (310) between the first state and the second state of the text-based work. The set of differences is processed5 to generate a set of edit operations (124; 324). The set of edit operations (124; 324) is processed to generate animation data for depicting a sequence of two or more successive simulated user-interface edits to a text-based work that change the text- based work from the first state to the second state.

Description

[0001]164037 / 02 Generating animation data BACKGROUND OF THE INVENTION This invention relates to systems and methods for generating animation data for depicting a sequence of simulated user-interface edits to a text-based work. Showing the creation of a piece of written work to students is a useful approach for explaining a development process. For example, when teaching computer programming, a portion of computer source code may be built up by a lecturer entering on a keyboard to provide a visual demonstration to a student or a class. A demonstration of editing a text-based work may be presented live or may be recorded—e.g. as a movie file generated from a screen capture of a text editor or integrated development environment (IDE). Recordings can reach a wider audience by being stored for viewing in different locations and at different times. A recording may be accompanied by a soundtrack, spoken by a teacher, that provides an explanation of the edits that are being made. However, such a recording can be difficult to maintain and update, e.g. to correct errors or to adapt the content for different audiences. Embodiments of the present invention seek to provide an improved approach for generating animations of edits to text-based works such as software code. SUMMARY OF THE INVENTION From a first aspect, the invention provides a computer-implemented method for generating animation data for depicting a sequence of simulated user-interface edits to a text-based work, the method comprising: comparing first data, representative of a first state of a text-based work, with second data, representative of a second state of the text-based work, to determine a set of differences between the first state and the second state of the text-based work; processing the set of differences to generate a set of edit operations; and processing the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits to the text-based work that change the text-based work from the first state to the second state. From another aspect, the invention provides software comprising instructions which, when executed on a processing system, cause the processing system to: compare first data, representative of a first state of a text-based work, with second data, representative of a second state of the text-based work, to determine a set of differences between the first state and the second state of the text-based work; process the set of differences to generate a set of edit operations; and process the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits to the text-based work that change the text-based work from the first state to the second state. The software may be carried on a non-transitory medium such as a magnetic drive or solid-state memory, or may be provided over a wired or wireless communication channel. From a further aspect, the invention provides a processing system for generating animation data for depicting a sequence of simulated user-interface edits to a text- based work, the processing system comprising one or more processors and a memory storing software, wherein the software comprises instructions which, when executed by the one or more processors, cause the processing system to: compare first data, representative of a first state of a text-based work, with second data, representative of a second state of the text-based work, to determine a set of differences between the first state and the second state of the text-based work; process the set of differences to generate a set of edit operations; and process the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits to the text-based work that change the text-based work from the first state to the second state. Thus, in accordance with embodiments of the invention, a processing system automatically generates animation data (e.g. a video file) for depicting simulated user- interface edits—i.e. edits that appear to be made in response to user actions through a user-interface actions, such as typing on a keyboard—showing a text-based work changing from a first state to a second state, without a human operator having to be recorded as they provide input to the computer system in real time. This automated generation of the animation data can facilitate much greater control over any resulting animation (e.g. video or other multimedia format), including easier maintenance and customization. A human tutor may create the first and second data, e.g. by capturing evolving states of the text-based work as the tutor edits the work over time, but, using methods disclosed herein, the animation data can be efficiently generated at a later time (and potentially re-generated many times with variations) without the involvement of the tutor. Automated generation of the animation data may also facilitate synchronisation of operations in time with an external source, such as cues from an audio track, as may be done in some embodiments. This relieves the operator of needing to perform edits at an appropriate pace for synchronization purposes, and may eliminate the need for subsequent editing of a live animation to speed up, slow down, truncate or extend what was recorded. Converting the differences between the two states into edit operations that a computer system can use to depict a plurality of keystroke edits can enable a relatively large change between the first and second states to be animated as several smaller changes (e.g. down to the level of individual keystrokes), without having to record a human operator editing the work in real time. This can save time, especially when it is desirable to regenerate the animation data, e.g. after updating the first or second data to correct an error, or with different animation settings. Depicting the changes between the first state and the second state as a sequence of simulated user-interface edits (e.g. showing a cursor moving around a screen, showing text appearing character-by-character as if typed by a human editor, etc.) can advantageously improve the interpretability and teaching value of an animation created using the animation data, compared with simply showing the first and second states to students as static slides. In particular, the animation data may enable a clearer stepwise explanation of how the text-based work evolves between the two states, which may have greater educational value in teaching students how to produce similar text-based works of their own. By animating the changing state of the text- based work at the level of inputs which a human operator could provide to a computer system through a user interface (e.g. keystrokes, selecting text with a cursor, etc.), the resulting animation appears naturalistic—i.e. mimicking the actions and pacing of a live human editing the work in real time. This can increase student engagement as well as providing a better learning experience compared with static slides. The sequence of two or more simulated user-interface edits may comprise any edits that could be applied to the text-based work by a human operator interacting with a computer system (e.g. with the present processing system or any other computer system). For example, simulated user-interface edits may comprise inserting characters into, or deleting text from, a document in a text-editing application, or moving a cursor left, right, up or down. The simulated user-interface edits may include keystrokes edits that could be input by a human operator using a physical or touchscreen keyboard of a computer system. The animation data may depict the simulated user-interface edits (e.g. keystrokes and / or other user-interface actions) being applied to the text-based work within a text- editing application which may, for example, be a text editor, a word processor, or an integrated development environment (IDE). The simulated user-interface edits may include editing operations which could be implemented by selecting a software tool within a text-editing application—for example, a find-and-replace operation, or a refactoring operating for computer source code. The simulated user-interface edits may include edits that could be carried out in response to cursor controls, and may include keystroke edits where two or more keys are depressed simultaneously, for example, when pressing “shift” and “down” for selecting a block of text, or “ctrl” and “c” for copying the block of text, and “ctrl” and “v” for pasting the block of text at a different location in the text-based work. By generating animation data for depicting a sequence of simulated user-interface edits, the processing system can advantageously produce a sequence of changes to the text-based work which mimic the actions of a human editor. The instructions may not necessarily be the most efficient way of transforming the text-based work from the first state to the second state, but they may result in the transformation appearing more naturalistic by mimicking successive user edits as if implemented by a human operator interacting with a computer system. In some embodiments, the data representative of the first state of the text-based work represents the state at a first point in time within the animation data, and the data representative of the second state of the text-based work represents the state at a later point in time within the animation data. Thus, the sequence of successive simulated user-interface edits may evolve the text-based work from an earlier version at a first point in time, to a second version at a later point in time. The first data and second data may be stored in a store, such as a memory of the processing system. They may be stored as respective files. The method may comprise accessing (e.g. receiving) the first and second data. Generating the animation data may further comprise comparing data that is representative of one or more further states of the text-based work. Each respective state of the text-based work will be referred to herein as a respective snapshot, and data representing (e.g. encoding) the state will be referred to as snapshot data. In some embodiments, data representing third and / or fourth and / or fifth states of the work may be processed by the processing system, in addition to the first and second data. Data representing an ordered sequence of two, three or more states may be processed when generating the animation data. Successive pairs of state data, representing pairs of states of the ordered sequence, may be compared to each other to generate, for each pair, a respective set of edit operations. Each set of edit operations may represent a sequence of edits that change the text-based work from an earlier state of the respective pair of states to a later state of the pair. Each set of edit operations may be suitable for generating a respective portion of the animation data for depicting a respective sequence of simulated user-interface edits for changing the work from the earlier state to the later state. The respective sequences of edit operations may be combined to form a single set of edit operations, which may be processed to generate animation data for depicting a sequence of simulated user- interface edits to the text-based work that change the text-based work from the first state to the second state and then the second state to a third state, and optionally to further successive states. In some embodiments, the text-based work comprises source code, i.e. written in one or more computer programming languages. However, the text-based work may comprise any form of text-based work, such as a scientific report, a work of literature (e.g. a novel), a poem, etc. The text-based work may comprise any document with a linear structure, i.e. where a location in the document can be uniquely specified by a single number, such as an offset in characters from the beginning, a character index, etc. In some embodiments, the animation data is suitable for generating an animation of the sequence of simulated user-interface edits to the text-based work. The animation data may comprise one or more video files or other multimedia files for display on a display device such as a computer or a television set. The animation data may encode a plurality of frames, wherein a frame of the animation data comprises a first graphical representation of the first state of the text-based work and a further frame of the animation comprises a graphical representation of the second state of the text-based work. The animation data may encode one or more intermediate frames comprising respective graphical representations of the text-based work after respective subsequences of the sequence of two more successive simulated user-interface edits have been applied to the text-based work as it changes from the first state to the second state. The graphical representations of the text-based work may show at least a portion of the text-based work in a text-editor application. For example, the animation data may be suitable for depicting the sequence of simulated user-interface edits within an integrated development environment (IDE) (e.g. Microsoft Visual Studio Code or PyCharm), or within a word-processing or text-editor application (e.g. Microsoft Word or Microsoft Notepad). Some embodiments may comprise depicting the sequence of two or more successive simulated user-interface edits to the text-based work, e.g. on a display. However other embodiments may output the animation data (e.g. over a network connection) or may store the animation data (e.g. in a memory or file store of the processing system). The animation data may comprise data, suitable for depicting the sequence of simulated user-interface edits, in any suitable format. For example, the animation data may be suitable for and / or used to render the sequence of edits on a web page, or the animation data may be a video file or may suitable for and / or used to generate a video (e.g. in a .mov or .mp4 format). In some embodiments, the data representative of a state of the text-based work is or comprises text data (e.g. in ASCII or Unicode format). The data may be some or all of the text characters (e.g. letters and whitespace) and control characters (e.g. newline) of the text-based work. The text-based work may, in at least one state (e.g. the second state), comprise at least one new line character and / or at least one indented line of text. In some embodiments, the data representative of the first state and the data representative of the second state are provided as input to a lexical tokenizer. The lexical tokenizer may be configured to generate tokenized data that encodes groups of one or more characters of the text-based work, in a respective state, by one or more tokens. First tokenized data may be generated from the first state data, and second tokenized data may be generated from the second state data. Each token may comprise a type and a value. The value of a token may comprise one or more characters. For example, each word in the text-based work may correspond to a different token. The series of characters “patent” may correspond to a token with type “word” and value comprising the string of characters in “patent”. Similarly, a token for a comma may have a type “punctuation” and a value of “,”. Other examples of token types may include a “whitespace” and “newline”. Identifying tokens in the received data may advantageously break up the characters in the text-based work in such a way that is meaningful in the domain of the text-based work. For example, tokenizing may allow groups of characters in the text-based work to be treated differently when inserted or modified from one state to the next, on account of forming part of a word. This can help make the resulting animation data be more naturalistic. A lexical tokenizer may be selected which is specific to the language of the text-based work. This language may be a computer programming language, e.g. Python, or a natural language, e.g. English. In some embodiments, a lexical tokenizer may be selected based on a user input provided to the processing system. In other embodiments the data representative of the first state of the text-based work and the data representative of the second state of the text-based work may be provided as input to a language detection module to determine a language of the text-based work. Comparing the first and second data may comprise using a differencing algorithm, such as a Ratcliff / Obershelp pattern recognition algorithm. It may comprise comparing the first tokenized data with the second tokenized data. It may comprise comparing each respective line of the first data with a respective line of the second data—e.g. using a line-based differencing algorithm. Each difference in the set of differences may comprise a respective operation type (e.g. equal, insert, replace, or delete). More narrowly, each difference in the set of differences may comprise: a first character string from the first state of the text-based work (e.g. encoded as a list of tokens); a location of the first character string (e.g. a character index range); a second character string from the second state of the text-based work (e.g. encoded as a list of tokens); a location of the second character string (e.g. a character index range); and an operation type associated with a type of difference between the first character string and the second character string (e.g. equal, insert, replace, or delete). Each edit operation in the set of edit operations may comprise a respective operation type. More narrowly, each edit operation in the set of edit operations may comprise: a first character string from the first state of the text-based work (e.g. encoded as a list of tokens); a location of the first character string (e.g. a character index range); a second character string from the second state of the text-based work (e.g. encoded as a list of tokens); a location of the second character string (e.g. a character index range); and an operation type associated with a type of difference between the first character string and the second character string. The set of differences and / or the set of edit operations may each be arranged sequentially, e.g. with each respective location in the first state being in a progressively later position within the text-based work. In some embodiments, the set of edit operations may include at least one operation of a type that is not present in the set of differences. Processing the set of differences to generate the set of edit operations may comprise introducing one or more types of edit operation that are not present in the set of differences. This can enable the edit operations to represent more naturalistic edits, or to be more compact, or both. In some embodiments, every operation type in the set of differences affects a respective single range of contiguous characters. Every operation type in the set of differences may be one of: equal, insert, replace and delete. These differences may be generated by applying a known diffing algorithm to the tokenized data. The set of edit operations, however, may include one or more further types of operation—e.g. indentation. The equal operation type may correspond there being no difference between two respective subsets of tokens which are being compared between the first state and the second state. The insert operation type may correspond to an addition of one or more tokens to the text-based work in the second state, which were not in the text-based work in the first state. The replace operation type may correspond to deleting a subset of tokens from the first state of the text-based work, and inserting a new subset of one or more tokens in its place, which has been introduced in the second state of the text- based work. The delete operation type may correspond to a subset of one or more tokens which was present in the first state of the text-based work being deleted in the second-state. If the animation data were to be derived directly from the set of differences, without further processing to generate a new set of edit operations, the sequence of edits which may be rendered in a resulting animation would be limited to the basic operations of insert, delete, replace and equal, as described above. However, a human editor would not typically edit a text-based work using this limited range of operation types. Processing the set of differences to generate the set of edit operations can allow the set of differences to be simplified, grouped, and / or modified to better accord with how a human editor might change the text-based work from the first state to the second state. In some embodiments, processing the set of differences to generate the set of edit operations comprises identifying a predetermined pattern of differences in the set of differences. It may comprise including a corresponding predetermined subset of edit operations within the set of edit operations in response to identifying the predetermined pattern—e.g. according to a mapping between predetermined difference patterns and corresponding sequences of edit operations. Sequences of difference types, such as equal, insert, replace and delete, may be grouped, simplified, re-ordered, and / or transformed to generate the set of edit operations. In some embodiments, processing the set of differences to generate the set of edit operations may comprise identifying a subset of differences in the set of differences with the same operation type, and grouping the subset of differences into one edit operation in the set of edit operations. Grouping and simplifying subsets of differences may advantageously reduce the volume of animation data generated, and thus may improve the speed of other components in the system which use the animation data to create an animation. Processing the set of differences to generate the set of edit operations may comprise identifying repeated inserted characters in the set of differences (e.g. a run of two or more successive character insertions) and, in response, including a single corresponding edit operation in the set of edit operations. This may, for example, allow four successive single-space inserts, detecting by a differencing algorithm, to be simulated in the animation by the more naturalistic user-interface action of a single “tab” keystroke. In particular, in some embodiments, generating the set of edit operations may comprise including, in the set of edit operations, an edit operation for indenting a line of text. The set of edit operations may include an edit operation type of indentation. The edit operation for indenting a line of text may be generated by: identifying one or more successive differences in the set of differences which together comprise inserting a predetermined number (e.g. four) successive whitespace text characters; and, in response, generating an edit operation comprising an indentation operation type. The edit operation may further comprise a list of characters for insertion comprising the predetermined number of whitespace characters. The use of this indentation operation type can advantageously allow the animation data to be generated from the set of edit operations in a way that most naturally simulates how an indentation would be implemented by a human user, for any desired context. For example, the animation data may be generated so as to show a cursor and text moving within an IDE as it would do if a user pressed the tab key once, rather than by simulating multiple successive strokes of the space-bar. A set of one or more algorithms may be applied to the set of differences to generate the set of edit operations. Each algorithm may be arranged to identify a different respective pattern of one or more differences in the set of differences, and to include a respective edit operation or sequence of edit operations in the generated set of edit operations. Each algorithm may implement a different insight into a more naturalistic approach to simulating one or more user edit actions corresponding to the pattern of differences. For example, repeating alternating differences which describe the insertion of four whitespace characters, followed by a line of characters which remains the same from the first state of the text-based work to the second-state of the text- based work, might be interpreted as indenting a block of text. In some embodiments, generating the set of edit operations comprises including, in the set of edit operations, an edit operation for indenting a block of text comprising plurality of lines of characters. The set of edit operations may include an edit operation type of block-indent. The edit operation for indenting a block may be generated by: identifying a sequence of successive first, second, third and fourth differences, wherein the first difference comprises inserting or modifying a first set of whitespace characters; wherein the second difference comprises a second set of successive characters that remain unmodified between the first state and the second state of the text-based work; wherein the third difference has the same operation type as the first difference and comprises inserting or modifying a second set of whitespace characters that is the same length as the first set of whitespace characters (e.g. both having four whitespace characters); and wherein the fourth difference comprises a fourth set of successive characters that remain unmodified between the first state and the second state of the text-based work; and in response, including an edit operation comprising a block-indent operation type. The edit operation may further comprise a list of characters for insertion comprising the first, second, third and fourth sets of characters. Converting a sequence of interleaved insert and equal difference operation types into a block-indent as described above may advantageously reduce the volume of data used to describe the overall change. Furthermore, it may advantageously result in an edit operation which relates more directly to an edit that would be implemented by a human editor, and from which more naturalistic animation data can thus be generated. For example, a block-indent operation would typically be carried out by selecting a block of text, then indenting the whole block, rather than individually indenting consecutive lines of text. Generating the set of edit operations may comprise re-arranging at least subset of the set of differences into an order which corresponds to a sequence of edits which would be more readily carried out by a human editor. For example, when inserting a new line of text into an existing block of text, a human operator would typically create a space for the new line by pressing the enter key, then subsequently typing in the new characters of the text. However, if implementing a sequence of edits directly derived from a set of differences generated by a typical difference operation, the new characters of text would be inserted first, at the beginning of an existing line of characters, before pressing the enter button to implement the newline character at the end of the line. Following the order of the differences directly in a series of edits would thus appear unnatural. In some embodiments, generating the set of edit operations comprises including, in the set of edit operations, a sequence of edit operations for accommodating one or more new lines of text. The edit operation for accommodating one or more new lines of text may be generated by: identifying one or more successive differences in the set of differences which together comprise inserting a first set of successive text characters, wherein the last text character in the first set comprises a line-terminating character; and in response, including a first edit operation that comprises inserting a line- terminating character, and including a second edit operation, following the first edit operation, that comprises inserting a second set of characters, wherein said second set comprises all but the last text character of the first set of successive text characters. Thus, animation data generated from the set of edit operations described above for inserting a new line of text may be used to render an animation which depicts a cursor moving as it would do if a user pressed the enter key first, then typed the new characters of text. In some embodiments, processing the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits comprises converting one or more, or all, of the edit operations in the set of edit operations to one or more editor control instructions. Editor control instructions may comprise instructions such as indenting a block of text, deleting a line of text, cutting a block of text, pasting a block of text, and inserting text and deleting text, for example. The editor control instructions may be used to operate driver software which interfaces with a text-editing application. Each editor control instruction may be implemented in the text-editing application by calling one or more corresponding methods in the driver software. For example, an edit operation which comprises deleting a section of text may be processed to generate a set of one or more editor control instructions which instruct the text-editing application driver to navigate a cursor to the start of the section of text to be removed, then navigate to the end of the section to be deleted while extending the current selection, and then deleting the selected text. Thus, one operation in the set of edit operations may result in multiple calls to the driver software. Methods embodying the invention may comprise controlling one or more software components such as a text-editing application (e.g. an IDE). Such a software component may be provided by third party, and may be distinct from software implementing methods embodying the invention. Software embodying the invention may, for example, comprise a driver or extension module component suitable for controlling a text-editing application, or, more generally, for interfacing with an external software component. It may comprise instructions for making calls to an external software component over an application programming interface (API). In particular, in some embodiments, the instructions for processing the set of edit operations to generate animation data may comprise instructions for controlling an external software and / or hardware component, such as a text-editing application. It will be appreciated that such external software and / or hardware need not necessarily form part of software or processing systems embodying the present invention, although it may do so in some embodiments. Similarly, steps performed by external software and / or hardware are not necessarily steps of methods embodying the present invention. The processor may be further configured to receive hints which control how the set of edit operations should be implemented as a sequence of simulated user-interface edits. For example, deleting a set of characters within a line of text may be implemented by deleting each character individually, whereas deleting one or more lines of text might be implemented by using line deletion operations. Deleting a large number of lines might be implemented by using the select-and-delete set of edit operations described above. Thus it will be seen that, in accordance with embodiments of the invention, a set of differences between two states of a text-based work may be converted into a new set of edit operations which are more closely associated with typical human editing operations. The sequence of simulated user-interface edit operations which may be depicted in a rendered animation using the animation data thus more effectively mimics an edit sequence which could be carried out by a human operator. This makes an animation generated using the animation data interpretable in a meaningful way for those viewing it, and consequently, makes it easier to follow, and easier to learn from in a tutorial context. Content for presenting a simulated live editing of a text-based work can thus can be generated efficiently and accurately through automation, while retaining interpretability. Features of any aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment described herein. Where reference is made to different embodiments or sets of embodiments, it should be understood that these are not necessarily distinct but may overlap. BRIEF DESCRIPTION OF THE DRAWINGS Certain preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a high-level schematic diagram of a system for generating an animation implemented in accordance with embodiments of the present invention; Figure 2 is a schematic diagram showing the editing module of the system in Figure 1 in more detail; and Figure 3 is a schematic diagram showing the compiler of the editing module in Figure 2 in more detail. DETAILED DESCRIPTION Figure 1 is a high-level schematic diagram of a processing system 100 for generating an animation depicting the evolution (i.e. development over time) of a piece of source code in accordance with embodiments of the present invention. Although the system 100 can be adapted and / or used to depict a sequence of edits to any of various different types of text-based works, such as prose, poetry, technical documentation, etc., the specific example described herein uses the system 100 to depict the evolution of a work comprising computer source code. The processing system 100 may comprise one or more workstations or servers, each having one or more processors as well as memory and storage for input files and output data. It may comprise user interface components such as a keyboard, display screen, etc. The system 100 implements a rendering module 110 and an editing module 120 which are provided by software executing on the system 100. Both the rendering module 110 and the editing module 120 can access input data from a snapshots file store 130. The editing module 120 can also receive input data from a hints file store 140. The editing module 120 controls an integrated development environment (IDE) 150. The IDE 150 may be a third-party software component, such as PyCharm, that executes on the system 100 alongside the rendering module and editing module. The IDE 150 is arranged to edit the source code and to generate visual output of the editing process as a graphical user interface (GUI) suitable for displaying on a display screen. The system 100 may include a display screen for showing output of the IDE 150 to a human operator during the process of generating animation data, but this is not essential. The rendering module 110 digitally captures the visual editing of the source code as generated in the IDE 150 (e.g. using a real- time screen capture process) to produce an animation file which is written to an animation file store 160. The snapshots file store 130 stores two or more files arranged in chronological order (e.g. with the order indicated by alphanumerically arranged file names), each file containing a string of text characters (e.g. ASCII or Unicode characters, which may include control characters such as carriage return and line feed characters) and being a different respective state of the source code work. These states are also referred to herein as snapshots. Depending on the length and complexity of the development of the text-based work, and the intention of the tutor, there may be ten, twenty, a hundred, or more than a hundred snapshots relating to the same source-code work. Each snapshot file defines a respective state of the source code at a particular instant in its development. When stepped through in chronological order, the sequence of snapshots show how the source code should evolve over time. This evolution may include deletions and edits to the source code, as well as the addition of new code. The snapshots may have been created by a human operator (e.g. a tutor) by saving instances of a source code work at distinct points in time, although they could potentially have been generated out of order. Significantly, one or more of the snapshots may have been edited after the snapshots were first created, e.g. to fix an error, or to modify the example. This ability to update snapshots and then easily regenerate an updated animation is an important benefit of the present system 100 over a traditional approach of generating a video using live screen capture of the source code being edited from start to finish in real-time. The editing module 120 retrieves and processes the snapshots to generate a sequence of edit instructions for editing the source code work so that it is developed in accordance with the sequence of snapshots. Whilst the snapshots in the snapshots file store 130 may provide a number of intermediate states of the source code as it evolves, the sequence of edit instructions generated by the editing module 120 breaks down the larger changes between each pair of successive snapshots into smaller edits. These lower-level edits mimic what a human editor would need to carry out in the IDE 150 to develop the code from one snapshot to the next (e.g. through typing on a physical or touchscreen keyboard). The editing module 120 uses these edit instructions to drive the IDE 150, implementing the more detailed series of simulated user-interface edits to take the source code from a first snapshot in the snapshots file store 130 to a final snapshot in the snapshots file store 130. The rendering module 110 captures this evolution of the source code as it is displayed in the graphical user interface (GUI) generated by the IDE 150 to produce animation data which is saved in an animation file store 160. This capturing can be implemented by a software-based screen recording of a window on a computer system which displays the IDE 150, for example. The rendering module 110 can receive other data instructing how the final animation should be rendered and generated—for example, a colour theme and / or a playback speed and / or an audio sound track to accompany the screen capture and / or what file format to output (e.g. a MPEG movie file, or a DHTML file for viewing as a JavaScript-based animation in a web browser). These instructions may be provided as input to the rendering module 110 (e.g. from the snapshots file store 130 or elsewhere). The hints file store 140 optionally stores one or more files which provide data to the editing module 120 describing how the source code work should transition between the successive snapshots in the snapshots file store 130. Sometimes, the difference between two successive snapshots of the source code does not unambiguously describe the changes which have been made. For example, if a line of code is removed, it is not certain whether the line should be cut (e.g. placed in a clipboard memory) or deleted. In such cases, to avoid the editing module 120 have to make an arbitrary choice, it may be helpful to provide additional information to describe what tool, action, or facility should be used to perform the edit. This additional information can be provided by a hints file in the hints file store 140. For each pair of snapshot files showing successive states of the source code, one or more hints can optionally be provided to further control the edits which are implemented. Figure 2 is a schematic diagram showing the editing module 120 in more detail. As previously described, the editing module 120 can receive input data from the snapshots file store 130. Figure 2 shows four exemplary snapshot files 132, 134, 136 and 138 in the snapshots file store 130, which together depict a sequence of successive states of the source code. In practice, there may be more or fewer snapshots than this. Each of the snapshot files 132, 134, 136 and 138 is provided as input to a compiler 122, which can also receive an input data from a compilation hints file 142 in the hints file store 140. The compiler 122 outputs an edit script 124. This edit script 124 can be passed directly to the interpreter 126 as shown in Figure 2, but may alternatively be stored persistently and passed to the interpreter 126 at a later point in time. The interpreter 126 in turn controls an IDE driver that comprises two portions: an IDE-driver server 152 and an IDE-driver client 128. The server portion 152 of the IDE driver may be implemented as an extension module for the IDE 150. The IDE driver client 128 executes within the editing module 120 and communicates with the server 152 through an application programming interface (API) The IDE driver 128, 152 is specific to the particular target IDE 150. Whilst an IDE 150 is used in the exemplary embodiment of the invention described in detail herein, for implementations which depict a sequence of edits to a different type of text-based work, any document- or text-editor may be used. For the example described herein, a desired IDE driver can be selected and used to generate animations for a desired IDE. This can enable the same snapshots to be used to generate multiple different animations with different IDEs, or the same IDE but configured to show different user- interface languages (e.g. English or Chinese). Resulting animations in different themes (e.g. light mode, dark mode etc), at different screen resolutions (say 1280x720 or 1920x1080) or even on different operating systems (e.g. Windows, macOS or Linux) can also be generated from the same snapshots. This flexibility can provide much greater efficiency than if a human tutor had to be filmed delivering the same tutorial live, multiple times over, using a different IDE each time. Data from the sequence of successive snapshot files 132, 134, 136 and 138, depicting the evolution of the source code, is processed by the compiler 122 to output the edit script 124. The edit script 124 contains a set of edit operations for taking the source code from the state shown in the first snapshot 132, through the second and third snapshots 134, 136, to the state in the last snapshot 138. The compiler 122 determines the differences between each pair of successive snapshots. It first compares an empty zeroth snapshot with the first snapshot 132, then compares the first snapshot 132 with the second snapshot 134, and so on. This difference-determining (i.e. diffing) process is described in more detail below, with reference to Figure 3. It is performed in such a way that the resulting edit operations provide a convincing simulation of the way in which a human developer might edit the work by interacting with the IDE to evolve it through the sequence of snapshots. This might correspond closely to how an original human creator of the snapshots 132-138 developed the work over time, although this is not necessarily the case (e.g. if the snapshots were produced out of order, or were revised at a later time). The compiler 122 can also receive data from the compilation hints file 142 alongside the snapshots 132, 134, 136 and 138. The compilation hints file 142 contains an array of hints. Each hint comprises the file path of a first snapshot (e.g. snapshot 132) and the file path of a second snapshot (e.g. snapshot 134 or 136), thus specifying an inclusive range of snapshots to which the respective hint applies. Each hint is named by a key in a hints mapping, and has a value which is an object comprising named arguments which parameterize the hint. For example, a hint may have a name which maps to a type of edit operation, e.g. insert, and arguments which parametrize the hint, e.g. {"by": "paste"}. This exemplary hint would indicate to the editing module 120 that it should drive the IDE 150 to insert characters by pasting from a clipboard, rather than by inserting individual characters by simulating newly-typed keystrokes. The edit script 124 produced by the compiler 122 is not necessarily the only possible edit script 124 which could be produced. In fact, there are many possible edit scripts which could be produced for a given sequence of snapshots. However, the compiler 122 described in the example herein is deterministic; a particular version of the compiler will always produce the same edit script given the same sequence of snapshots and hints. The edit script 124 is then passed to the interpreter 126, which processes the edit operations contained in the edit script 124 to drive the IDE 150 to evolve the source code, within the IDE 150 editing environment, through the sequence of states shown in the snapshots 132, 134, 136 and 138. The interpreter 126 is responsible for transforming the abstract set of edit operations in the edit script 124 into concrete actions in the context of the particular IDE 150 (or other text-editing application). The interpreter 126 may be a separate software program (e.g. executing on a different processor or machine from the compiler 122), although in the exemplary embodiments described herein, the interpreter 126 is provided within a single linked editing module 120, for execution on one processing platform. The compiler 122 may also use the interpreter 126 to verify that the edit script 124 produced by the compiler 122 results in states of the source code which match the successive snapshots 132, 134, 136 and 138 provided as input to the editing module 120, and may signal an error to a human operator if there is an inconsistency. The interpreter 126 uses the client portion 128 of the IDE driver to interact with the IDE 150 through a server 152 extension module. The interpreter 126 is responsible for evaluating the operations in the edit script 124 and calling the appropriate methods to carry out these operations on the IDE driver client 128. The interpreter 126 has methods for controlling the IDE 150, via the IDE driver 128, 152, to perform common, predefined text-editing operations such as: indenting a block of text, deleting a line of text, cutting a block of text, pasting a block of text, inserting text characters, and deleting text characters. For example, a delete operation in the edit script 124 which specifies the removal of a section of text (e.g. a certain sequence of characters), may be interpreted by the interpreter 126 as requiring the IDE driver to navigate the cursor to the start of the section of text to be removed, then navigate to the end of the selection to be deleted while extending the current selection (e.g. by simulating a user holding a “shift” key down on a keyboard while pressing the “right arrow” key an appropriate number of times), and then deleting the selected text. Thus, one operation in the edit script 124 may result in multiple calls to the IDE driver client 128. The IDE driver client 128 then communicates with the server component 152 of the IDE driver, through an API, to implement these calls within the IDE 150. API communications may include lower-level operations such as inserting individual text characters to simulated typing, or navigating a cursor up or down between individual lines of text, but also may include higher-level operations such as deleting an entire line of text, pasting a line of text, and indenting or un-indenting a selected of a portion of text. The IDE driver also calculates the pace of keypresses for the simulated edits based on an overall playback rate set on the driver by the client. For example, keystrokes might be nominally every 200 milliseconds, but if playing back with a rate of 2.0, they would be every 100 milliseconds, so typing takes half the time. They exact intervals between key-presses can also be varied based on a function which associates a cost (i.e. a delay) with each keypress to give a natural effect. For example, assuming a QWERTY layout, successive keys typed with alternate hands are faster than successive keys typed with the same hands. Shifted characters can take a bit longer, and changes in shift state as in AaAaA have a time penalty too. Repeated characters in a word take less time. All this adds to the realism, and helps prevent the playback looking robotic and unnatural. There is typically has a lot of freedom in how edit operations are implemented by the interpreter 126, while still validly evolving the source code from one snapshot to the next. The interpreter 126 may be configured to make decisions based on factors such as: the value of the edit operations, the state of the source code work, and the current cursor position. For example, deleting a few characters may be implemented by deleting each character individually, whereas deleting a few complete lines of characters might be implemented by using a corresponding number of individual line- deletion operations, while deleting a large number of lines might be implemented by using the select-and-delete sequence of operations described above to delete an entire block of text at once. The interpreter 126 can optionally implement a system of hints from an interpretation hints file 144, separate to the compilation hints file 142. For example, the interpreter 126 may implement a hint which specifies whether a replace operation in the edit script 124 should be implemented by replacing whole or partial tokens. (As described in more detail below, a token is a string of one or more characters that defines a meaningful entity for the type of work that is being edited. For example, tokens may include respective source-code keywords, variables, operators, literals, etc.) This use of hints is useful when a token being replaced is very similar to a token replacing it— for example, when pluralising a variable by adding an ‘s’ to the end of its name, such as replacing “item” with “items”. In this case, a hint can be used to specify that the ‘s’ should added, rather than the whole token replaced by deleting “item” then retyping “items”, so as to better simulate how a human editor would implement the change. Some types of hint may be provided either in a compilation hint file 142 or in an interpretation hint file 144. In general, implementing the hints as compilation hints rather than interpretation hints may reduce the complexity of the interpreter 126. Figure 3 is a schematic diagram showing the compiler 122 of the editing module 120 in more detail. The compiler 122 processes successive adjacent pairs of snapshots 132- 138 in turn. Figure 3 shows it receiving input data from the first and second snapshots 132, 134, by way of example. It compares the snapshots 132 and 134 to determine a set of edit operations 324, which will form a subsequence within the full edit sequence 124. The subsequence 324, when implemented in the IDE 150, evolves the source code from the first snapshot 132 to the second snapshot 134 through a sequence of simulated user-interface edits (e.g. simulating a user pressing keys of a physical or virtual keyboard, including individually or in combination such as CTRL+C for copying to a clipboard). The compiler 122 comprises a tokenizer 302, which tokenizes the text characters of each snapshot 132, 134 and outputs a respective tokenized snapshot 332 and 334 for each input snapshot 132, 134. These are input to a line-level difference module 304. The line-level difference module 304 receives the tokenized snapshots 332, 334, and processes them to output a line-level edit list 306 of successive line-level edit operations. The line-level edit list 306 is then passed as input to the token-level difference module 308, which in turn outputs a token-level edit list 310 of successive token-level edit operations. The token-level edit list 310 is provided to transformation module 312, which can also receive compilation hints from the compilation hint file 142. The transformation module 312 outputs the subsequence of sequential edit operations 324 which is concatenated with the subsequences for the other pairs of snapshots to form the edit script 124 for the full sequence of successive snapshots 132, 134, 136, 138. Input data from each of the first snapshot 132 and the second snapshot 134 is provided to the compiler 122 as a respective text file consisting of a string of successive of characters. These characters represent the text (e.g. letters, numbers and symbols) and formatting (e.g. spaces, newlines and tab characters) in each respective snapshot 132, 134. Rather than the compiler 122 working on the snapshots 132 and 134 as a sequence of individual characters, the tokenizer 302 first groups the characters in the snapshots 132 and 134 into tokens, and assigns a token type (e.g. “string”, which may be encoded by a predefined number) and a token value (e.g. “hello”) to each such group. This means that the text in each of the snapshots 132, 134 will be broken up into a sequence of such tokens. The token types are defined so as to be meaningful in the domain of the work that is represented by the snapshots. For example, in the example where the text-based work contains source code in the Python programming language, the tokens may include Python identifiers, keywords, operators, and literals, as well as having a token for whitespace, etc.. The tokenizer may use a specific lexer (i.e. a program that performs lexical analysis) which may be configurable or selectable by a user; for example, where the work contains Python source code, the lexer may be specified as one which can interpret the Python programming language, such as the Pygments lexer. Different lexers may be used for Java, C++, or other types of work. The tokenizer 302 may have the capability to use any number of different lexers. Tokenization is beneficial because it attaches meaning to the characters in the text- based work, and because humans tend to read, write, and edit documents at the level of tokens rather than characters. This allows the compiler 122 to produce more naturalistic edit sequences 324 that more accurately simulate how a human would edit the work. For example, when replacing the word “Python” with “Editron” in a document in a text editor application, most people would instinctively delete the entire word “Python” and type the word “Editron” in its place, rather than deleting the two characters “Py” and replacing them with the three characters “Edi”, and then deleting the character “h” and replacing it with the character “r”—i.e. so as to leave the original letters “t” and “on” intact, which is what purely character-level difference-based editing would do. Treating the word “Python” as a single token, and the word “Editron” as a single token, is suboptimal in a purely computational sense (being an edit distance of fourteen versus an edit distance of four), but is far more naturalistic and, for a human editor, usually quicker. In the compiler 122, a hierarchical differencing (i.e. diffing) algorithm is used to compute the differences between the successive snapshots 132 and 134 by first using the line-level difference module 304 and then the token-level difference module 308. However, there are many different diffing algorithms which could be implemented in practice in variant embodiments. For the example compiler 122 shown in Figure 3, first the line-level diffing operation 304 groups the tokens into runs which represent a single physical line of source code, by starting a new run after each line terminator token (e.g. newline, carriage return or line feed). This grouping is important because it reflects the way that humans tend to read, write, and edit a text-based work. The line-level diffing operation 304 then compares groups of tokens representing whole lines between the two snapshots 132, 134. Any of several different diffing algorithms can be used for this purpose, such as a Ratcliff / Obershelp pattern recognition algorithm. Before performing the line-level diffing, the lines are first stripped of any leading tokens that represent indentation. The reason for this is that adding or removing indentation to blocks of source code is a common operation which tends to lead to complicated diffs with a large number of changes. By stripping the indentation from the lines before line- level diffing, this problem can be avoided and the degree of similarity between the line- level diffs of two snapshots 132, 134 can be increased, leading to more accurate correlations. The result of this line-level comparison is a sequence of line-level edit operations 306 which describe how to transform the lines of the first snapshot 132 into the lines of the second snapshot 134, where each operation is one of replace, delete, insert or equal, and each operation contains information on which lines in the first snapshot 132 relate to which lines in the second snapshot 134. This line-level diffing allows runs of equal lines, runs of deleted lines, runs of inserted lines, and runs of replaced lines, to be identified, and for the tokens within each run to be handled together, with the next, lower-level phase of diffing being applied separately to the tokens within each run. In order to compare runs of lines (irrespective of whether the line-level operation is equal, delete, insert or replace—i.e. ignoring the line-level operator), the lines of tokens within each run are flattened into two single sequences of tokens, corresponding to the first snapshot 132 and the second snapshot 134 respectively. These flattened sequences are then compared in the token-level diffing operation 308. This may use the same diffing algorithm as the line-level difference module 304, but where the elements being compared are individual tokens rather than whole lines of tokens. Alternatively, it could use a different diffing algorithm in some embodiments. The result of this comparison is a sequence of token-level edit operations for each run. These sequences of token-level edit operations are then concatenated into a single sequence or batch. A batch is a list of token-level edit operations 310 which transforms one snapshot 132 to the next 134. The edit operations in a single batch 310 (i.e. associated with a particular pair of snapshots) are applied to the work in a top-to-bottom document order, which is to say that earlier operations modify earlier parts of the work, and later operations modify later parts of the work. One implication of this is that if an author describing an evolving work with snapshots 132-138 wishes an edit nearer the beginning of the work to be applied after an edit has been performed nearer the end of the work (i.e. two edits that are not in document order), then the author must arrange for these edits to be in separate batches by including a snapshot in the snapshot sequence which contains the first edit but not the second edit. The compiler 122 then carries out an important additional process in the transformation module 312, which modifies the token-level edit list 310 by applying a series of transformations designed to transform the token-level edit list 310 into edit sequences 324 that together form an edit script 324 that is more concise and, importantly, more naturalistic when implemented within the IDE 150. Some transformations applied by the transformation module 312 reduce the complexity of an edit list after earlier transformations have been applied. Other transformations are designed specifically to make the edit list more natural by better mimicking the way that humans edit documents. The transformations supported by the transformation module 312 include, among others: detecting a move of a block of text, indenting larger blocks of code in one operation, accommodating new lines of code, and coalescing successive token-level operations that are the same as each other. The transformation module 312 outputs a set of edit operations 324 which can be applied to the source code to change it from the state shown in the first snapshot 132 to the second snapshot 134. To generate the edit script 124 shown in Figure 2, the transformed edit operations (e.g.324) for each pairwise comparison between successive screenshots (e.g.132 and 134, 134 and 136, etc.) are combined. This final edit script 124, when applied to the source code by the interpreter 126, takes the source code from the state shown in the first snapshot 132 to the state shown in the final snapshot 138. An end-to-end example is explained in detail below to illustrate the operation of the compiler 122. The example does not demonstrate all of the features that may be implemented within the system 100, but exemplifies how the system 100 works to show the underlying principles that it implements. An exemplary sequence of snapshots of source code in the Python language, which are provided to the compiler 122, are as follows: Snapshot 1 : theory_010.py 1 #! / usr / bin / env python3 2 print("Hello, Python!") Snapshot 2 : theory_020.py 1 #! / usr / bin / env python3 2 print("Hello, Editron!") Snapshot 3 : theory_030.py 1 #! / usr / bin / env python3 2 3 def greet(): 4 print("Welcome!") 5 print("Hello, Editron!") Snapshot 4 : theory_040.py 1 #! / usr / bin / env python3 2 3 def greet(): 4 print("Welcome!") 5 print("==") 6 print("Hello, Editron!") Snapshot 5 : theory_050.py 1 #! / usr / bin / env python3 2 3 def make_greeter(): 4 5 def greet(): 6 print("Welcome!") 7 print("==") 8 print("Hello, Editron!") 9 10 return greet 11 12 g = make_greeter() 13 g() In the first snapshot, a simple Python program which prints the string “Hello, Python!” to the console is created. In the second snapshot, the string is changed to “Hello, Editron!”. In the third snapshot, the print statement is wrapped in a function. In the fourth snapshot, a print statement is added to show a banner underneath the welcome message. In the fifth snapshot, the existing greet function is enclosed into another function called “make_greeter”, and the “make_greeter” function and the callable object it produces are invoked. These five snapshot files are stored in a directory such as the snapshots file store 130 and ordered sequentially. As explained with reference to Figure 3, the compiler 122 computes the difference between each successive pair of successive snapshots, first comparing an empty zeroth snapshot with the first snapshot, then the first snapshot with the second, and so on. To produce an edit script 124 from these snapshots, a command is run to call the compiler 122. The command has parameters specifying the file path of the source files to use as input, the file path for outputting the final edit script, as well as which lexer to use, and optionally may specify a hints file (e.g. hints file 142) to use when producing the edit script 124, as explained above. Further parameters may also be provided, for example, specifying the format which should be used for the output file. While five snapshots are explicitly provided in this example, the compiler will implicitly add a zeroth snapshot which comes before the first snapshot. This zeroth snapshot is the empty work. This is useful because it allows the initial state of the work given in the first snapshot to be described as the difference between the zeroth snapshot and the first snapshot. This makes the edit script self-contained, and obviates the need to provide the initial state of the work as a separate input. Each snapshot is associated with a label which is used to refer to the snapshot in the edit script. For the detailed example described here, the labels of the explicit snapshots are the names of the files which contain the snapshots, for example theory_010.py. For the implicit zeroth snapshot, the label is the string '<empty>'. Rather than working on the snapshots as a sequence of characters, the compiler will first tokenize the snapshots as described with reference to Figure 3. The text from the first snapshot, when tokenized, yields the following 13 tokens, in order. Token Type Token Value Comment.Hashbang #! / usr / bin / env^python3 Text.Whitespace ↵ Name.BuiltinprintPunctuation(Literal.String.Double“Literal.String.DoubleHelloLiteral.String.Double,Literal.String.Double ^ Literal.String.DoublePythonLiteral.String.Double!Literal.String.Double“Punctuation)Text.Whitespace ↵ The ^ symbol here represents a single space (e.g. as generated by one strike of the spacebar on a keyboard). In this exemplary implementation of the invention, the tokenization is performed by the third-party Pygments library for which an appropriate lexer needs to be specified. This is supplied as an option to the make-edit script command as described above. The tokens returned by Pygments are post processed by the compiler to make them more suitable for our purposes. In particular, the compiler splits literal string tokens (Literal.String) into separate tokens each time the Unicode character class changes. This places the string delimiters, internal punctuation, whitespace, newlines and whole words into separate tokens. For example, the single token obtained from Pygments for the string literal "Hello, Python!" is tokenized as: ", Hello,, space, Python, ! and ". The compiler also splits text tokens (Text) which contain a line-continuation character (\) followed by a newline character into two separate tokens, one for the line- continuation character and one for the newline character. Notice that the same characters may be tokenized differently depending on their context. For example, a space character is tokenized as part of the Comment.Hashbang in the first token, but as a standalone Literal.String.Double in the context of the double-quoted string literal. In yet other contexts, the space character may be tokenized as a Text token. As explained above with reference to Figure 3, groups of tokens representing whole lines are first compared between successive snapshots. The line-level diff between the first snapshot (before) and the second snapshot (after) is shown below: Snapshot 1 Snapshot 2 Operation Half-open Ranges theory_010.py theory_020.py #! / usr / bin / env python3 #! / usr / bin / env python3equal [0, 1) → [0, 1)print("Hello, Python!") print("Hello, Editron!")replace [1, 2) → [1, 2)The last column here shows the half-open ranges of line indexes (zero-based) affected by the operation. The equal operation maps lines index 0 in the first snapshot to line index 0 in the second snapshot, and the replace operation maps line index 1 in the first snapshot to line index 1 in the second snapshot. While the table above shows the snapshots as strings for brevity, in reality each line is by this point a list of tokens. Next, the lower-level phase of diffing is applied to the tokens within each run by the token-level difference module 308 described with reference to Figure 3. The resulting list of token-level differences is shown in the table below. Snapshot 1 Snapshot 2 Operation Half-open Ranges theory_010.py theory_020.py #! / usr / bin / env^python3 ↵ #! / usr / bin / env^python3 ↵equal [0, 23) → [0, 23)print ( " Hello , ^ print ( " Hello , ^equal [23, 37) → [23, 37)Python Editronreplace [37, 43) → [37, 44)!" ) ↵ ! " ) ↵equal [43, 47) → [44, 48)One of the later tidying transformations applied to the list of token-level differences shown above by the transformation module 312 is the coalesce-equals transformation. This transformation merges adjacent equal operations into a single equal operation, giving the following edit script: Snapshot 1 Snapshot 2 Operation Half-open Ranges theory_010.py theory_020.py #! / usr / bin / env^python3 ↵ #! / usr / bin / env^python3 ↵ equal [0, 37) →[0, 37) print ( " Hello , ^ print ( " Hello , ^ Python Editronreplace [37, 43) →[37, 44)!" ) ↵ ! " ) ↵equal [43, 47) →[44, 48) The effect of this transformation is to reduce the number of operations in the edit script, and therefore the complexity of the edit script. However, it does not change the result of applying the whole of the edit script. While coalesce-equals is simple, it succinctly illustrates how post-diff transformations implemented by the transformation module 312 in the compiler 122 fit into the overall process. Having described in full the production of the complete edit script for the evolution of Snapshot 1 into Snapshot 2, the production of the edit script for the evolution of Snapshot 2 into Snapshot 3 will now be described. This evolution is more complex, and so is the edit script and the transformations required to make the result appear natural. The line- and token-level diffing of the two snapshots, followed by the transformations applied by the transformation module 312 produces the following edit script: Snapshot 2 Snapshot 3 theory_020.py theory_030.py Operation Half-open Ranges #! / usr / bin / env^python3 ↵ #! / usr / bin / env^python3 ↵ equal [0, 23) → [0, 23) «nothing»↵insert [23, 23) → [23, 24)«nothing» <ZERO-INDENT>zero-indent [23, 23) → [24, 24)«nothing»def ^ greet ( ) : ↵insert [23, 23) → [24, 37)«nothing»^^^^indentation [23, 23) → [37, 41) print ( " Welcome ! " «nothing» insert [23, 23) → [41, 59) ) ↵«nothing»^^^^indentation [23, 23) → [59, 63) print ( " Hello , ^ print ( " Hello , ^ equal [23, 48) → [63, 88) Editron ! " ) ↵ Editron ! " ) ↵ Three types of transformation have been applied in the above example. First, a convert-indentation is applied which identifies standalone insertions of indentation characters (i.e. spaces or tabs preceded by a newline character) and converts the insert operation into an indentation operation. This gives the interpreter 126, running downstream of the compiler 122, information that the spaces specifically represent indentation. Many code editors give indentation special treatment, so this is important information. A split-insertion-on-indentation transformation is also applied, which arranges for any leading indentation characters on a line (i.e. spaces or tabs preceded by a newline character) to be partitioned off from the rest of the line into their own insert operation. Notice that the value of the indentation operation is still a token containing four spaces; only its type has changed. The decision on whether those four spaces represent one indentation level of four spaces, or two indentation levels of two spaces each, is deferred for the interpreter 126 to decide as it will have more contextual information about the text-editing environment in which it is running. A detect-zero-indents transformation has also been applied, which searches insert and replace operations where the inserted text contains newline characters which are not followed by any indentation characters in the target snapshot state. This is an indication that the following line is intended to have no indentation. The transformation module 312 inserts special zero-indent operations to signify this, allowing the downstream edit script interpreter to make the appropriate adjustments to the indentation of the following line. This is necessary because many text-editing environments (e.g. IDEs and word processors) will automatically indent the following line when the user presses Enter, and in cases where this automatically inserted indentation is not desired, the interpreter must ensure that it is deleted. These zero- indent operations can be important synchronization points to ensure that the state of the text-editing application (e.g. IDE 150) and the state assumed by the edit script remain in synchronisation. Note that what was a single insert operation has been split into two insert operations, and a zero-indent operation has been placed between, after the newline token. The zero-indent operation contains a special zero-length ZERO-INDENT token. Changing the source code from the third snapshot to the fourth snapshot comprises inserting a new line of code. The line- and token-level diffing of the third snapshot and the fourth snapshot, followed by applying coalesce-equals and indent transformations as described above, produces the series of edit operations in the table below. Snapshot 3 Snapshot 4 theory_030.py theory_040.py Operation Half-open Ranges #! / usr / bin / env^python3 ↵ #! / usr / bin / env^python3 ↵ ↵ ↵ def ^ greet ( ) : ↵ def ^ greet ( ) : ↵ equal [0, 59) → [0, 59) ^^^^ print ( " ^^^^ print ( " Welcome ! " ) ↵ Welcome ! " ) ↵«nothing»^^^^indentation [59, 59) → [59, 63)«nothing»print ( " == " ) ↵insert [59, 59) → [63, 75)^^^^ print ( " Hello ^^^^ print ( " Hello equal [59, 88) → [76, 104) , ^ Editron ! " ) ↵ , ^ Editron ! " ) ↵ Note that to implement the insertion of a line of code, the insertion point of the indentation at position 59 is at the beginning of the line which prints “Hello, Editron!”, which begins at position 59 in the third snapshot. The inserted text ends with a newline character (↵). This seems reasonable as a new line of code has been inserted in the position where the line which prints “Hello, Editron!” used to be, and line of code is terminated by newline characters. Consider, however, what would happen if the edit script interpreter were to interpret this edit script naively, yet incrementally, by simulating the typing of the changes described in the order of the script. The series of incremental edits which would occur following the script of operations above is shown below in the left-hand column, depicting the “naïve” edit sequence. The “transformed” edit sequence, which would more naturally be implemented by a human developer, is shown on the right-hand side. The cursor position is shown with the ^ character, and starts at the position 59, which is at the beginning of the line which prints “Hello, Editron!” in the third snapshot: Snapshot 3 : theory_030.py def greet(): print("Welcome!") print("Hello, Editron!") ^ Naive edit sequence Transformed edit sequence def greet(): def greet(): print("Welcome!") print("Welcome!") print("Hello, Editron!") ^ print("Hello, Editron!") ^ def greet(): def greet(): print("Welcome!") print("Welcome!") print("= print("Hello, Editron!") ^ ^ print("Hello, Editron!") def greet(): def greet(): print("Welcome!") print("Welcome!") print("==") print("Hello, Editron!") print("= ^ print("Hello, Editron!") Snapshot 4 : theory_040.py def greet(): print("Welcome!") print("==") print("Hello, Editron!") ^ For the naïve edit sequence, first the indentation is inserted, perhaps by the interpreter 126 which is controlling the IDE 150 ‘pressing’ the Tab key, as a human editor would do. Then the insert operation is applied at position 63, which is now the current cursor position. All pending characters except the newline character are inserted, then only when the final newline character is inserted, is the desired state in the fourth snapshot achieved. While all of these states are correct, only the final state is natural-looking. Almost no human would usually add a line to a work in this way by substantially modifying an existing line before splitting the line in two. Instead, people typically create accommodation space for one or new lines by pressing Enter one or more times, and then adding text to these empty lines. This amounts to, as shown for the transformed edit sequence, pressing Enter first, at position 59, navigating the cursor back into the gap, which is still at position 59, and then typing the indentation and the content of the line, yielding the same final document state. The transformed set of edit operations which creates this sequence is shown below. Snapshot 3 Snapshot 4 Half-open theory_030.py theory_040.py Operation Ranges #! / usr / bin / env^python3 ↵ #! / usr / bin / env^python3 ↵ ↵ ↵ [0, 59) ef ^ greet ( ) : ↵ def ^ greet ( ) : ↵ eq → d ual [0, 59) ^^^^ print ( " ^^^^ print ( " Welcome ! " ) ↵ Welcome ! " ) ↵ «nothing» [59, 59) → ↵ insert [59, 60) «nothing»^^^^indentation [59, 59) → [59, 63) «nothing»print ( " == " )insert [59, 59) → [63, 74) ^^^^ print ( " Hello ^^^^ print ( " Hello equal [59, 88) → [75, 104) , ^ Editron ! " ) ↵ , ^ Editron ! " ) ↵ The newline character has been relocated from the end of the insert operation into a new insert operation prior to the indentation operation. Notice that this new insert operation and the following indentation operation are both emplaced at the same position, 59. This implies that the edit script interpreter will need to navigate the cursor back to position 59 before applying the indentation. This is a key mechanism for achieving a natural-looking evolution of the work. This behaviour has limits though. People generally don’t insert 25 blank lines in order to insert 25 new lines of text. They might, however, insert a few blank lines to create accommodation space for the new text, and start writing 25 lines within that gap. The general accommodate-new-lines transformation identifies runs of insert and indentation operations (note that indentation operations are really a special case of insert operations) where the last tokens in the run are newline characters. The sequence of tokens in the run is then rotated to shift newline tokens from the end of the run to the beginning of the run, with a new insert operation being created at the beginning of the run to accept the rotated newline characters. A (configurable) maximum of three newline characters are rotated, just enough to create accommodation space in which new lines can be entered naturally. As the work evolves to the fifth snapshot, the existing greet function is wrapped in a new function called make_greeter and two new lines of code are added to the end of the program to invoke make_greeter and call the function returned by it. In the set of differences produced by the line-level diff and token-level diff operations, the existing code which has been indented is represented as insert and replace operations which add or modify indentation whitespace, alternating with equal operations which represent the unmodified, by now indented, code. A batch-indentation transformation would be applied to this edit script, which looks for an alternating pattern of operations as described above, and, if the indentation operations are compatible (which is to say, they all represent the same amount of added or removed indentation) then the run of alternating operations is replaced by a single indent-block operation. Thus, when implementing the batch-edit operation, the simulated edits may comprise selecting all of the lines which are to be indented, then indenting them all in one keystroke, rather than individually indenting each new line. The end-to-end example described above, as may be appreciated, highlights some of the specific transformations which may be applied by the transformation module 312 in the compiler 122 of the editing module 120. Any number of transformations may be applied in order to transform the more standard “diffs” which may be produced by a typical diff comparison between two versions of a text-based work into a set of edit operations which the interpreter 126 may use to implement a natural looking sequence of simulated user-interface edits which are depicted in the resulting animation. This process allows an animation to be created which simulates the actions that a human editor would take to change the text from one state to another. It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.

Claims

CLAIMS 1. A computer-implemented method for generating animation data for depicting a sequence of simulated user-interface edits to a text-based work, the method comprising: comparing first data, representative of a first state of a text-based work, with second data, representative of a second state of the text-based work, to determine a set of differences between the first state and the second state of the text-based work; processing the set of differences to generate a set of edit operations; and processing the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits to the text-based work that change the text-based work from the first state to the second state.

2. The method of claim 1, wherein the sequence of two or more simulated user- interface edits comprise edits that could be applied to the text-based work by a human operator interacting with a computer system.

3. The method of claim 1 or 2, wherein the data representative of the first state of the text-based work represents the state at a first point in time within the animation data, and the data representative of the second state of the text-based work represents the state at a later point in time within the animation data.

4. The method of any preceding claim, wherein the data representative of a state of the text-based work is or comprises text data.

5. The method of any preceding claim, wherein the text-based work comprises source code.

6. The method of any preceding claim, wherein the animation data is suitable for generating an animation of the sequence of simulated user-interface edits to the text- based work.

7. The method of any preceding claim, wherein the animation data comprises a video file.

8. The method of any preceding claim, wherein the animation data encodes a plurality of frames, wherein a frame of the animation data comprises a first graphical representation of the first state of the text-based work and a further frame of the animation comprises a graphical representation of the second state of the text-based work.

9. The method of any preceding claim wherein the data representative of the first state and the data representative of the second state are provided as input to a lexical tokenizer; and wherein the lexical tokenizer is configured to generate tokenized data that encodes groups of one or more characters of the text-based work, in a respective state, by one or more tokens.

10. The method of any preceding claim wherein the set of differences comprises a sequence of differences and / or wherein the set of edit operations comprises a sequence of edit operations.

11. The method of any preceding claim wherein the set of edit operations includes at least one operation of a type that is not present in the set of differences, and processing the set of differences to generate the set of edit operations comprises introducing one or more types of edit operation that are not present in the set of differences.

12. The method of any preceding claim wherein every difference in the set of differences comprises a respective operation type, and wherein every operation type in the set of differences affects a respective single range of contiguous characters.

13. The method of any preceding claim wherein every difference in the set of differences comprises a respective operation type, and wherein every operation type in the set of differences is one of: equal, insert, replace and delete.

14. The method of any preceding claim wherein processing the set of differences to generate the set of edit operations comprises identifying a predetermined pattern of differences in the set of differences.

15. The method of any preceding claim wherein generating the set of edit operations comprises including, in the set of edit operations, an edit operation for indenting a line of text.

16. The method of any preceding claim wherein generating the set of edit operations comprises including, in the set of edit operations, an edit operation for indenting a block of text comprising plurality of lines of characters.

17. The method of any preceding claim, wherein generating the set of edit operations comprises including, in the set of edit operations, a sequence of edit operations for accommodating one or more new lines of text.

18. The method of any preceding claim, wherein processing the set of edit operations to generate animation data for depicting a sequence of two or more successive simulated user-interface edits comprises converting one or more, or all, of the edit operations in the set of edit operations to one or more editor control instructions; and using the editor control instructions to operate driver software which interfaces with a text-editing application.

19. Software comprising instructions which, when executed on a processing system, cause the processing system to carry out the method of any of claims 1 to 18.

20. A processing system for generating animation data for depicting a sequence of simulated user-interface edits to a text-based work, the processing system comprising one or more processors and a memory storing software, wherein the software comprises instructions which, when executed by the one or more processors, cause the processing system to carry out the method of any of claims 1 to 18.

Images