Patent Description:
While working on changes to a codebase, it is important for developers to understand what has changed between each version of the codebase. However, when multiple developers are collaborating in teams during development, it may become difficult to keep track of all of the changes made by each developer and how those changes will affect the stability of the codebase. <CIT> discloses a method for examining and debugging code. In one embodiment, code modification information for a code portion is programmatically generated, wherein the code modification information reflects at least one change made to the code portion with respect to a previous version of the code portion. The code portion is then displayed on a display device during a debugging Session; and the code modification information is visually represented on the display device while displaying the code portion. <CIT> discloses a method for debugging a change-set. The method includes obtaining a change-set for debugging, calculating a code change region by using the change-set and generating breakpoints for debugging the change-set based on the code change region. In exemplary embodiments, breakpoints in a change-set can be set quickly and effectively. It is the object of the present invention to provide improved difference view modes in integrated development environments.

To address the issues discussed above, a computer device is provided. The computer device includes a display and a processor configured to execute an integrated development environment that includes code development tools, output for display on the display an editor window of the integrated development environment configured to present a code file and real-time mark-up of the code file, wherein the editor window includes a difference view mode that causes the editor window to emphasize a difference between the code file and a baseline code file. The processor is further configured to perform a function of one of the code development tools on the code file and present a result of the function in the editor window while in the difference view mode.

Difference view add-ons for an integrated development environment (IDE) open new tabs in the IDE separate from the main editor window that show differences between two code files. Typically, these difference view add-ons are not fully integrated with the IDE, and are unable to access the various development tools offered by the IDE, such as, for example, debugging tools, code editing tools, symbolic analysis tools, and other types of development tools. Thus, in order to access the full developmental features of IDE, users of these difference view add-ons must typically tab back and forth between the main editor window of the IDE and the window of the difference view add-on.

In order to address the challenges discussed above, a computer device <NUM> is provided, as shown in the example embodiment of <FIG>. The computer device <NUM> may include a display <NUM>, volatile memory <NUM>, non-volatile memory <NUM>, a processor <NUM>, and/or an input device suite <NUM> including one or more input devices <NUM>. The one or more input devices <NUM> may include, for example, one or more of a keyboard, a mouse, a trackpad, a touchscreen, a microphone, a camera, an inertial motion unit, a global positioning system (GPS) unit, and/or some other input device <NUM>. In addition to the display <NUM>, the computer device <NUM> may further include one or more other output devices, such as a speaker, a haptic feedback unit, or another type of output device.

The processor <NUM> of the computer device <NUM> may be configured to execute an integrated development environment (IDE) <NUM> that includes a source code editor for editing code files. The IDE <NUM> may also include code development tools <NUM>, such as, an integrated debugging tool 26A, a breakpoint tool 26B, a symbolic lookup tool 26C, an intelligent code completion tool 26D, and other types of development tools 26E.

In one example, the integrated debugging tool 26A may be configured to provide functions for viewing a call stack of a currently executing code file at a designated point in time. The integrated debugging tool 26A may also provide functions for changing variable values while the code file is running, inspect the values of variables while the code file is running, skip or repeat sections of code of the code file, examine memory contents associated with the running code file, view thread contexts for multi-threaded applications, and other types of debugging functions. The integrated debugging tool 26A may also include the breakpoint tool 26B configured to halt execution of a code file when a set breakpoint in the code file is reached. The integrated debugging tool 26A may be configured to generate debugging events, such as, for example, an exception that is thrown for a code file, a breakpoint event for a running code file that has reached a breakpoint set via the breakpoint tool 26B, or some other condition that triggers a debugging event.

The symbolic lookup tool 26C may be configured to provide functions for navigating to selected classes, files, and/or symbols specified by names. The intelligent code completion tool 26D may provide functions for context-aware code completion by presenting auto completion popups as the user is typing to reduce typographical and syntactical errors. It will be appreciated that the development tools <NUM> described above are merely exemplary, and that the IDE <NUM> may include other development tools 26E not specifically described above.

