Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1189 LexPython: keywords2: don't highlight sub-identifiers

Bug
closed-fixed
Neil Hodgson
Scintilla (788)
5
2011-08-03
2011-06-23
Todd Whiteman
No

For Python, it's common (in IDLE, Wing editor) to set keywords2 "Highlighted identifiers" to be the builtin identifiers, such as "open", "file", "min", etc... This is good in general, but it breaks down when a keyword2 item is used a sub-identifier, like "myobject.file = 1", as "file" still gets highlighted as style word2.

It makes more sense to only highlight keyword2 items when they are not preceded by a ".". I cannot think of a case where you'd want the sub-identifier styled as word2, so I'm proposing this patch to change it.

Discussion

1 2 > >> (Page 1 of 2)
  • Neil Hodgson
    Neil Hodgson
    2011-06-23

    Committed. Though I'm sure someone won't like it.

     
  • Neil Hodgson
    Neil Hodgson
    2011-06-23

    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-fixed
     
  • Marko Njezic
    Marko Njezic
    2011-07-05

    Instead of enforcing this behavior upon everyone, it should be made optional and controlled by a dedicated property. That way you'll leave up to the users to decide how they want to highlight keywords2.

     
  • Todd Whiteman
    Todd Whiteman
    2011-07-06

    @markonjezic

    What is the use-case for wanting these sub-identifiers highlighted... as I couldn't think of any off-hand?

     
  • Marko Njezic
    Marko Njezic
    2011-07-06

    One use case is if you want to highlight special __*__ names (i.e. object.__doc__, object.__class__, object.__getitem__, object.__setitem__, etc.), which is no longer possible with your patch. And this is just one example, since people can get very creative. The patch enforces your personal preference that assumes that keywords2 are always set to just built-in functions upon everyone else, which is not a very nice thing. Unless an option is added to control this new behavior, the patch is actually a regression in functionality.

     
  • Todd Whiteman
    Todd Whiteman
    2011-07-06

    • status: open-fixed --> open-accepted
     
  • Todd Whiteman
    Todd Whiteman
    2011-07-06

    Yes, that is indeed a valid (and likely common enough) use case.

    I have no problems with making this an optional property - will update with a patch.

     
  • Todd Whiteman
    Todd Whiteman
    2011-07-06

    @Neil - If you don't want another property, just backout the original change - I can patch our own copy of Scintilla for this feature.

     
1 2 > >> (Page 1 of 2)