ajaxorg / ajaxorg/ace

Case insensitive matching in one rule affects other rules too

Offen
#4,887 10 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen
bug effort/medium p2
Vorherrschende Sprache
JavaScript
Sterne
27.1k
Forks
5.3k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

### Describe the bug

I have a custom highlighter with the following rules:

1. Case-sensitive matching of `FOO`
2. Case-insensitive matching of `BAR` (`bar`, `Bar`, `BAR`, etc.)

The problem is that the second rule makes the first rule match case insensitive, too.

```js
this.$rules = {
"start" : [ {
token : "keyword",
regex : /FOO/,
caseInsensitive: false // being explicit does not help, nor does re-ordering the rules help
}, {
token : "keyword",
regex : /BAR/,
caseInsensitive: true
} ]
};
```

### Expected Behavior

`foo` should not be highlighted as keyword, the other ones should:

image

Setting `caseInsensitive` to `false` or not setting it at all should make the rule match case sensitively. Setting it to `true` should make the rule - and only this rule - match case insensitively.

### Current Behavior

All tokens get highlighted as keywords:

image

### Reproduction Steps

1. Create a custom `Test` mode, see https://gist.github.com/Simran-B/4bbaf20297587ec9761ee4de9674b33e
2. Run `npm install` in the ace root directory
3. Run `node ./Makefile.dryice.js`
4. Run `node ./static.js`
5. Open `http://10.192.168.29:8888/kitchen-sink.html` in a browser
6. Change the **Mode** to **Test**
7. Enter `foo FOO bar BAR`

### Possible Solution

I'm not sure what causes this behavior, but it's peculiar that explicitly setting `caseInsensitive` to `false` does NOT help. The only workaround right now appears to be to not set `caseInsensitive` and use the following regex for the second rule: `[bB][aA][rR]`

### Additional Information/Context

By default, the `regex` expressions are case sensitive. If I don't set `caseInsensitive: true` in the second rule, I get the following expected behavior:

image

Then I add `caseInsensitive: true` to the second rule and it affects the first rule as well - even if I explicitly set `caseInsensitive: false`.

I originally observed this behavior in v1.2.6 but reproduced it using the latest commit on the master branch.

### Ace Version

bbb5800b4cf56d2996691edc63edc2783e19f427

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.