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

Built-in types are highlighted as support.function and not support.type if called #16

Closed
FichteFoll opened this Issue Sep 2, 2014 · 7 comments

Comments

Projects
None yet
4 participants
@FichteFoll

2014-09-02_22 40 11

Consider the above snippets, str is once highlighted as support.type and once highlighted as support.function, as well as list. This is probably because they are actually used like a function, but in fact they are classes. The default Python syntax def does not treat these built-in type calls differently to the literal references.

Here is the same snippet with the default Python syntax:
2014-09-02_22 44 56

I prefer the default version over the current, but what do you think?

@facelessuser

This comment has been minimized.

Show comment
Hide comment
@facelessuser

facelessuser Sep 2, 2014

Contributor

I think part of the problem is that they currently need to be treated like a function in order to have parameters get highlighted. I agree that they aren't really functions though.

So I think that the current implementation is the easy way to get parameters etc. working; just make them functions.

But the other way would be to add parameter support to these class objects; that would be more work, but it would more correct. I have thought about doing the latter approach myself, but I am also very lazy at times when I have something working.

I would be interested to hear what @MattDMo thinks as well.

Contributor

facelessuser commented Sep 2, 2014

I think part of the problem is that they currently need to be treated like a function in order to have parameters get highlighted. I agree that they aren't really functions though.

So I think that the current implementation is the easy way to get parameters etc. working; just make them functions.

But the other way would be to add parameter support to these class objects; that would be more work, but it would more correct. I have thought about doing the latter approach myself, but I am also very lazy at times when I have something working.

I would be interested to hear what @MattDMo thinks as well.

@FichteFoll

This comment has been minimized.

Show comment
Hide comment
@FichteFoll

FichteFoll Sep 2, 2014

I'm not as busy as I was last time in #8. I also realize now, after seeing the screenshots in there, that this is an issue directly caused by that change.

I'll start working on the "fix" that I had in mind back then which should also cover this issue and hopefully also make the syntax definition itself a bit more manageable.

I'm not as busy as I was last time in #8. I also realize now, after seeing the screenshots in there, that this is an issue directly caused by that change.

I'll start working on the "fix" that I had in mind back then which should also cover this issue and hopefully also make the syntax definition itself a bit more manageable.

@facelessuser

This comment has been minimized.

Show comment
Hide comment
@facelessuser

facelessuser Sep 3, 2014

Contributor

Meh, I think in this case there was a net positive increase in the highlighting via #8, but yeah, it could be done better. I look forward to seeing this improve even more; I'll keep an eye out for your fix.

Contributor

facelessuser commented Sep 3, 2014

Meh, I think in this case there was a net positive increase in the highlighting via #8, but yeah, it could be done better. I look forward to seeing this improve even more; I'll keep an eye out for your fix.

@MattDMo

This comment has been minimized.

Show comment
Hide comment
@MattDMo

MattDMo Nov 15, 2014

Owner

So after a hiatus, I'm trying to get back to work on this again. I've merged @FichteFoll's changes into a testing branch in my repo, and I'll see what makes sense to use.

Owner

MattDMo commented Nov 15, 2014

So after a hiatus, I'm trying to get back to work on this again. I've merged @FichteFoll's changes into a testing branch in my repo, and I'll see what makes sense to use.

@aldanor

This comment has been minimized.

Show comment
Hide comment
@aldanor

aldanor Oct 30, 2015

Any updates? 🐼

aldanor commented Oct 30, 2015

Any updates? 🐼

@MattDMo

This comment has been minimized.

Show comment
Hide comment
@MattDMo

MattDMo Oct 31, 2015

Owner

@aldanor as a matter of fact, yes! PythonImproved 2.0 is going to be released in the very near future, and this is fixed there.

Owner

MattDMo commented Oct 31, 2015

@aldanor as a matter of fact, yes! PythonImproved 2.0 is going to be released in the very near future, and this is fixed there.

@MattDMo MattDMo closed this Oct 31, 2015

@MattDMo MattDMo added this to the 2.0 milestone Oct 31, 2015

@aldanor

This comment has been minimized.

Show comment
Hide comment
@aldanor

aldanor Nov 1, 2015

@MattDMo wow, very cool -- and a good timing!

Thanks!

aldanor commented Nov 1, 2015

@MattDMo wow, very cool -- and a good timing!

Thanks!

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