Struct MD055TablePipeStyle 

pub struct MD055TablePipeStyle { /* private fields */ }

Rule MD055: Table pipe style

See docs/md055.md for full documentation, configuration, and examples.

This rule enforces consistent use of leading and trailing pipe characters in Markdown tables, which improves readability and ensures uniform document styling.

Purpose

• Consistency: Ensures uniform table formatting throughout documents
• Readability: Well-formatted tables are easier to read and understand
• Maintainability: Consistent table syntax makes documents easier to maintain
• Compatibility: Some Markdown processors handle different table styles differently

Configuration Options

The rule supports the following configuration options:

MD055:
  style: "consistent"  # Can be "consistent", "leading_and_trailing", or "no_leading_or_trailing"

Style Options

• consistent: All tables must use the same style (default)
• leading_and_trailing: All tables must have both leading and trailing pipes
• no_leading_or_trailing: Tables must not have leading or trailing pipes

Examples

Leading and Trailing Pipes

| Header 1 | Header 2 | Header 3 |
|----------|----------|----------|
| Cell 1   | Cell 2   | Cell 3   |
| Cell 4   | Cell 5   | Cell 6   |

No Leading or Trailing Pipes

Header 1 | Header 2 | Header 3
---------|----------|---------
Cell 1   | Cell 2   | Cell 3
Cell 4   | Cell 5   | Cell 6

Behavior Details

• The rule analyzes each table in the document to determine its pipe style
• With “consistent” style, the first table’s style is used as the standard for all others
• The rule handles both the header row, separator row, and content rows
• Tables inside code blocks are ignored

Fix Behavior

When applying automatic fixes, this rule:

• Adds or removes leading and trailing pipes as needed
• Preserves the content and alignment of table cells
• Maintains proper spacing around pipe characters
• Updates both header and content rows to match the required style

Performance Considerations

The rule includes performance optimizations:

• Efficient table detection with quick checks before detailed analysis
• Smart line-by-line processing to avoid redundant operations
• Optimized string manipulation for pipe character handling

Enforces consistent use of leading and trailing pipe characters in tables

Implementations

impl MD055TablePipeStyle

pub fn new(style: String) -> Self

pub fn from_config_struct(config: MD055Config) -> Self

Trait Implementations

impl Clone for MD055TablePipeStyle

fn clone(&self) -> MD055TablePipeStyle

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for MD055TablePipeStyle

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for MD055TablePipeStyle

fn default() -> MD055TablePipeStyle

Returns the “default value” for a type.

impl Rule for MD055TablePipeStyle

fn name(&self) -> &'static str

fn description(&self) -> &'static str

fn category(&self) -> RuleCategory

Get the category of this rule for selective processing

fn should_skip(&self, ctx: &LintContext<'_>) -> bool

Check if this rule should quickly skip processing based on content

fn check(&self, ctx: &LintContext<'_>) -> LintResult

fn fix(&self, ctx: &LintContext<'_>) -> Result<String, LintError>

fn as_any(&self) -> &dyn Any

fn default_config_section(&self) -> Option<(String, Value)>

Returns the rule name and default config table if the rule has config. If a rule implements this, it MUST be defined on the impl Rule for ... block, not just the inherent impl.

fn config_schema(&self) -> Option<(String, Value)>

Returns the rule name and every config key the rule accepts, for validation.

fn from_config(config: &Config) -> Box<dyn Rule>

where Self: Sized,

Factory: create a rule from config (if present), or use defaults.

fn skippable_by_category(&self) -> bool

Whether the content-category prefilter may skip this rule.

fn config_aliases(&self) -> Option<HashMap<String, String>>

Returns config key aliases for this rule This allows rules to accept alternative config key names for backwards compatibility

fn polymorphic_config_keys(&self) -> &'static [&'static str]

Returns the list of config keys whose deserializer accepts more than one TOML type (e.g. either a scalar or a list). The schema is built from a serialized default that can only encode one variant, so the validator would reject the alternative form. The registry replaces the schema entry for each listed key with a polymorphic sentinel so type checking is skipped while the key name is still validated. The registry rewrites Rule::config_schema, so default_config_section() keeps returning the clean user-facing default.

fn fix_capability(&self) -> FixCapability

Declares the fix capability of this rule

fn cross_file_scope(&self) -> CrossFileScope

Declares cross-file analysis requirements for this rule

fn contribute_to_index( &self, _ctx: &LintContext<'_>, _file_index: &mut FileIndex, )

Contribute data to the workspace index during linting

fn cross_file_check( &self, _file_path: &Path, _file_index: &FileIndex, _workspace_index: &WorkspaceIndex, ) -> LintResult

Perform cross-file validation after all files have been linted

fn observes_suppressions(&self) -> bool

Whether this rule reports on the inline comments that suppressed warnings

fn check_suppressions( &self, _ctx: &LintContext<'_>, _report: &SuppressionReport, ) -> LintResult

Report on a document’s inline disable comments