[FEATURE]: Add directive to disable Codebook LSP on a per-file basis

[Drew-Daniels]

Feature Description

Thanks for codebook! It's been a breeze to use and have really enjoyed using it so far.

Background

I came across #151 and while it similar to what I'm looking for, I am looking for a way to easily disable codebook entirely on a per-file basis without requiring updates to the codebook configuration file.

Use Case

Take my ~/.config/yazi/config.toml file - which has some words unrecognized by codebook.

I can disable codebook on this file by using this configuration in my ~/.config/codebook/codebook.toml

ignore_paths = ["**/yazi/*.toml"]

However, this gets a bit tedious having to update my configuration for every file I don't want codebook to check spelling on, and I would like for an easy way to have it ignore files when it comes across some kind of disable directive.

Proposed Solution

Instead of requiring I update ~/.config/codebook/codebook.toml file to explicitly ignore every file I don't want it to run on - I would like for there to be an easy way to disable codebook on a per-file basis completely every time I open that file.

Ex.):

# codebook disable
# ... etc. ...

Alternative Solutions

No response

Examples

No response

Additional Context

I think the closest analog to this would be the shellcheck directive of disable=all

Ex.):

# shellcheck disable=all

[blopker]

Hey! Thanks for adding this request. I do want to avoid adding comment directives if possible. I don't think it's a great user experience since people will need to read the user manual to learn about them.

However, I've just reworked the LSP initialization options code, and it's now easier to add options. Would an optional Quick Action (where suggestions show up) that added the current file to the codebook.toml file, make this process less painful? Could have an option for the project or global configs.

[Drew-Daniels]

Sure thing, and I can see your point.

I think that might be nicer than the current state, but to be honest I don't know that I personally would like of having a large config file full of file specific paths to ignore - but I think that's just my preference, and maybe others feel a different way about it.

Certainly think what you're suggesting would be more ergonomic than requiring users to manually edit their config to add file paths they want to ignore though so I wouldn't be opposed to that in favor of what's in place today.

[blopker]

Maybe it's just a taste thing. However, I'd hope that many of the files could be ignored with globs. As you pointed out, it's pretty straightforward to ignore all JavaScript files with a **/*.js. This should greatly reduce the length and the number of times the config needs to be edited.

Another quick action I've been thinking of is something like "Add all issues to dictionary", which would clear out all the diagnostics by adding every marked issue to the words dictionary. Although I think the ignore files path is better for this use case of editing config files from various programs.

Anyway, the comment directive request has shown up a few times now, so I may just need to do it 😂. The upfront work is high, but if done right, could be powerful.

[nkxxll]

I'll throw my hat in the ring I just searched for a comment directive to disable the thing for specific markdown files where I don't care about spelling.

If you need a code monkey that helps you get this done. I am happy to help I have no fear to get my hands dirty on that feature 😄.

As always, great project, thank you for your time ❤️

[blopker]

Hey! Thanks for the offer. I am still bearish on adding a comment directive system, but if you want to take a crack at it, I'd love to see an implementation. If it's simple enough and doesn't affect performance greatly, I'm still open to it. Alternatively, if you want to go with the optional quick action route, then I'd be happy to take a PR for that as well.

[nkxxll]

@blopker this can be close because of #178 right?

[blopker]

Yes, thank you for the reminder!