felipemanga / PyInSky

Cloud based Python IDE for Pokitto
4 stars 0 forks source link

Improve pixel highlighting syntax #1

Open Pharap opened 5 years ago

Pharap commented 5 years ago

It would be ideal if it were possible to have some limited control over the editor through specialised comments.

For example, at the moment a variable has to contain the name pixels to get the 'pixel highlighting' functionality. It would be better to be able to put a comment above the variable declaration indicating that it's an image rather than placing limitations on users' identifiers.

@haviital has also brought up the possibility of using (for example) # PROJ_SHOW_FPS_COUNTER to enable the FPS counter display.

felipemanga commented 5 years ago

Hey, I'd prefer to split this into two separate issues. Pixel highlighting syntax is pretty simple (whether it's done with comments or not), while PokittoLib defines are a whole other can of worms.

As for highlighting, the current situation looks like this:

imagePixels = b'\x00'
image = upygame.surface.Surface( 1, 1, imagePixels )
screen.blit( image, x, y )

"Pixels" is only used once in a temporary variable, so it's not too bad. The actual surface is used for the blitting and that can have whatever name you want.

From what I understand, you want someting like this:

#image
whateverData = b'\x00'
whatever = upygame.surface.Surface( 1, 1, whateverData )
screen.blit( whatever, 1, 1 )

Rather than a comment, I think the ideal here would be to detect something like ".surface.Surface([0-9]+, [0-9]+," and do away with the temporary: whatever = upygame.surface.Surface( 1, 1, b'\x00' )

felipemanga commented 5 years ago

New issue added for PokittoLib settings: https://github.com/felipemanga/PyInSky/issues/3

Pharap commented 5 years ago

I'd prefer to split this into two separate issues. Pixel highlighting syntax is pretty simple (whether it's done with comments or not), while PokittoLib defines are a whole other can of worms.

Fair enough.

I was thinking of the problem at a higher level. I.e. that if both mechanisms were activated via comments then the actual system for idetecting specialised comments would be the same for both, ignoring any special handling. (E.g. commentDetectionSystem.registerHandler(regex, handlerFunction);.)

"Pixels" is only used once in a temporary variable, so it's not too bad.

No, but the flexibility would be useful, and I think it would be less surprising.

From what I understand, you want someting like this

Yeah, that's the sort of thing I was thinking of. Perhaps having some additional symbol to identify the comment as a 'comment macro', like how Doxygen uses a special symbol combination to identify doxygen compatible comments.

Rather than a comment, I think the ideal here would be to detect something like ".surface.Surface([0-9]+, [0-9]+," and do away with the temporary

I think shoving a large byte string into a function call is going to make the code harder to read.


Another alternative would be to colour all byte strings by default.

It would look a bit odd if people were trying to do something like:

b'\xcf\x84o\xcf\x81\xce\xbdo\xcf\x82'.decode('utf-8')

But I think unicode manipulation is going to be relatively uncommon considering the Pokitto library doesn't support any non-latin fonts as far as I'm aware.

Worst case scenario, people end up with multicoloured strings and they're a tiny bit distracting.


Either way this is probably a less important issue than some of the others that will come up.

haviital commented 5 years ago

This really is a low priority issue. The only "fix" I would like to have sooner is to put a normal comment that bytes literal name should have the "pixels" substring in the name. There are always people who do not look at FAQs nor watch tutorial videos.