As illustrated in <FIG>, the processor <NUM> may be configured to output for display on the display <NUM> a graphical user interface (GUI) <NUM> of the IDE <NUM>. The GUI <NUM> may include various GUI elements, such as, for example, a tool bar, windows, and other GUI elements that a user of the computer device <NUM> may utilize to enter input to the IDE <NUM> via the input device suite <NUM>. In one example, the GUI <NUM> output to the display <NUM> includes an editor window <NUM> of the IDE <NUM> configured to present a code file <NUM>. The editor window <NUM> may be configured to display each of the code instructions <NUM> of the code file <NUM>. The editor window <NUM> may also be configured to display GUI elements for organizing the displayed code instructions <NUM>, such as, for example, line numbers. The editor window <NUM> may also display real-time mark-up of the code file <NUM> as the user edits/changes the code instructions <NUM>, adds/deletes comments, or otherwise edits the code file <NUM>. For example, the editor window <NUM> may indicate one or more syntax errors in the code file <NUM>.

The editor window <NUM> includes a difference view mode <NUM> that causes the editor window <NUM> to emphasize a difference <NUM> between the code file <NUM> and a baseline code file <NUM>. The difference <NUM> may be determined by the processor <NUM> in real-time by comparing the code file <NUM> to the baseline code file <NUM>. The difference <NUM> may include a code difference <NUM> between the code instructions <NUM> of the code file <NUM> and the baseline code file <NUM>. For example, the code difference <NUM> may include one or more code instructions <NUM> that have been added to the code file <NUM>, deleted from the code file <NUM>, and/or partially replaced or otherwise edited compared to the code instructions of the baseline code file <NUM>.

The difference <NUM> may further include changes to one or more non-instructions portions <NUM> of the code file <NUM>, such as comments and/or whitespace. As shown, the difference <NUM> may include a non-instruction difference <NUM> between code comments or whitespaces of the code file <NUM> and the baseline code file <NUM>. It will be appreciated that other types of differences between the code file <NUM> and the baseline code file <NUM> may also be determined and emphasized by the editor window <NUM>.

In one example, the IDE <NUM> may be configured to toggle on the difference view mode <NUM> of the editor window <NUM> for an already opened code file <NUM> in response to an event. For example, if the user edits/changes the already opened code file <NUM>, the IDE <NUM> may be configured to toggle on the difference view mode <NUM> for the editor window <NUM> presenting the opened code file <NUM>. As another example, a code file <NUM> may be opened in the editor window <NUM> directly into the difference view mode <NUM> in response to an event, such as, for example, a debugging event of the integrated debugging tool 26A.

Turning to <FIG>, an example GUI <NUM> of the IDE <NUM> is illustrated. The illustrated GUI <NUM> includes the editor window <NUM> of the IDE <NUM> that is currently operating in the difference view mode <NUM>. Thus, as shown, the editor window <NUM> visually presents the code file <NUM> and the baseline code file <NUM>. In the illustrated example, the code instructions and comments of the code file <NUM> and the baseline code file <NUM> are organized by line number and presented side-by-side in the editor window <NUM>. In this specific example, the code instructions at lines L1 and L2 of the baseline code file <NUM> remain unchanged in the code file <NUM>. Similarly, the non-instruction comments at line L3 of the baseline code file <NUM> also remain unchanged in the code file <NUM>.

However, at line L4 of the code file <NUM>, the user has inserted a new comment 44A that is not included in the baseline code file <NUM>. Similarly, at line L5 of the code file <NUM>, the user has inserted a new code instruction 34A that is also not included in the baseline code file <NUM>. The processor <NUM> detects these differences <NUM> of the new code instruction 34A and the new comment 44A, and emphasizes the detected differences <NUM> in the editor window <NUM>.

In one example, to emphasize the detected differences <NUM> in the editor window <NUM>, the processor <NUM> may be configured to highlight the lines in the editor window <NUM> that include code differences <NUM> and/or non-instruction differences <NUM>. In the example illustrated in <FIG>, a highlight <NUM> has been applied to lines L4 and L5 for the code file <NUM> to emphasize the new comment 44A and the new code instructions 34A to the user. A contrasting highlight <NUM> may also applied to a corresponding space of the editor window <NUM> for the baseline code file <NUM>.

Continuing the illustrated example, lines L5, L6, and L8 of the baseline code file <NUM> include baseline code instructions. The baseline code instructions of lines L5 and L6 of the baseline code file <NUM> remain unchanged at lines L7 and L8 of the code file <NUM>. However, the baseline code instructions of line L8 of the baseline code file <NUM> have been deleted from the code file <NUM>. The processor <NUM> may detect this difference <NUM> of the deleted baseline code instruction 34B, and emphasizes the detected difference in the editor window <NUM>. In the example illustrated in <FIG>, a highlight <NUM> has been applied to line L8 for the baseline code file <NUM>, and a contrasting highlight <NUM> has been applied to a corresponding space of the editor window <NUM> for the code file <NUM>.

In one example, the highlight <NUM> and contrasting highlight <NUM> take the form of changes in background color or shading of the lines of the editor window <NUM>. As another example, the highlight <NUM> may be a change in color of the code instructions or comments that have been changed. It will be appreciated that other forms and styles of emphasis may be used by the processor <NUM> to emphasize the differences <NUM> between the baseline code file <NUM> and the code file <NUM>. For example, a change in font, bolding, underlining, strikethrough, italicization, etc., may be used to emphasize the differences <NUM> in the editor window <NUM>.

Turning to <FIG>, the processor <NUM> is configured to perform a function of one of the code development tools <NUM> on the code file <NUM> and present a result of the function in the editor window <NUM> while in the difference view mode <NUM>. In one example, the one of the code development tools performed on the code file includes the integrated debugging tool 26A. The integrated debugging tool 26A may be configured to generate debugging events, such as, for example, an exception thrown for the code file <NUM>. The processor <NUM> may be configured to detect the debugging event generated for the code file <NUM> by the integrated debugging tool <NUM>.

In one example, the code file <NUM> may not currently be opened when the debugging event was generated for the code file <NUM>. For example, the IDE <NUM> may currently be running a plurality of code files of a program that includes the code file <NUM>, and may encounter a debugging event, such as an error, that occurs while the code file <NUM> is being run. In this example, the IDE <NUM> executed by the processor <NUM> may be configured to open the code file <NUM> in the editor window <NUM> in the difference view mode <NUM> based on at least detecting the debugging event generated by the integrated debugging tool 26A. That is, in response to detecting a debugging event for a code file <NUM> that is not currently opened, the IDE <NUM> may be configured to open that code file <NUM> in the editor window <NUM> directly in the difference view mode <NUM> with a suitable baseline code file <NUM>, such as, for example, a previous version of the code file <NUM>. In one example, multiple debugging events may be detected for multiple different code files, and the IDE <NUM> may be configured to concurrently open each of the multiple different code files in the editor window <NUM> in the difference view mode <NUM>.

In one example, the debugging event generated by the integrated debugging tool 26A may include an exception thrown for the code file <NUM>. In this example, after transitioning an editor window <NUM> already presenting the code file <NUM> into the difference view mode <NUM>, or opening the code file <NUM> in the editor window <NUM> directly into the difference view mode <NUM>, the IDE <NUM> may be configured to present the exception <NUM> in the editor window <NUM> in the difference view mode <NUM>. It will be appreciated that the differences <NUM> of the difference view mode <NUM> are concurrently shown with the thrown exceptions <NUM> in the editor window <NUM>. In this manner, the user may concurrently view both the differences <NUM> and the results of the code development tool <NUM> without having to tab between multiple window tabs.

The integrated debugging tool 26A may include other functions. In one example, the integrated debugging tool 26A may be configured to output debugging data <NUM> that may be presented via the GUI <NUM> of the IDE <NUM>. The debugging data <NUM> may include data regarding the call stack of the running code file <NUM>. It will be appreciated that other suitable debugging data <NUM> may also be output and displayed via the GUI <NUM> concurrently with the differences <NUM> between the code file <NUM> and the baseline code file <NUM>.

In another example, the one of the code development tools performed on the code file <NUM> includes the breakpoint tool 26B configured to halt execution of the code file <NUM> at a specified code instruction. <FIG> illustrates an example breakpoint <NUM> set by the user of the computer device <NUM>. The user may enter a user input via the input device suite <NUM> to set the breakpoint <NUM>, such as, for example, clicking a breakpoint GUI element, pressing a breakpoint hotkey, etc. In the illustrated example, the user has set the breakpoint <NUM> at the new code instructions 34A at line L5 of the code file <NUM>. As the user is concurrently presented with the differences <NUM> between the code file <NUM> and the baseline code file <NUM> while performing a set breakpoint function of the breakpoint tool 26B, the user may efficiently identify which code instructions <NUM> of the code file <NUM> have changed, and appropriately set the breakpoint <NUM> to debug/analyze the new code instruction 34A. By setting the breakpoint <NUM>, execution of the code file <NUM> may be halted at line L5 such that the user may view the call stack, inspect variables, and perform other debugging functions to understand a state of the executed code when it reached the specified code instruction.

