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

CSS sometimes doesn't color classes, id's, etc properly #652

Closed
Naatan opened this Issue Oct 2, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@Naatan
Member

Naatan commented Oct 2, 2015

This seems very random and there are a lot of different scenario's that I've come across, happens in CSS, LESS and SCSS, but mostly the latter 2.

I have found one use-case that I am able to reproduce fairly consistently (still not 100% consistent, more like 70%);

Write out the following in Komodo (do not copy it)

foobar {
    .foo
    {

    }
}

Then put your cursor on .foo and press backspace, it will now color properly.

Note the problem does not occur when I write it out like this:

foobar {
    .foo {

    }
}

My hope is that fixing this issue will also fix similar css issues.

@Naatan Naatan added the Type: Bug label Oct 2, 2015

@Naatan Naatan added this to the 9.3 milestone Oct 2, 2015

@cdcmicro

This comment has been minimized.

cdcmicro commented Oct 3, 2015

FWIW, I saw similar behavior recently with IDE 9.2 on Win7 x64 with SCSS. I was busy and dismissed it at the time.

I always write in the second form. This was coming back to a SCSS file after closing IDE and starting fresh the next day. I think mine was something like:

div.foo {
    & #bar {
    }
}

Seemed like backspacing-out and re-typing the space between '&' and '#bar' re-colored it and the code below it.

@Naatan

This comment has been minimized.

Member

Naatan commented Oct 3, 2015

Yep, it's an old bug that I've never found reliable steps to reproduce for, until now ..

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 13, 2015

In this case, .whatever on a single line in Less is ambiguous, as it could be followed by at least '(' or '{'. Therefore the '{' is required to disambiguate .whatever to be a class name. Since Scintilla only asks the lexer to style starting at the current line, once you've inserted a newline on the previous line, .whatever is left in an unresolved state and Scintilla starts styling at '{'.

This will be tricky to resolve without affecting performance too much.

@mitchell-as mitchell-as modified the milestones: 9.3.1, 9.3 Oct 13, 2015

@Naatan

This comment has been minimized.

Member

Naatan commented Oct 14, 2015

Unfortunately it's not an uncommon coding style and one we'll want to support :\ What are the implications?

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 14, 2015

We'll probably have to add some logic before each styling event that looks for a '{' that starts the line and if it exists, re-style starting at the previous line. This logic would be run during each styling event (basically, every keypress). The lexer is quite complex though (written by ActiveState), and I'll have to investigate further when I have some time.

@Naatan

This comment has been minimized.

Member

Naatan commented Oct 14, 2015

Alright, thanks for explaining :) Can a lexer be smart enough to only trigger on certain keypresses? eg. enter (new line).

@mitchell-as

This comment has been minimized.

Member

mitchell-as commented Oct 14, 2015

No, sadly. Any text inserted must be styled, so the lexer is called upon for all insertions.

@Naatan Naatan modified the milestones: 9.3.1, 9.4 Nov 4, 2015

@Naatan Naatan modified the milestones: 9.4, 10.0 Nov 13, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment