You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: implement MD013 line-length rule with comprehensive architecture enhancements
Major changes:
- Implemented MD013 (line-length) rule with configurable limits and exceptions
- Enhanced architecture with single-pass document processing and context caching
- Added comprehensive rules implementation checklist (48 total markdownlint rules)
- Categorized rules into 5 implementation types for optimal development strategy
Key architectural improvements:
- Enhanced Context system with line caching and node-to-line mapping
- Hybrid AST + line processing for optimal performance
- Document-wide state preparation for complex rules
- Single-use contract enforcement for memory safety
Code quality improvements:
- Fixed clippy warnings (or_default, format string inlining)
- Suppressed false-positive recursive parameter warnings
- Added comprehensive documentation and usage examples
Test coverage:
- 75 total tests passing
- Comprehensive MD013 test suite with multiple configuration modes
- Integration tests for CLI error reporting
Documentation:
- Added MD013 rule documentation following project conventions
- Updated CLAUDE.md with complete rules roadmap and architecture analysis
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The goal is to port $ARGEMENTS rule implementation from the original markdownlinter.
2
+
Think hard to create an implementation plan. It must include writing comprehensive unit-tests covering as much as possible combinations of rule's settings as possible. Embrace TDD approach. This means, start with writing minimum set of data structurs needed for a test, refrain from writing actual logic for linting at this stage. When, write unit tests. Confirm they are failing. When keep implementing/refining the logic until tests are green.
3
+
You'd also need to create new samples for that rule in `test-samples` directory, following existing naming conventions.
4
+
Finally, you must validate that the implementation is consistent with markdownlinter. This can be done via running both linters against test samples and when analyzing the output. If any inconsistencies found - you must fix them. Assume markdownlinter is already installed on this machine locally. For any found actual inconsistency, add unit test.
5
+
At the end, copy original rule documentation in `docs/rules`
QuickMark has evolved from a simple node-based traversal to a sophisticated single-pass architecture that efficiently handles different rule types while maintaining exceptional performance. This design is inspired by the original markdownlint's architecture but leverages Rust's performance advantages and tree-sitter's robust parsing.
212
+
213
+
**Rule Type Classification**:
214
+
215
+
Rules are categorized into five types for optimal performance and implementation strategy:
216
+
217
+
-**Line-Based Rules** (e.g., MD013): Operate directly on raw text lines with AST context for configuration
218
+
-**Token-Based Rules** (e.g., MD001, MD003): Work with specific cached AST node types
219
+
-**Document-Wide Rules** (e.g., MD024, MD025): Require full document state analysis
220
+
-**Hybrid Rules** (e.g., MD022): Need both AST analysis and line context for structural spacing
221
+
-**Special Rules** (e.g., MD044): Unique implementation requirements like external dictionaries
222
+
223
+
**Enhanced Context System**:
224
+
225
+
The `Context` provides multiple optimized data views:
226
+
- Raw text lines for line-based analysis
227
+
- Cached filtered AST nodes by type (headings, code blocks, etc.)
228
+
- Configuration-driven rule execution with lazy evaluation
229
+
230
+
**Motivation for Single-Pass Architecture**:
231
+
232
+
1.**Performance**: Avoids multiple document parsing passes that would compromise QuickMark's speed promise
233
+
2.**Memory Efficiency**: Caches commonly-used node types rather than re-filtering AST repeatedly
234
+
3.**Scalability**: Supports complex rules (cross-document validation, word analysis) without architectural changes
235
+
4.**Compatibility**: Maintains the existing rule interface while enabling performance optimizations
236
+
237
+
This architecture allows rules like MD013 to work efficiently with raw text while still having access to AST context for proper configuration handling (e.g., different limits for headings vs. code blocks).
128
238
129
239
### Key Design Patterns
130
240
@@ -138,7 +248,7 @@ quickmark/
138
248
139
249
**Shared Context**: `Rc<Context>` is passed to all rule linters, containing file path and configuration.
140
250
141
-
**AST Traversal**: Uses tree-sitter node iteration with each rule's `feed` method processing nodes.
251
+
**Hybrid AST + Line Processing**: Uses tree-sitter for structural analysis with cached node filtering, plus direct text line access for line-based rules. Rules receive an enhanced context with multiple optimized data views.
142
252
143
253
**Configuration-Driven**: Rule severity and settings are externally configurable via TOML files.
144
254
@@ -175,11 +285,18 @@ quickmark/
175
285
## Adding New Rules
176
286
177
287
1. Create a new rule module in `crates/quickmark_linter/src/rules/`
178
-
2. Implement the `RuleLinter` trait
288
+
2. Implement the `RuleLinter` trait with appropriate `RuleType` classification
179
289
3. Add the rule to `ALL_RULES` in `crates/quickmark_linter/src/rules/mod.rs`
180
290
4. Add any rule-specific configuration to the config structs
181
291
5. Update TOML parsing in `quickmark_config` if needed
182
292
293
+
**Rule Type Guidelines**:
294
+
- Use `RuleType::Line` for rules that primarily analyze text content (line length, whitespace, etc.)
295
+
- Use `RuleType::Token` for rules that analyze document structure (headings, lists, code blocks)
296
+
- Use `RuleType::Document` for rules requiring full document analysis (duplicate headings, cross-references)
297
+
- Use `RuleType::Hybrid` for rules needing both AST nodes and line context (blank line spacing around elements)
298
+
- Use `RuleType::Special` for rules with unique requirements (external dictionaries, complex text analysis)
299
+
183
300
## Adding New Configuration Formats
184
301
185
302
1. Create conversion functions in `quickmark_config`
0 commit comments