Project 2: Go-To-Line Feature Upgrade

Final Submission Due Date: Tuesday, April 30 @ 11:59PM


Note There is no new GitHub classroom assignment for this project. Please use the same repository as Project 1.
Please do your work for Project 2 in a new branch that you create (do not use the feedback branch or other existing branches).

Checkpoint due Tuesday, April 23 @ 11:59PM

Create a pull request by Tuesday night that includes at the very least a current version of your design document that:

  • Includes some diagrams and explanation of the part of the codebase you will work with
  • A brief discussion on your plan for implementing the requirements.

Motivation

Our marketing team has just conducted extensive user testing of developers that use IDLE. One of the main issues identified by our team involved the Go to line feature found under Edit when the Python Editor Window is open.

IDLE_feature

Users reported being confused about what big meant (whether it meant they should type in the word big or type in a big number). We would like you to update the Go to line popup to fix this issue.

Our competitors, such as VS Code, have an effective implementation of such a feature. When the user sees the popup for Go to line, the maximum allowed input (i.e., the number of lines within a file) is shown to the users.

VS_feature

Task

Specifically, edit the popup to fulfill these requirements:

Required Features

You must implement the following features to receive full credit for this assignment.

  • Show the user their current line number when the Go to Line popup is displayed. See the image of the VSCode feature to see an example.
  • If the user enters a value that is too large (bigger than the total number of lines), a red error message should be shown to users that says Enter a number between 1 and N, inclusive where N is the number of lines in the file.
  • Implement the logic for handling a negative number using reverse indexing. For example, -1 should go to the last line, -2 should be the second to last line, etc. If a user enters a number that is too negative such that it extends past the first line, the error message shown to users should say Negative entries must be between -N and -1, inclusive where N is the number of lines in the file.
  • Change the Go to Line popup such that the popup should show the user the range of values allowed (i.e., show the total number of lines). You can choose the exact wording, but it should mention that a user can enter a number between 1 and N or -N and -1.

Nice-to-have Features

Feel free to also implement these features (and more!) if you would like a bit of extra challenge.

  • Allow entries for the Go to line popup to be formatted like X:Y where X is line number and Y is the column (character) number within that line.
  • Create some custom enhancement to the feature that you think can help us stand out from our competitors! It can be a visual enhancement, an additional input that is accepted, etc.

Submission

In terms of changes to the codebase, please create a folder called Project2 inside the idlelib codebase. Within this folder, you will add two documents.

As you make updates to the codebase, please justify the decisions that you make. You should create a Design Document called design.md where you discuss the potential options for how you could implement these changes and describe why you chose your certain implementation. Keep in mind that we want to adhere to principles of maintainability, readability, and extendibility of our codebase. In this document, you should include a diagram that shows the relationship between the relevant parts of the codebase that implement the Go to line feature. The purpose of the diagram should be to help coworkers understand the code you were working on and how you had to change certain methods/classes.

In addition to the Design Document, please also create a Process Journal called journal.md where you describe your step by step code navigation jourey and code understanding process as best as you can. This should be a relatively detailed description of the approach, such as describing the specific code navigation techniques (search terms used, navigation shortcuts used, etc), debugger breakpoints you used, and more. Try to reflect on how you went about understanding the parts of the codebase that you need to change and how you went about adding the feature. Please describe major obstacles you faced or decisions you had to make as well as how you got unstuck from those obstacles (using Google, StackOverflow, ChatGPT, office hours, discussed with others, etc.).

In addition to these two documents, you will also make any changes to the codebase that you believe are appropriate to implementing the requirements of the task. Same as in Project 1, create a pull request with your submission (the changes to the idlelib codebase as well as your folder called Project2).

In the description of the pull request, please concisely state:

  • What features you have implemented
  • Screenshots of those new features in action