[wingide-users] Some thoughts

David Taylor taylor234 at comcast.net
Fri Aug 19 13:45:38 MDT 2011

+1 on having a little more insight into the upcoming features. You guys do
such a great job of listening to your users & fixing problems when they
arise, but you've committed to putting a LOT of features on your to-do list,
and we're realistic enough to know they won't all appear at once. It would
really help if you could give us some idea of your priorties for these
features and/or a rough cut at your intended development sequence. I know
there are risks in doing that, but there are rewards as well, such as (1)
getting feedback from us as to our own priorites for those features (other
than just mentioning the ones we want), and (2) helping us be patient when
the lack of a feature is frustrating us.



-----Original Message-----
From: wingide-users-bounces at wingware.com
[mailto:wingide-users-bounces at wingware.com] On Behalf Of
ristretto.rb at gmail.com
Sent: Friday, August 19, 2011 11:38 AM
To: Wing IDE Support
Cc: Wing Users
Subject: Re: [wingide-users] Some thoughts

Some Comments below.

To the Wing leaders:

I really hope Wing continues to be the rocking tool it is.  But, it looks
like the IDE wars are hot, and I hope you have a plan.
I know the policy is generally to not tell us about what you are planning.
But, perhaps it's time to rethink that.  If I knew that really powerful
features were coming, and when, I might tough it out a bit longer.  If I
have no idea when something will actually be implement in Wing,  it make
more sense to jump ship.
I don't want to jump ship.


On Fri, Aug 19, 2011 at 7:43 AM, Wing IDE Support <support at wingware.com>
> On 8/18/11 7:38 PM, ristretto.rb at gmail.com wrote:
>> 1. [snip] What I would dearly like is a list of open files down one 
>> side of the window.  [snip]
> The list of open files is a good idea, but is probably too difficult 
> to implement in a script.  A tool panel the displays all open files is 
> probably more doable.  We'll look at possibly adding a list of open 
> files in the future.

You have been looking into this for a while:
I truly hope you implement something soon.

>> 2.  Open From Project is slowish to open, and if I start typing too 
>> soon, I get text in my current open window.  This window could use 
>> some power tools like tab completion.  I would use this instead of a 
>> open files list, if it was fast and quick to use.
> It should only be slower the first time and then faster after that.  
> It should also be faster the first time in the next release.

I should have mention speed, since the speed isn't the main issue.
The biggest problems are these:
A.  Allowing input in the current editor while waiting for the open files
dialog to come up.
Can you somehow save the typed input that happen while waiting for the
dialog to appear, and then apply it to the dialog's text box once it has
That way, I don't care if it take a second or two to come up, I just know my
typing will be in the box when it does B.  Requiring me to type a lot to
fine things.  Tab completion, and smart guessing of what I'm looking for
would be a huge improvement.

>> 3.  Is there a way to copy the path to the current file on the 
>> clipboard?  Sometimes I need to know it to paste somewhere else.
> We need to add this.  A workaround to get the path of the file is to 
> use open from keyboard, select the path, and then copy it.

That's nice, but doesn't get you the file name.  If you pasting into a term,
then a bit of tab completion will work.  But, if you are pasting somewhere
else, it doesn't.

>> 1.  super(SomeObject, self).save(*args, **kwargs).  Clicking on save 
>> should follow the hierarchy to find def save()
> I'll increase the priority on supporting this.

When coding a new project, Inspection isn't as important.  But when coming
onto a large project in the middle, being able to get the IDE to find the
relationships for you is huge.

I would say, you have to keep up with PyCharm just to compete, and out
perform in this area to be the leader.

>> 3.  parameter help
> Do you mean parameters in the autocompleter or something else?

Yes.  Just like Code Inspection is helpful with learning new code, the
Completion tools are helpful when writing new code.

>> 1.  return in a # comment considers the next line a comment too and 
>> puts in a #
> Hmm, I guess it depends on the frequency of multiline comments as to 
> whether it's better to insert a # after enter or not.

When you are breaking long comment it two, for reason of pep-8 for example.
I'm not suggesting doing it when you are at the end of a comment line.  Only
when in the middle and you return.
PyCharm does this.

>> 2.  git annotate for git integration
> We'll add this.

This is pretty minor, if we can easily copy the file path from the ide
somehow and paste it into the term window and run git annotate.

Wing IDE users list

More information about the wingide-users mailing list