🐛 Fix timeout issue with dd command in patch and chaperon buffer
#123
Conversation
- Before this fix, `dor`, `dol`, and `do` mappings were available in operator-pending mode, in addition to normal and visual modes, within the patch buffer. This caused the `dd` command to wait for a key sequence timeout. - This commit removes the operator-pending mode mappings for `dor`, `dol`, and `do`, restricting them to only normal and visual modes. This change addresses the timeout issue when using the `dd` command in the patch buffer.
WalkthroughThe recent updates introduce a new constant Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #123 +/- ##
=======================================
Coverage 58.33% 58.33%
=======================================
Files 17 17
Lines 864 864
Branches 101 101
=======================================
Hits 504 504
Misses 360 360 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (2)
- denops/gin/command/chaperon/command.ts (13 hunks)
- denops/gin/command/patch/command.ts (17 hunks)
Additional comments: 16
denops/gin/command/patch/command.ts (8)
- 131-139: The introduction of the
modesconstant with values["n", "x"]for specifying normal and visual modes is a good practice for ensuring consistency and flexibility in defining modes for mappings. This change effectively addresses the issue by limiting the mappings to the intended modes and should prevent the timeout issue with theddcommand. The syntax and logic appear correct, and the use of the constant enhances maintainability by centralizing the mode definitions.- 149-149: Using the
modesconstant for thedpmapping configuration is consistent with the previous change and maintains the intended restriction to normal and visual modes. This consistency is beneficial for maintainability and clarity in the codebase.- 163-177: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [166-184]
Repeating the use of the
modesconstant in theinitWorktreefunction for both<Plug>(gin-diffput)and<Plug>(gin-diffget)mappings is a good practice. It ensures that the mappings are consistently applied across different parts of the code, adhering to the intended operational modes and contributing to the overall objective of resolving the timeout issue.
- 191-197: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [194-203]
The application of the
modesconstant for thedpanddomappings within theinitWorktreefunction is consistent and maintains the restriction to normal and visual modes. This approach is commendable for its consistency and clarity, ensuring that the mappings are correctly limited to the intended modes.
- 218-224: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [221-230]
The use of the
modesconstant in theinitIndexfunction for the<Plug>(gin-diffget-l)mapping is consistent with the changes made in other parts of the file. This consistency in applying the mode restrictions across different functions is beneficial for maintainability and clarity.
- 236-242: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [239-249]
Applying the
modesconstant for thedolanddomappings within theinitIndexfunction is consistent with the previous changes and maintains the intended restriction to normal and visual modes. This approach enhances the maintainability and clarity of the codebase by ensuring consistent application of mode restrictions.
- 268-274: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [271-281]
The repetition of the
modesconstant usage for the<Plug>(gin-diffput)and<Plug>(gin-diffget-r)mappings in theinitIndexfunction is a good practice. It ensures that the mappings are consistently applied across different parts of the code, adhering to the intended operational modes and contributing to the overall objective of resolving the timeout issue.
- 287-293: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [290-300]
Using the
modesconstant for thedp,dor, anddomappings within theinitIndexfunction is consistent with the changes made in other parts of the file. This consistency in applying the mode restrictions across different functions is beneficial for maintainability and clarity, ensuring that the mappings are correctly limited to the intended modes.denops/gin/command/chaperon/command.ts (8)
- 157-165: The introduction of the
modesconstant with values["n", "x"]for specifying normal and visual modes in theinitTheirsfunction is a good practice for ensuring consistency and flexibility in defining modes for mappings. This change effectively addresses the objective of refining command mappings and should contribute to enhancing the user experience by ensuring that the command operates efficiently without unnecessary delays.- 175-175: Using the
modesconstant for thedpmapping configuration in theinitTheirsfunction is consistent with the previous change and maintains the intended restriction to normal and visual modes. This consistency is beneficial for maintainability and clarity in the codebase.- 192-198: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [195-204]
Repeating the use of the
modesconstant in theinitWorktreefunction for the<Plug>(gin-diffget-l)mapping is a good practice. It ensures that the mappings are consistently applied across different parts of the code, adhering to the intended operational modes and contributing to the overall objective of refining command mappings.
- 210-216: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [213-223]
The application of the
modesconstant for thedolanddomappings within theinitWorktreefunction is consistent with the previous changes and maintains the intended restriction to normal and visual modes. This approach enhances the maintainability and clarity of the codebase by ensuring consistent application of mode restrictions.
- 242-248: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [245-254]
The repetition of the
modesconstant usage for the<Plug>(gin-diffget-r)mapping in theinitWorktreefunction is a good practice. It ensures that the mappings are consistently applied across different parts of the code, adhering to the intended operational modes and contributing to the overall objective of refining command mappings.
- 261-267: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [264-273]
Using the
modesconstant for thedoranddomappings within theinitWorktreefunction is consistent with the changes made in other parts of the file. This consistency in applying the mode restrictions across different functions is beneficial for maintainability and clarity, ensuring that the mappings are correctly limited to the intended modes.
- 290-298: The introduction of the
modesconstant in theinitOursfunction for the<Plug>(gin-diffput)mapping is consistent with the approach taken in other parts of the file. This consistency ensures that the mappings are limited to the intended modes, contributing to the objective of refining command mappings and enhancing the user experience.- 308-308: Using the
modesconstant for thedpmapping configuration in theinitOursfunction is consistent with the previous changes and maintains the intended restriction to normal and visual modes. This consistency is beneficial for maintainability and clarity in the codebase.
|
Thank you! |
dor,dol, anddomappings were available in operator-pending mode in addition to normal and visual modes within the patch buffer. This caused theddcommand to wait for a key sequence timeout.dor,dol, anddo, restricting them to only normal and visual modes. This change addresses the timeout issue when using theddcommand in the patch buffer.Summary by CodeRabbit
modesconstant for greater consistency and flexibility across various commands.