After the user has set the breakpoint <NUM> in the code file <NUM>, the breakpoint tool 26B of the integrated debugging tool 26A may be configured to detect that the breakpoint <NUM> has been reached while the code file <NUM> is running, and generate a breakpoint event as the debugging event. If the code file <NUM> is not currently opened in the editor window <NUM>, the IDE <NUM> may be configured to automatically open the code file <NUM> in the editor window <NUM> in the difference view mode <NUM> based on at least detecting the breakpoint event.

In other examples, processor <NUM> may be configured to perform functions of the symbolic lookup tool 26C, the intelligent code completion tool 26D, and other development tools 26E on the code file <NUM>, and present a result of those functions in the editor window <NUM> while in the difference view mode <NUM>. For example, a result of a file look-up function, class look-up function, reference look-up function, etc., of the symbolic lookup tool 26C may be presented in a pop-up window in the editor window <NUM> concurrently with the differences <NUM> between the code file <NUM> and the baseline code file <NUM>. In one example, the IDE <NUM> executed by the processor <NUM> may be configured to determine that the result of the function of the symbolic lookup tool 26C occurs in a target code file, which, for example, may be the code file <NUM>, another code file referenced in the code file <NUM>, etc. If the target code file is not currently opened, the IDE <NUM> may be further configured to open the target code file in the editor window <NUM> in the difference view mode <NUM>.

As another example, a result of the intelligent code completion tool 26D, such as the remaining letters in a class, file name, predefined variable, etc., may be presented in a pop-up or in mark-up in real time as the user types in the editor window <NUM> concurrently with the differences <NUM>. In this manner, the user may utilize all of the code development tools <NUM> afforded by the integrated development environment <NUM> while the editor window <NUM> and the IDE <NUM> are toggled in the difference view mode <NUM>.

Turning back to <FIG>, the baseline code file <NUM> may be selected by the user via input to the GUI <NUM>. For example, a code file manager <NUM> of the IDE <NUM> may store a plurality of code files saved by the user. The plurality of code files may be presented in a list on the GUI <NUM> output to the display <NUM>. The user may select both the code file <NUM> and the baseline code file <NUM> from among the plurality of code files stored on the computer device <NUM> for comparison in the difference view mode <NUM>.

As another example, when the user initially opens a code file <NUM> handled by the code file manager <NUM>, an initial state of the code file <NUM> may be saved temporarily in memory. The initial state of the code file <NUM> may be presented to the user in the editor window <NUM>. The processor <NUM> may be further configured to detect that the user has previously edited or recently changed the code file <NUM> from its initial state <NUM> when the code file <NUM> was opened to an edited code file <NUM>. Upon detecting the change, the processor <NUM> may be configured to toggle the editor window <NUM> presenting the code file <NUM> into the difference view mode <NUM>. In this example, the baseline code file <NUM> is an initial state <NUM> of a code file <NUM> opened via the IDE <NUM>, and the code file <NUM> includes one or more code changes from the initial state <NUM> of the code file <NUM>. The code file <NUM> used in the difference view mode <NUM> may be updated in real-time as the user edits and changes code instructions <NUM> and non-instruction portions <NUM> of the code file <NUM>. An updated difference <NUM> between the baseline code file <NUM> (e.g. the initial state <NUM> of the code file <NUM>) and a current state of the code file <NUM> (e.g. edited code file <NUM>) may be determined and emphasized in the editor window <NUM>.

<FIG> illustrates an example IDE executed by the processor <NUM> of the computer device <NUM> that includes a client side of a version control system <NUM> configured to manage a plurality of code files <NUM> that includes the code file <NUM>. The version control system <NUM> includes a local repository <NUM> that stores one or more versions <NUM> of the plurality of code files <NUM>. The version control system <NUM> is configured to manage changes and edits to the one or more versions <NUM> of the plurality of code files <NUM>. In one example, the version control system <NUM> may implement a git-based version control. However, it will be appreciated that the version control system <NUM> may implement any suitable type of version control.

As illustrated in <FIG>, a previous version of the code file <NUM> stored by the version control system <NUM> may be selected as the baseline code file <NUM> for the difference view mode <NUM> to be compared to the current version of the code file <NUM>. In one example, the baseline code file <NUM> may be selected from among the one or more versions <NUM> of the plurality of code file <NUM> by the user. In another example, the processor <NUM> may be configured to programmatically select the baseline code file <NUM> when there exists an implied baseline for the code file <NUM>, such as, for example, when the user is initiating a change to version control <NUM> for the plurality of code files <NUM> managed by the version control system <NUM>. In git-based terms, the change to version control <NUM> may include a commit, a pull request, etc. However, it will be appreciated that the processes described with reference to <FIG> may also be applied to other types of version control systems.

