Skip to content

Conversation

@Josbleuet
Copy link

📌 Summary

This pull request extends the file editing tool to include regular expression support, providing more flexible and powerful text manipulation capabilities.

🔍 Related Issues

  • Fixes #

✨ Changes Made

  • Introduces regex-based edits with options for case sensitivity, multiline matching, and dot-all mode.
  • Adds support for limiting the number of replacements in regex edits.
  • Enables specifying a line range to restrict edits within a specific portion of the file.
  • Introduces new EditOperation enum to support Exact or Regex based replacements.

🛠️ Testing Steps

💡 Additional Notes

Adds support for regular expression-based edits to the file editing tool, in addition to exact string matching.
This provides more flexible and powerful text manipulation capabilities.

Introduces options for regex case-insensitivity, multiline matching, dot-all mode, and maximum replacements.
Also adds support for specifying a line range on which to apply edits.

The original `EditOperation` enum is refactored to support both exact and regex edit types.
Tests are added to ensure the new functionality works as expected.
Copy link
Member

@hashemix hashemix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @Josbleuet , thanks for the contribution!

Although line-range editing and regex support are valuable enhancements, they should be addressed in two separate PRs to keep the scope focused.

Furthermore, instead of updating the existing apply_file_edits method, it would be preferable to implement a dedicated edit function and determine which one to use in the tool call depending on the input parameters.

edits: Vec<EditOperation>,
dry_run: Option<bool>,
save_to: Option<&Path>,
line_range: Option<String>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line-range support is a nice enhancement, but it should go in a separate PR as it doesn’t match the current PR’s scope (“Extends file edit tool with regex support”).

On the other hand, instead of updating current apply_file_edits method we better to have a separate edit function, we can decide which one to use in the tool call based on the parameters.

}

/// Parse line range string (e.g., "10-50" or "10:50") and return 0-based indices
fn parse_line_range(&self, range: &str, content: &str) -> ServiceResult<(usize, usize)> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there’s a cleaner way to handle line ranges , so we do not need to parse them.
using two separate numbers would be more straightforward:

like

from_line: Option<usize>, 
to_line: Option<usize>

@hashemix
Copy link
Member

I’ll close this PR for now. Please feel free to create a new one based on this feedback, or reopen this after making the suggested changes.

@hashemix hashemix closed this Oct 31, 2025
@Josbleuet Josbleuet deleted the feat/edit-file branch November 6, 2025 03:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants