Rewritten the README

My previous project was rejected multiple times due to suspected AI usage, though I didn’t use AI to generate my README. So this time, I recorded the entire process when writing the README and made a timelapse of it.

Added an Example Ruleset

I’ve added an example ruleset for reviewers and raters (I don’t know what they are named) to test my linting language quickly without writing one themselves.
The program on the screenshot is a rule that flags headings that are not continuous from the previous headings (like jumping from H1 to H3).

Honestly, this language is way more expressive than I first thought. I thought it would be impossible to detect skipping levels, but it could.

Wrote README

I created README.md and added some information to it.
I also added a sample linter program:

for sentence in sentences(doc) (
    length = char_count(doc, sentence)
    words = word_count(doc, sentence)
    has_hedging = or(
        contains(doc, sentence, "I think"),
        contains(doc, sentence, "I believe"),
        contains(doc, sentence, "perhaps"),
        contains(doc, sentence, "probably")
    )

    if and(
        gt(length, 100),
        gt(words, 15),
        has_hedging
    ) (
        sentence
    )
)

Implemented Result Formatting

I’ve implemented the print logic of the lint result. I used owo-colors to colorize the output.

Linting With Custom DSL

I’ve completed implementing my custom language for linting documents, and I added a few more functions to it.
Sample program:

for match in sentences(doc) (
    if gt(char_count(doc, match), 100) (
        match
    )
)

In this language, for and if are statements. This means that they can return values.
for collects non-null values and returns the list of values. if returns the value if it exists, and null if the value is not returned in it or the condition is false.

My plint CLI shows the errors on the position of the returned matches.

Implemented Linting Language

I’ve implement the parser and the interpreter for my custom linting language.
I have some experience making custom language and this is not my first time doing that so it was quite easy and it took no longer than 10 hours to implement this.

Added Commands

I implemented a few more commands:

ruleset check: Check if the ruleset is valid
ruleset create: Create a new ruleset
ruleset edit: Open the ruleset YAML file in the default editor
ruleset list: List all rulesets

group create: Create a new group
group edit: Open the group YAML file in the default editor
group add-set: Add the ruleset to the group
group remove-set: Remove the ruleset from the group
group list: List all groups

Added check command

I added ruleset check command to check if the ruleset is valid.
The error message is not yet implemented so it just shows the error using Debug, but I’ll change it later.

Removed Interactive Editing

You may wonder why I removed it after more than 5 hours of coding. Here’s why.

I wanted to achieve something like this:

Ruleset
> Name: rule-foo-bar
  Authors: Alice
  Description: This is a placeholder description.
  Version: 1
  Edit Rules
  ← Back

I tried inquire and Ratatui to implement this. However, both of them was not suitable for this after all.

inquire

inquire is a very simple crate to ask users some question on CLI.
The main problem was that I could not add multiple fields and let user edit multiple fields in the same screen (like above), which means that the implementation had to be like this:

Select what to edit
> Name
  Authors
  Description
  Version
  Back

and I wanted to avoid this.

Ratatui

Ratatui is a crate to build a “TUI” application in Rust.
It is very powerful, but I found it a bit over-engineered for my use case. Also, it is mainly designed for full-screen terminal application and was not suitable for inline CLI application like mine.

Making a CLI Library Myself

I also tried to make a CLI library myself, but I decided not to do so. (You can find my library repository here.)
I used crossterm and I had to calculate the position of the cursor, characters and I also had to count unicode characters and calculate the widths for them. I thought that this was not worth it, especially because I didn’t have so much time before the summer break ends.

For now, I decided to make edit command just open the default editor and implement other things, and make the CLI after adding all other essential features.

Use inquire for interactive ruleset creation

I added inquire to the dependency and used it to ask the name, the authors, the description and the version of the new ruleset when creating a ruleset.

Conditional linting

I’ve added conditions so that the linter can use the returned value from the checker to determine whether to show an error.
Currently, condition includes eq, neq, gt, gte, lt, lte, and, or, and not.

Implemented Linting & Testing

I added the basic linting logic and I tested if it works.
As you can see in the video, linting works nicely and it successfully returns the matches.

Here’s the example rule set I used in the video:

name: basic-ruleset
description: This is a basic ruleset.
version: 1

rules:
  - id: no-hello
    message: '"hello" is not allowed.'
    severity: error
    checker: std.regex
    args:
        pattern: hello

  - id: invalid-hello
    message: '"helloooo" is not allowed.'
    severity: error
    checker: std.regex
    args:
        pattern: helloooo

Finished Condition enum

I’ve implemented Condition enum used to evaluate the result of the checkers and decide whether to show an error in the ruleset.
Next I’m going to add the YAML loading feature

Checker trait

I initialized the project structure and added basic types & traits. I also added RegexChecker that returns the matches of the given regular expression.