In one example, the processor <NUM> may be configured to determine that a user is preparing to make the change to version control <NUM> of the plurality of code files <NUM> via the version control system <NUM>, such as, for example, a commit or pull request. Based on at least detecting the change to version control <NUM>, the processor <NUM> may be configured to open a changed code file of the plurality of code files in the editor window <NUM> in the difference view mode <NUM> to cause the editor window <NUM> to emphasize differences <NUM> between the changed code file of the plurality of code files in the change to version control and a previous version of the changed code file stored via the version control system <NUM>. For example, the processor <NUM> may be configured to programmatically select the previous version <NUM> of the code file <NUM> as the baseline code file <NUM> when the code file <NUM> is opened in the editor window <NUM> in the difference view mode <NUM> in response to determining that the user is preparing to make the change to version control <NUM>. The previous version <NUM> of the code file is implied by the change to version control <NUM> action. That is, the change to version control <NUM>, such as, for example, a commit or pull request, includes one or more changes/edits that will be applied to the previous version of the code file <NUM> to become the code file <NUM>. Thus, the processor <NUM> may be configured to select the previous version of the code file <NUM> as the baseline code file <NUM>, and present the user with the difference <NUM> between the selected baseline code file <NUM> and the code file <NUM>.

In one example, the code file <NUM> may already be opened in the editor window <NUM> while not in the difference view mode <NUM>. In this example, based on at least determining that the user is preparing to make the change to version control <NUM>, the IDE <NUM> may be configured automatically transition the editor window <NUM> into the difference view mode <NUM>, and programmatically select the previous version <NUM> of the code file <NUM> as the baseline code file <NUM> as discussed above. In this manner, when the user is preparing to make the change to version control <NUM>, the IDE <NUM> is configured to toggle on the difference view mode <NUM> for the editor window <NUM> showing the code file <NUM> and present the user with the difference <NUM> between the previous version of the code file <NUM> and the code file <NUM> so that the user may efficiently view the relevant changes and edits of that change to version control <NUM>.

In one example, the change to version control <NUM> may include changes to more than one code file of the plurality of code files <NUM>. Based on detecting the change to version control <NUM>, the processor <NUM> may be configured to determine a filtered list <NUM> of the plurality of code files <NUM> that excludes one or more unchanged code files that are unchanged in the user's change to version control <NUM> of the plurality of code files <NUM>. That is, an example change to version control <NUM> may only include changes to one of the code files of the plurality of code files <NUM>, such as the code file <NUM>, and no changes to the other code files of the plurality of code files <NUM>. The processor <NUM> may be configured to generate a list of the plurality of code files <NUM> and filter the list to exclude the other code files that were not changed in the example change to version control <NUM>. The processor <NUM> may be further configured to present the filtered list <NUM> on the display <NUM> in the difference view mode <NUM> via the GUI <NUM> of the IDE <NUM>. In another example, each of the more than one changed code files may be opened in editor windows <NUM> in the difference view mode <NUM> and compared to their respective baseline code files, such as previous versions of each of those changed code files.

Turning briefly to <FIG>, an example GUI <NUM> for the IDE <NUM> is illustrated. As shown, the user may prepare a change to version control <NUM> via a version control GUI <NUM> element of the example GUI <NUM>. Using the version control GUI <NUM>, the user may prepare one or more commits, which each include changes to one or more of the plurality of code files <NUM>. In the illustrated example, the selected commit includes changes to the code file <NUM>. Based on the user selected of that commit, the processor <NUM> may be configured to determine the filtered list <NUM> that excludes the other unchanged code files of the plurality of code files <NUM>. In this example, the plurality of code files <NUM> may include a second code file, a third code file, etc., that were not changed in the selected change to version control <NUM>, and are thus excluded from the illustrated filtered list <NUM>. The determined filtered list <NUM> is presented on the display <NUM> via the GUI <NUM> of the IDE <NUM>. The user may then select one of the code files in the filtered list <NUM> to review the relevant changes. It should be appreciated that the code files may also be opened via other means and presented in the editor window <NUM> in the difference view mode <NUM> for review by the user. For example, the code files may be opened in response to a detected debugging event such as an exception or breakpoint, in response to a result of a symbolic lookup, etc..

