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.
Optionally removes trailing whitespace, tweaks to startup script for the prompt, bugfixes for indentation handling, bugfixes in separators (now purely placed based on indentation), and in shortcuts. More in the changelog.
Separators are now JUST based on indentation. This way the nesting is completely up to the programmer.
The only exception is that separators will not be used as roots.
I know I'm nagging, but honestly I think separators base on indentation are not a good idea, because separators are comments and Python does not care about the indentation of comments either. Consider this example:
Label 2 clearly belongs inside f(x) between 1 and 3, irrelevant of its indentation. But DrPython prints it after 1 and 3 which is confusing.
My suggestion is that a label should be treated as if it had the same indentation as the following real (non-comment) Python statement.
Another issue with separators: I think a dotted horizontal line in the middle would be better icon than empty space. Or a very light grey sharp character (#) symbol. With the empty space, the horizontal line at the left side looks as if it is ending "nowhere."
The problem with a dotted horizontal line is that it may not line up as well on different platforms.
Onto the parsing:
The problem is that I'd need to completely change how the sourcebrowser parses to do things the way you want.
I actually had labels parsed that way last time, but since drpy only looks at defs, classes and imports, the returns are not picked up (as you noticed in your last note on sourcebrowser behaviour).
The question is, if I rewrite the parsing code, will it be drastically slower? I am not at all inclined to completely rewrite the sourcebrowser just for labels, if there is a significant speed price to pay.
Perhaps using the block code to find the start and end of each block, and then locate labels within each block, would be best....
I don't think the labels will slow down parsing if you do it correctly. Maybe I will have a look into it next week if I find some time.
Hmmm. Well, it would if I searched for all blocks of code.
However, If I only change the code so:
IF a label is encountered, do the block end search then and only then (so the speed penalty is only paid by people using labels).
Basically, the idea would be to try the previous block, and if the end of that block is after the position of the label, then add the label at the same indentation as the previous item. If not, try the item before that in (and so on).
I think this will work.
Or maybe it will just be a mess.
After all that, I got it working perfectly :).
It is always the simplist solution that seems to work (and be initially hidden).
This will be in the next release.