Make fields and functions in PdeKeywords protected #2383

Closed
marcogillies opened this Issue Mar 3, 2014 · 3 comments

Comments

Projects
None yet
3 participants
@marcogillies

The PDEKeywords class in the Processing app, handles syntax highlighting. This would seem a prime candidate for subclassing in different modes. As different languages have different syntax rules, then there should be different code for handling them (I am currently working on the Python mode).

However, it isn't really set up for subclassing as important members and functions (lastOffset, lastKeyword, doKeyword) are declared private. Would it be possible to make these protected?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 11, 2014

Member

@jdf managed to get through this with his version of Python Mode; is there anything we're still missing here or can this be closed?

Member

benfry commented May 11, 2014

@jdf managed to get through this with his version of Python Mode; is there anything we're still missing here or can this be closed?

@jdf

This comment has been minimized.

Show comment
Hide comment
@jdf

jdf May 11, 2014

Contributor

I forked an old copy of the original open source project that the syntax highlighting editor in PDE is built from in order to execute the Python mode editor.

Contributor

jdf commented May 11, 2014

I forked an old copy of the original open source project that the syntax highlighting editor in PDE is built from in order to execute the Python mode editor.

@benfry benfry changed the title from PDEKeywords is inheritance unfriendly to Make fields and functions in PdeKeywords protected Aug 13, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 13, 2015

Member

Looked at this now and went back and forth several times... The keyword coloring is really fragile (and buggy), and those interfaces stink, so I'd left them hidden so that we're not supporting them in perpetuity or setting up an expectation of them working in future releases.

Then again, if we change anything, it'll be getting rid of the entire 'syntax' package, so we may as well make those available as-is.

So... fixed for 3.0 beta 4.

Member

benfry commented Aug 13, 2015

Looked at this now and went back and forth several times... The keyword coloring is really fragile (and buggy), and those interfaces stink, so I'd left them hidden so that we're not supporting them in perpetuity or setting up an expectation of them working in future releases.

Then again, if we change anything, it'll be getting rid of the entire 'syntax' package, so we may as well make those available as-is.

So... fixed for 3.0 beta 4.

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