In this illustrated example, the user selects the code file <NUM>. As discussed previously, the change to version control <NUM> includes an implied baseline for the changed code files. Thus, the processor <NUM> may be configured to select the previous version of the code file <NUM> as the baseline code file, and open the code file <NUM> in the editor window <NUM> in the difference view mode <NUM>. After opening the code file <NUM> in the difference view mode <NUM>, the processor <NUM> may be configured to display the baseline code file <NUM>, the code file <NUM>, and emphasize the differences <NUM> between the baseline code file <NUM> and the code file <NUM>. As discussed above, the user may further apply one or more code development tools <NUM> to the code file, such as, for example, the integrated debugging tool 26A, the breakpoint tool 26B, etc., to test the changes included in the selected change to version control <NUM>. In this manner, the user may efficiently review the relevant changes before finalizing the change to version control <NUM>.

Turning back to <FIG>, the client-side of the version control system <NUM> may be configured to communicate with a remote repository for the version control system <NUM>. The remote repository for the version control system <NUM> may be configured to maintain a master version of the plurality of code files <NUM> that may be pulled by a plurality of computer devices of a plurality of developers that are collaborating to develop the plurality of code files <NUM>. For example, a second computer device <NUM> implementing the IDE <NUM> may also communicate with the remote repository for the version control system <NUM>. The computer device <NUM> and the second computer device <NUM> may be configured to send changes to version control <NUM> to the remote repository, which may then be merged with the master version of the plurality of code files <NUM> after being accepted by an administrator user of the remote repository <NUM>.

For example, after the user has prepared and reviewed their change to version control <NUM>, the user may generate a pull request via their client side of the version control system <NUM>. The pull request may push the one or more changed code files (e.g. code file <NUM>) to the remote repository <NUM>, and request to merge the change to version control <NUM> with the master version of the plurality of code files <NUM>.

On the other hand, the user of the computer device <NUM> may review changes to version control <NUM> prepared by other users and pushed to the remote repository <NUM>. For example, the change to version control <NUM> of the plurality of code files <NUM> may be made by a user of the second computer device <NUM>. The user of the second computer device <NUM> may prepare a pull request for the change to version control <NUM>, which will push the changed code files of the plurality of code files <NUM> to the remote repository <NUM>. The processor <NUM> of the computer device <NUM> may be configured to receive a notification for the pull request of the second computer device <NUM>. The processor <NUM> may then pull the one or more changed code files included in the change to version control <NUM> from the remote repository. The processor <NUM> may then determine the filtered list <NUM> of the plurality of code files <NUM> that excludes one or more unchanged code files that are unchanged in the user's change to version control <NUM> of the plurality of code files <NUM>, and present the filtered list <NUM> to the user via the GUI <NUM> of the IDE <NUM>. The user of the computer device <NUM> may then select one of the changed code files from the filtered list <NUM> for review. Based on the user selecting one of the changed code files, the selected code file may be opened in the editor window <NUM> in the difference view mode <NUM>. As another example, code files of the second user's change to version control <NUM> may be opened in the difference view mode <NUM> in response to a debugging event generated by the integrated debugging tool <NUM> while running the code files, in response to a result of the symbolic lookup tool 26C, etc., as described above.

In one example, the user selects the code file <NUM> from the filtered list <NUM> for review. As discussed previously, the change to version control <NUM> initiated by the second computer device <NUM> includes an implied baseline for each of the changed code files. Thus, the processor <NUM> may be configured to select the previous version of the code file <NUM> as the baseline code file <NUM>, and opens the selected code file <NUM> in an editor window <NUM> in the difference view mode <NUM>. The code file from the change to version control <NUM> selected by the user and the implied baseline code file for the selected code file are presented to the user via the editor window <NUM>, and the differences <NUM> may be emphasized as discussed herein. In this manner, the user of the computer device <NUM> may efficiently review the relevant changes to each code file in the change to version control <NUM> initiated by the user of the second computer device <NUM>. The user of the computer device <NUM> may then accept the change to version control <NUM> after review, and cause the remote repository <NUM> for the version control system to merge the change to version control <NUM> with the master version of the plurality of code files <NUM> stored on the remote repository <NUM>.

<FIG> shows a flowchart of a computer-implemented method <NUM>. The method <NUM> may be implemented by the computer device <NUM> of <FIG>. At <NUM>, the method <NUM> may include executing an integrated development environment that includes code development tools. <FIG> illustrated an example integrated development environment <NUM> that includes a plurality of different code development tools <NUM>, such as, for example, an integrated debugging tool 26A, a breakpoint tool 26B, a symbolic lookup tool 26C, an intelligent code completion tool 26D, and other development tools 26E.

