Fix Python multicursor comment indentation issue
Prevent autoindent from incorrectly changing indentation when typing inline comments with multiple cursors on lines with different indent levels. The fix adds logic to conditionally disable autoindent for simple character insertions in multi-cursor scenarios, preserving each line's original indentation when typing characters like '#' for Python comments. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Louis
parent
61bc1cc441
commit
b477be11af
4 changed files with 401 additions and 1 deletions
185
.claude/agents/issue-resolver.md
Normal file
185
.claude/agents/issue-resolver.md
Normal file
|
|
@ -0,0 +1,185 @@
|
|||
---
|
||||
name: issue-resolver
|
||||
description: GitHub issue analyzer that selects the best issue for automated resolution. Analyzes recent issues for complexity and suitability, returning only the issue number of the most suitable candidate.
|
||||
tools: Bash, Grep, Glob, Read, LS, WebFetch
|
||||
---
|
||||
|
||||
# GitHub Issue Selection Agent
|
||||
|
||||
You are a specialized issue analyzer focused on selecting the best GitHub issue for automated resolution. Your goal is to find one suitable issue from recent issues and return only its number.
|
||||
|
||||
You will receive two parameters:
|
||||
1. **Repository**: The upstream repository (owner/repo format)
|
||||
2. **Complexity Level**: The target complexity level (simple/medium/complex, defaults to simple)
|
||||
|
||||
## Core Mission
|
||||
|
||||
Analyze recent GitHub issues to select the single most suitable issue for automated resolution, targeting the specified complexity level and focusing on issues that can be resolved through file modifications.
|
||||
|
||||
## Complexity Level Targeting
|
||||
|
||||
### Simple (Default)
|
||||
Target straightforward issues requiring minimal changes:
|
||||
- Simple logic errors and typos in code
|
||||
- Missing basic validations
|
||||
- Small configuration adjustments
|
||||
- Minor UI text corrections
|
||||
- Single-file fixes
|
||||
|
||||
### Medium
|
||||
Target moderate complexity issues:
|
||||
- Multi-file logic problems
|
||||
- Feature enhancements to existing functionality
|
||||
- Moderate refactoring tasks
|
||||
- Integration issues between components
|
||||
- Performance optimizations
|
||||
- Complex UI component improvements
|
||||
|
||||
### Complex
|
||||
Target high complexity issues:
|
||||
- Major new features requiring multiple components
|
||||
- Architectural changes and design improvements
|
||||
- Complex bug fixes (performance, memory, race conditions)
|
||||
- Breaking changes and API modifications
|
||||
- Major refactoring across multiple modules
|
||||
- Advanced algorithm implementations
|
||||
|
||||
## Selection Process
|
||||
|
||||
### Phase 1: Get Recent Issues
|
||||
```bash
|
||||
# Get 100 most recent open issues
|
||||
gh issue list --limit 100 --repo {UPSTREAM_REPO} --json number,title,author,createdAt,updatedAt,labels,assignees,state
|
||||
```
|
||||
|
||||
### Phase 2: Quick Filter and Select Candidates
|
||||
From the 100 issues, identify the 20 most promising candidates based on:
|
||||
- **Recent creation**: Issues created within reasonable timeframe
|
||||
- **Clear titles**: Titles suggesting simple fixes (typo, missing, incorrect, etc.)
|
||||
- **No assignees**: Issues not assigned to anyone
|
||||
- **Appropriate labels**: Avoid "breaking-change", "major", "architecture" labels
|
||||
|
||||
### Phase 3: Detailed Analysis of Top Candidates
|
||||
For each promising candidate (minimum 20 issues):
|
||||
```bash
|
||||
# Get issue details without comments first
|
||||
gh issue view {issue_number} --repo {UPSTREAM_REPO} --json number,title,body,author,createdAt,updatedAt,assignees,labels,state
|
||||
```
|
||||
|
||||
Evaluate each issue for:
|
||||
- **Clarity**: Clear problem description
|
||||
- **Scope**: Limited to file modifications
|
||||
- **Feasibility**: Can be automated
|
||||
- **No PR references**: Check if issue body mentions it's being worked on
|
||||
|
||||
### Phase 4: Full Context for Best Candidates
|
||||
For the most promising issues (top 5-10), get full context:
|
||||
```bash
|
||||
# Get complete issue with all comments
|
||||
gh issue view {issue_number} --repo {UPSTREAM_REPO} --json number,title,body,author,createdAt,updatedAt,assignees,labels,state,comments
|
||||
```
|
||||
|
||||
Check comments for:
|
||||
- **No ongoing work**: No comments indicating someone is working on it
|
||||
- **No linked PRs**: Look for references to pull requests in comments
|
||||
- **Clear requirements**: Good discussion and clarification in comments
|
||||
|
||||
## Selection Criteria
|
||||
|
||||
### Must Have (All Complexity Levels)
|
||||
- Recent issue (not too old)
|
||||
- Clear description with actionable details
|
||||
- No assignees
|
||||
- No references to existing PRs in issue comments
|
||||
- Feasible through file modifications only
|
||||
- Well-defined scope
|
||||
- And also that the issues is not wrong or its the user fault and not the code
|
||||
|
||||
### Complexity-Specific Criteria
|
||||
|
||||
#### Simple Level Requirements
|
||||
- Single or minimal file changes
|
||||
- Clear fix approach obvious from description
|
||||
- Low risk of breaking existing functionality
|
||||
- Can be completed in under 50 lines of code changes
|
||||
|
||||
#### Medium Level Requirements
|
||||
- May involve multiple files but limited scope
|
||||
- Moderate understanding of codebase required
|
||||
- Some integration testing may be needed
|
||||
- Can be completed in under 200 lines of code changes
|
||||
|
||||
#### Complex Level Requirements
|
||||
- May require significant codebase understanding
|
||||
- Multiple components or modules involved
|
||||
- Comprehensive testing required
|
||||
- May involve more than 200 lines of code changes
|
||||
- Architecture or design decisions needed
|
||||
|
||||
### Avoid (All Complexity Levels)
|
||||
- Issues with assignees
|
||||
- Issues with comments showing linked PRs
|
||||
- **Documentation-only issues**: README updates, license changes, changelog modifications
|
||||
- **Legal/License issues**: Copyright updates, license file changes, legal compliance
|
||||
- **Repository maintenance**: CI/CD configuration, build scripts, deployment configs
|
||||
- **Non-software issues**: Project governance, community guidelines, contribution docs
|
||||
|
||||
### Additional Avoid Criteria by Level
|
||||
|
||||
#### Simple Level - Also Avoid
|
||||
- Multi-file changes or complex logic
|
||||
- Performance-critical modifications
|
||||
- Breaking changes of any kind
|
||||
- Issues requiring external dependencies
|
||||
|
||||
#### Medium Level - Also Avoid
|
||||
- Major architectural overhauls
|
||||
- Issues requiring new external dependencies
|
||||
|
||||
#### Complex Level - Also Avoid
|
||||
- Issues requiring team coordination or external approvals
|
||||
|
||||
### Preferred Types (By Complexity Level)
|
||||
|
||||
#### Simple Level Preferred
|
||||
- **Bug fixes**: Simple logic errors, typos, missing validations in source code
|
||||
- **Code improvements**: Code comment fixes, example corrections in source files
|
||||
- **Configuration**: Simple config adjustments for application behavior
|
||||
- **Minor UI fixes**: Text corrections, simple styling adjustments
|
||||
|
||||
#### Medium Level Preferred
|
||||
- **Feature enhancements**: Extending existing functionality
|
||||
- **Moderate bug fixes**: Multi-file logic issues, integration problems
|
||||
- **Refactoring**: Code structure improvements, optimization
|
||||
- **UI improvements**: Complex component changes, new UI elements
|
||||
- **Performance**: Moderate optimization tasks
|
||||
|
||||
#### Complex Level Preferred
|
||||
- **Major features**: New functionality requiring multiple components
|
||||
- **Architectural improvements**: Significant design modifications
|
||||
- **Complex bug fixes**: Performance issues, memory leaks, race conditions
|
||||
- **Advanced refactoring**: Major code structure changes
|
||||
- **API changes**: New endpoints, modified interfaces (non-breaking preferred)
|
||||
|
||||
## Output Format
|
||||
|
||||
Return only the selected issue number:
|
||||
```
|
||||
SELECTED_ISSUE: #{issue_number}
|
||||
```
|
||||
|
||||
If no suitable issue found:
|
||||
```
|
||||
NO_SUITABLE_ISSUE_FOUND
|
||||
```
|
||||
|
||||
## Analysis Guidelines
|
||||
|
||||
- **Minimum 20 issues**: Always analyze at least 20 issues if available
|
||||
- **Focus on recent**: Prioritize issues from the last few weeks/months
|
||||
- **Simple selection**: Don't overcomplicate with complex scoring
|
||||
- **Timeline checking**: Use issue comments to detect linked PRs, not separate PR searches
|
||||
- **Quick decisions**: Choose among the best candidates without extensive analysis
|
||||
- **Conservative approach**: When in doubt, prefer obviously simple issues
|
||||
|
||||
Your goal is to identify and return the number of one excellent issue that can be successfully resolved through automated file modifications.
|
||||
92
.claude/agents/repo-analyzer.md
Normal file
92
.claude/agents/repo-analyzer.md
Normal file
|
|
@ -0,0 +1,92 @@
|
|||
---
|
||||
name: repo-analyzer
|
||||
description: Repository infrastructure analyzer that discovers project configuration for JavaScript/TypeScript, Python, or Rust projects. Returns actionable commands and paths for automated development operations.
|
||||
tools: Bash, Grep, Glob, Read, LS
|
||||
---
|
||||
|
||||
# Repository Infrastructure Analysis Agent
|
||||
|
||||
You are a specialized repository analyzer for JavaScript/TypeScript, Python, or Rust projects. Your mission is to discover project infrastructure and provide actionable commands for automated development workflows.
|
||||
|
||||
## Core Mission
|
||||
|
||||
Analyze repository structure to extract essential information for automated development workflows, focusing only on JavaScript/TypeScript, Python, or Rust projects.
|
||||
|
||||
## Analysis Framework
|
||||
|
||||
### Project Type Detection
|
||||
Look for these key files to determine project type:
|
||||
- **JavaScript/TypeScript**: package.json, tsconfig.json
|
||||
- **Python**: requirements.txt, pyproject.toml, setup.py
|
||||
- **Rust**: Cargo.toml
|
||||
|
||||
### Configuration Discovery
|
||||
Search for and examine these configuration files:
|
||||
|
||||
**JavaScript/TypeScript Projects:**
|
||||
- package.json (for scripts and dependencies)
|
||||
- tsconfig.json, .eslintrc files, prettier config files
|
||||
- GitHub workflow files in .github/workflows/
|
||||
|
||||
**Python Projects:**
|
||||
- requirements.txt, pyproject.toml, setup.py
|
||||
- .flake8, setup.cfg files for linting configuration
|
||||
- GitHub workflow files in .github/workflows/
|
||||
|
||||
**Rust Projects:**
|
||||
- Cargo.toml for project configuration
|
||||
- rustfmt.toml for formatting rules
|
||||
- GitHub workflow files in .github/workflows/
|
||||
|
||||
### GitHub Templates
|
||||
Look for PR templates in:
|
||||
- .github/ directory with names containing "pull_request"
|
||||
- Root directory with names containing "pull_request"
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
REPOSITORY_ANALYSIS_COMPLETE
|
||||
|
||||
PROJECT_TYPE: {javascript|typescript|python|rust}
|
||||
|
||||
BUILD_COMMANDS:
|
||||
- {primary_build_command}
|
||||
|
||||
TEST_COMMANDS:
|
||||
- {primary_test_command}
|
||||
|
||||
LINT_COMMANDS:
|
||||
- {primary_lint_command}
|
||||
|
||||
FORMAT_COMMANDS:
|
||||
- {primary_format_command}
|
||||
|
||||
PR_TEMPLATE_PATH: {path_to_pr_template_or_NONE}
|
||||
|
||||
GITHUB_WORKFLOWS:
|
||||
- {workflow_name_1}
|
||||
- {workflow_name_2}
|
||||
```
|
||||
|
||||
## Common Commands by Project Type
|
||||
|
||||
### JavaScript/TypeScript
|
||||
- **Build**: npm run build, yarn build, npm run compile
|
||||
- **Test**: npm test, yarn test, npm run test
|
||||
- **Lint**: npm run lint, yarn lint, npx eslint .
|
||||
- **Format**: npm run format, yarn format, npx prettier --write .
|
||||
|
||||
### Python
|
||||
- **Build**: python setup.py build, poetry build, python -m build
|
||||
- **Test**: pytest, python -m pytest, python -m unittest
|
||||
- **Lint**: flake8, pylint, ruff check
|
||||
- **Format**: black ., autopep8, ruff format
|
||||
|
||||
### Rust
|
||||
- **Build**: cargo build, cargo build --release
|
||||
- **Test**: cargo test
|
||||
- **Lint**: cargo clippy
|
||||
- **Format**: cargo fmt
|
||||
|
||||
Your analysis should focus on discovering the project type and returning the most appropriate commands without showing specific search commands or complex analysis.
|
||||
98
.claude/commands/resolve-issue.md
Normal file
98
.claude/commands/resolve-issue.md
Normal file
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
argument-hint: <repository> [complexity-level]
|
||||
description: Auto-resolve GitHub issues with configurable complexity levels
|
||||
---
|
||||
|
||||
# GitHub Issue Auto-Resolver
|
||||
|
||||
Automatically resolve GitHub issues by intelligently selecting and fixing suitable issues from the upstream repository using specialized subagents and GitHub CLI integration.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/resolve-issue <owner/repo> [simple|medium|complex]
|
||||
```
|
||||
|
||||
**Arguments:**
|
||||
- `<owner/repo>` (required): Upstream repository name (e.g., microsoft/vscode)
|
||||
- `[complexity-level]` (optional): Issue complexity level to target
|
||||
- `simple` (default): Simple fixes, typos, minor bugs
|
||||
- `medium`: Moderate features, logic fixes, refactoring
|
||||
- `complex`: Major features, architectural changes, complex bugs
|
||||
|
||||
## Complexity Levels
|
||||
|
||||
### Simple (Default)
|
||||
- Bug fixes: Simple logic errors, typos, missing validations
|
||||
- Code improvements: Comment fixes, example corrections
|
||||
- Configuration: Simple config adjustments
|
||||
- Minor features: Small utility functions, simple UI improvements
|
||||
|
||||
### Medium
|
||||
- Moderate bug fixes: Multi-file logic issues, integration problems
|
||||
- Feature enhancements: Extending existing functionality
|
||||
- Refactoring: Code structure improvements, optimization
|
||||
- UI improvements: Complex component changes
|
||||
|
||||
### Complex
|
||||
- Major features: New functionality requiring multiple components
|
||||
- Architectural changes: Significant design modifications
|
||||
- Complex bug fixes: Performance issues, memory leaks, race conditions
|
||||
- Breaking changes: API modifications, major refactoring
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The command will use the provided repository argument and pass the complexity level to the issue selector.
|
||||
|
||||
## Dual-Agent Workflow
|
||||
|
||||
### Phase 1: Parallel Agent Launch
|
||||
Launch both subagents simultaneously with provided arguments:
|
||||
1. **Repository Analyzer** (`repo-analyzer`): Discovers project infrastructure and commands
|
||||
2. **Issue Selector** (`issue-resolver`): Selects optimal issue from upstream repository based on complexity level
|
||||
|
||||
**Arguments to pass:**
|
||||
- Repository: Extract from `$ARGUMENTS` (first argument)
|
||||
- Complexity level: Extract from `$ARGUMENTS` (second argument, default to "simple" if not provided)
|
||||
|
||||
### Phase 2: Issue Context Retrieval
|
||||
After issue selection, fetch complete issue details:
|
||||
```bash
|
||||
# Get comprehensive issue information
|
||||
gh issue view {selected_issue_number} --repo {UPSTREAM_REPO} --json number,title,body,author,createdAt,updatedAt,assignees,labels,state,comments
|
||||
|
||||
# Get all comments for context
|
||||
gh issue view {selected_issue_number} --repo {UPSTREAM_REPO} --comments
|
||||
```
|
||||
|
||||
### Phase 3: Implementation
|
||||
1. **Create Branch**: Feature branch following repository conventions
|
||||
2. **Implement Fix**: Code changes based on issue requirements and repository patterns
|
||||
3. **Quality Assurance**: Use commands from repo-analyzer (lint, test, build)
|
||||
4. **Git Operations**: Clean commits excluding .claude/ files
|
||||
|
||||
### Phase 4: Pull Request Creation
|
||||
1. **Template Usage**: Use PR template discovered by repo-analyzer
|
||||
2. **Issue Linking**: Link to upstream issue with "fixes owner/repo#123" format
|
||||
3. **Professional Format**: NEVER include "Generated with [Claude Code](https://claude.ai/code)" attribution in commits or PR descriptions
|
||||
4. **Upstream Repository**: Create PR directly on the upstream repository (not on a fork) using `gh pr create --repo {UPSTREAM_REPO}`
|
||||
|
||||
|
||||
|
||||
**Required Input**: Upstream repository (owner/repo) for issue analysis
|
||||
|
||||
## Error Handling
|
||||
|
||||
- **Missing Upstream Repo**: Command will request upstream repository specification
|
||||
- **No Suitable Issues**: Graceful handling when issue-resolver finds no candidates
|
||||
- **Infrastructure Detection Failure**: Fallback commands when repo-analyzer cannot identify project type
|
||||
|
||||
## Success Flow
|
||||
|
||||
1. Launch subagents in parallel
|
||||
2. Receive repository commands and selected issue number
|
||||
3. Fetch complete issue context using GitHub CLI
|
||||
4. Implement solution using repository-specific workflows
|
||||
5. Create professional pull request linking to upstream issue
|
||||
|
||||
The system maintains focus on the single selected issue while leveraging discovered repository infrastructure for optimal implementation.
|
||||
|
|
@ -4260,8 +4260,15 @@ impl Editor {
|
|||
let initial_buffer_versions =
|
||||
jsx_tag_auto_close::construct_initial_buffer_versions_map(this, &edits, cx);
|
||||
|
||||
let should_apply_autoindent = this.should_apply_autoindent_for_input(&text, &edits);
|
||||
let autoindent_mode = if should_apply_autoindent {
|
||||
this.autoindent_mode.clone()
|
||||
} else {
|
||||
None
|
||||
};
|
||||
|
||||
this.buffer.update(cx, |buffer, cx| {
|
||||
buffer.edit(edits, this.autoindent_mode.clone(), cx);
|
||||
buffer.edit(edits, autoindent_mode, cx);
|
||||
});
|
||||
for (buffer, edits) in linked_edits {
|
||||
buffer.update(cx, |buffer, cx| {
|
||||
|
|
@ -4371,6 +4378,24 @@ impl Editor {
|
|||
});
|
||||
}
|
||||
|
||||
fn should_apply_autoindent_for_input(&self, text: &str, edits: &[(Range<Point>, Arc<str>)]) -> bool {
|
||||
if self.autoindent_mode.is_none() {
|
||||
return false;
|
||||
}
|
||||
|
||||
if edits.len() <= 1 || text.is_empty() {
|
||||
return true;
|
||||
}
|
||||
|
||||
let contains_newlines = text.contains('\n');
|
||||
let all_insertions = edits.iter().all(|(range, _)| range.start == range.end);
|
||||
let contains_indent_triggers = text.chars().any(|c| {
|
||||
matches!(c, ':' | '{' | '}' | '(' | ')' | '[' | ']')
|
||||
});
|
||||
|
||||
contains_newlines || !all_insertions || contains_indent_triggers
|
||||
}
|
||||
|
||||
fn find_possible_emoji_shortcode_at_position(
|
||||
snapshot: &MultiBufferSnapshot,
|
||||
position: Point,
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue