Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation needed to add words #3857

Open
ccoVeille opened this issue Nov 27, 2024 · 4 comments
Open

Documentation needed to add words #3857

ccoVeille opened this issue Nov 27, 2024 · 4 comments

Comments

@ccoVeille
Copy link
Collaborator

Is there a place where you documented the way to add words?

I'm talking about here the special case "dataCenter", sometimes there is a need to use ^, sometimes ~, here it was about using an uppercase C in data center

What would be the way to write a brand that has a dedicated syntax? Like :
Elasticsearch brand that is not elasticseach or ElasticSearch

Originally posted by @ccoVeille in #3846 (comment)

@ccoVeille
Copy link
Collaborator Author

ccoVeille commented Dec 13, 2024

Let's pull out my question from the other PR, and write it here

what would be the syntax to only allow "konami code" ?so konami would be allowed but only followed with code.

Konami is a brand that could be added to brands dictionary.

But "Konami code" is definitely a coding term.

Originally posted by @ccoVeille in #3881 (comment)

You replied to PR author about what it could do with konami as a brand.

My question was more general in fact.

When there are words that only exists together like "foo bar", here the example was "konami code", what would be the syntax for allowing "foo bar" only

@Jason3S
Copy link
Collaborator

Jason3S commented Dec 13, 2024

@ccoVeille,

When there are words that only exists together like "foo bar", here the example was "konami code", what would be the syntax for allowing "foo bar" only

There isn't currently support for checking multiple words separated by a space. It is not an easy problem.

@ccoVeille
Copy link
Collaborator Author

Thanks

I hope that I'll be able to help you to write a documentation by keep asking you questions like this one 🤭

@ccoVeille
Copy link
Collaborator Author

ccoVeille commented Dec 27, 2024

Other information shared in another PR

Another option, is to have everything with leading caps:

`I+` and `*Line*`.

Based upon the `caseSensitive` setting, it can prevent false negatives in normal text:

When writing text and `caseSensitive` is `true`, it will not match against `iline`, only `ILine`. When writing code and `caseSensitive` is `false`, it will match.


Originally posted by @Jason3S in #3920 (comment)

Follow-up with #3937

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants