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

Every single word in a JSX block is colored in js2-jsx-mode #62

Closed
thblt opened this issue Dec 9, 2018 · 3 comments · Fixed by #95
Closed

Every single word in a JSX block is colored in js2-jsx-mode #62

thblt opened this issue Dec 9, 2018 · 3 comments · Fixed by #95

Comments

@thblt
Copy link

thblt commented Dec 9, 2018

The title says it all, really. JSX blocks are completely colorized, including regular HTML text.
capture du 2018-12-09 16-40-38

The same issue appears in js-jsx-mode

Thanks!

@Hi-Angel
Copy link
Collaborator

Hi-Angel commented Aug 4, 2019

So, FYI, while working on something else, I took a short stub at it, and the reason you see this turned out to be nil here. The reason it's there in the first place is that documentation about variable color-identifiers:modes-alist says:

If the list includes nil, unfontified words will be considered.

As result, every list for every major mode contain nil in particular.

Per my understanding, this cannot result in proper colorizing, what you see should in fact happen with every mode. Maybe @ankurdave could tell more about it…?

@Hi-Angel
Copy link
Collaborator

Hi-Angel commented Aug 4, 2019

To be more specific about how nil is causing it: in the affected mode the color-identifiers:scan-identifiers function calls this part (memq (get-text-property (point) 'face) identifier-faces) for every word. And for every word (get-text-property (point) 'face) returns nil, which is stored as one of the faces for the mode, so the whole expression evaluates to t.

@Hi-Angel
Copy link
Collaborator

Hi-Angel commented Aug 4, 2019

@thblt Yeah, and as a workaround, removing the nil should work.

Hi-Angel added a commit to Hi-Angel/color-identifiers-mode that referenced this issue Jan 19, 2023
`scan-identifiers` isn't the best scan-fn (see also ankurdave#94) as it moves not
just through changed properties. Let's use the cc-mode one, which goes
exclusively through face changes while searching for declared
identifiers.

Fixes: ankurdave#62
Hi-Angel added a commit that referenced this issue Jan 19, 2023
`scan-identifiers` isn't the best scan-fn (see also #94) as it moves not
just through changed properties. Let's use the cc-mode one, which goes
exclusively through face changes while searching for declared
identifiers.

Fixes: #62
Hi-Angel added a commit to Hi-Angel/color-identifiers-mode that referenced this issue Jan 22, 2023
It isn't actually specific to cc-mode, and works in a way similar to the
previous default `scan-identifiers`, except that because it only goes
through places with properties set, it is:

1. more performant due to less motion
2. less likely to introduce wrong coloring as in ankurdave#40 or ankurdave#62

We also rename the function to remove infix `cc-mode` as it isn't (and
never really have been) specific to c-mode.

Fixes: ankurdave#94
Hi-Angel added a commit to Hi-Angel/color-identifiers-mode that referenced this issue Jan 22, 2023
It isn't actually specific to cc-mode, and works in a way similar to the
previous default `scan-identifiers`, except that because it only goes
through places with properties set, it is:

1. more performant due to less motion
2. less likely to introduce wrong coloring as in ankurdave#40 or ankurdave#62

We also rename the function to remove infix `cc-mode` as it isn't (and
never really have been) specific to c-mode.

Fixes: ankurdave#94
Hi-Angel added a commit to Hi-Angel/color-identifiers-mode that referenced this issue Jan 22, 2023
It isn't actually specific to cc-mode, and works in a way similar to the
previous default `scan-identifiers`, except that because it only goes
through places with properties set, it is:

1. more performant due to less motion
2. less likely to introduce wrong coloring as in ankurdave#40 or ankurdave#62

We also rename the function to remove infix `cc-mode` as it isn't (and
never really have been) specific to c-mode.

Fixes: ankurdave#94
Hi-Angel added a commit that referenced this issue Jan 23, 2023
It isn't actually specific to cc-mode, and works in a way similar to the
previous default `scan-identifiers`, except that because it only goes
through places with properties set, it is:

1. more performant due to less motion
2. less likely to introduce wrong coloring as in #40 or #62

We also rename the function to remove infix `cc-mode` as it isn't (and
never really have been) specific to c-mode.

Fixes: #94
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

Successfully merging a pull request may close this issue.

2 participants