At <NUM>, the method <NUM> may include outputting for display on the display an editor window of the integrated development environment configured to present a code file and real-time mark-up of the code file, wherein the editor window includes a difference view mode that causes the editor window to emphasize a difference between the code file and a baseline code file. <FIG> illustrates an example GUI <NUM> including the editor window <NUM>. The editor window <NUM> may be configured to display each of the code instructions <NUM> of the code file <NUM>. The editor window <NUM> may also be configured to display GUI elements for organizing the displayed code instructions <NUM>, such as, for example, line numbers. The editor window <NUM> may also display real-time mark-up of the code file <NUM> as the user edits/changes the code instructions <NUM>, adds/deletes comments, or otherwise edits the code file <NUM>. For example, the editor window <NUM> may indicate one or more syntax errors in the code file <NUM>.

In one example, the code file <NUM> may already be opened in the editor window <NUM> while not in the difference view mode <NUM>. In this example, the difference view mode for the editor window may be toggled on in response to a user input, such as an input to compare two or more code files. As another example, the difference view mode may be toggled on in response to a new user change or edit to an opened code file. In this example, the baseline code file is an initial state of a code file opened via the integrated development environment, and the code file includes one or more code changes from the initial state of the code file.

In another example, the code file may not yet be opened in the editor window <NUM>. In this example, the method <NUM> may include opening the code file in the difference view mode via steps <NUM> and <NUM>. At <NUM>, the method <NUM> may include detecting a debugging event generated for the code file by the integrated debugging tool. The debugging event may include an exception thrown by the integrated debugging tool, a breakpoint event of a breakpoint set via a breakpoint tool 26B, etc..

At <NUM>, the method <NUM> may include opening the code file in the editor window in the difference view mode based on at least detecting the debugging event. For example, based on at least detecting that an exception was thrown in the code file <NUM> while running a plurality of code files that includes the code file <NUM>, the method <NUM> may open the code file <NUM> in the difference view mode. As another example, based on at least detecting that a breakpoint has been reached while running the code file <NUM>, the method <NUM> may open the code file <NUM> in the difference view mode. It should be appreciated that the code file <NUM> may be opened in the difference view mode in response to other events. For example, if a result of the symbolic lookup tool 26C is located in the code file <NUM>, then the method <NUM> may open the code file <NUM> in the difference view mode.

At <NUM>, the method <NUM> may include programmatically selecting the previous version of the code file as the baseline code file when the code file is opened in the editor window in the difference view mode. The previous version of the code file may be selected as the baseline code file in response to a user action that includes an implied baseline. In one example, the integrated development environment further includes a version control system configured for managing a plurality of code files that includes the code file. One example version control system may be a git-based version control. However, it will be appreciated that other types of version controls may be utilized for method <NUM>. When the integrated development environment detects that the user is preparing a change to version control for the plurality of code files, the method <NUM> may open a changed code file, such as the code file <NUM>, in the editor window <NUM> in the difference view mode <NUM>, and may select the previous version of the code file as the baseline code file. In this example, the baseline code file is a previous version of the code file stored by the version control system. The GUI <NUM> may display both the code file and the baseline code file, and emphasize the differences between the code file and the baseline code file.

At <NUM>, the method <NUM> may include performing a function of one of the code development tools on the code file and presenting a result of the function in the editor window while in the difference view mode. In one example, the one of the code development tools includes an integrated debugging tool configured for throwing exceptions within the editor window while in the difference view mode. The integrated debugging tool 26A may include other functions. In one example, the integrated debugging tool 26A may be configured to output debugging data <NUM> that may be presented via the GUI <NUM> of the IDE <NUM>. The debugging data <NUM> may include data regarding the call stack of the running code file <NUM>. It will be appreciated that other suitable debugging data <NUM> may also be output and displayed via the GUI <NUM> concurrently with the differences <NUM> between the code file <NUM> and the baseline code file <NUM>. The differences <NUM> of the difference view mode <NUM> are concurrently shown with the thrown exceptions <NUM> and other results of the integrated debugging tool in the editor window <NUM>. In this manner, the user may concurrently view both the differences <NUM> and the results of the code development tool <NUM> without having to tab between multiple window tabs.

In another example, the one of the code development tools includes a breakpoint tool configured for halting execution of the code file at a specified line of code. <FIG> illustrates an example breakpoint <NUM> set by the user of the computer device <NUM>. The user may enter a user input via the input device suite <NUM> to set the breakpoint <NUM>, such as, for example, clicking a breakpoint GUI element, pressing a breakpoint hotkey, etc. The functions of other development tools <NUM> may also be performed on the code file <NUM>, and the results presented via the GUI <NUM>.

While performing the function of one of the code development tools at step <NUM>, the method <NUM> may be configured to open one or more code files in the editor window <NUM> in the difference view mode <NUM> in response to an event of one of the code development tools. For example, a debugging event such as an exception or breakpoint event, a result of a symbolic lookup, etc..

At <NUM>, the method <NUM> may include determining that a user is preparing to make a change to version control of the plurality of code files via the version control system. In a git-based version control system, the changes to version control may include commits, pull requests, etc. However, it will be appreciated that the method <NUM> may also be applied to other types of version control systems.

At <NUM>, the method <NUM> may include determining a filtered list of the plurality of code files that excludes one or more unchanged code files that are unchanged in the user's change to version control of the plurality of code files. For example, the change to version control <NUM> may only include changes to one of the code files of the plurality of code files <NUM>, such as the code file <NUM>, and no changes to the other code files of the plurality of code files <NUM>. The method <NUM> may include generating a list of the plurality of code files <NUM> and filter the list to exclude the other code files that were not changed in the example change to version control <NUM>.

At <NUM>, the method <NUM> may include presenting the filtered list on the display in the difference view mode. The filtered list may be shown to the user view the GUI <NUM> of the integrated development environment <NUM>. If the user selects one of the changed code files in the filtered list, the method <NUM> may include opening the selected code file in an editor window in the difference view mode, and emphasizing the differences between the previous version of the selected code file and the selected code file.

Computing system <NUM> may, for example, embody the computer device <NUM> of <FIG>, or may instead embody some other computing system. Computing system <NUM> may take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices, and wearable computing devices such as smart wristwatches and head mounted augmented/virtual reality devices.

Computing system <NUM> includes a logic processor <NUM>, volatile memory <NUM>, and a non-volatile storage device <NUM>.

The logic processor <NUM> may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logic processor <NUM> may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. Individual components of the logic processor <NUM> optionally may be distributed among two or more separate devices, which may be remotely located and/or configured for coordinated processing. In such a case, these virtualized aspects may be run on different physical logic processors of various different machines.

The term "program" may be used to describe an aspect of computing system <NUM> implemented to perform a particular function. In some cases, a program may be instantiated via logic processor <NUM> executing instructions held by non-volatile storage device <NUM>, using portions of volatile memory <NUM>. It will be understood that different programs may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same program may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The term "program" encompasses individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc..

As the herein described methods and processes change the data held by the non-volatile storage device <NUM>, and thus transform the state of the non-volatile storage device <NUM>, the state of display subsystem <NUM> may likewise be transformed to visually represent changes in the underlying data.

In some embodiments, the input subsystem <NUM> may comprise or interface with selected natural user input (NUI) componentry. Example NUI componentry may include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection, gaze detection, and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity; and/or any other suitable sensor.

As non-limiting examples, the communication subsystem <NUM> may be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network. In some embodiments, the communication subsystem <NUM> may allow computing system <NUM> to send and/or receive messages to and/or from other devices via a network such as the Internet.

Claim 1:
A computer device (<NUM>) comprising:
a display (<NUM>); and
a processor (<NUM>) configured to:
execute (<NUM>) an integrated development environment (<NUM>) that includes code development tools (<NUM>), wherein one of the code development tools includes an integrated debugging tool (26A) configured to generate debugging events;
output (<NUM>) for display on the display an editor window (<NUM>) of the integrated development environment configured to present a code file (<NUM>) and real-time mark-up of the code file, wherein the editor window includes a difference view mode (<NUM>) that causes the editor window to emphasize a difference (<NUM>) between the code file and a baseline code file (<NUM>);
detect (<NUM>) a debugging event generated for the code file by the integrated debugging tool;
open (<NUM>) the code file in the editor window in the difference view mode based on at least detecting the debugging event;
programmatically select (<NUM>) the previous version of the code file as the baseline code file when the code file is opened in the editor window in the difference view mode; and
perform (<NUM>) a function of one of the code development tools (<NUM>) on the code file and present a result of the function in the editor window while in the difference view mode.