Re: [Pydev-code] New pydev jython scripts: Assign stuff to variable if it is None

[Joel H. <yo...@if...>]

 > Nice touch...

Thanks! :-)

 > I've just commited your code, but I did do one change:

Cool! I also made one change, though... AssistProposal now also has a 
priority attribute, so you can move the 'chattier' ones down to the 
bottom of the list (i.e: assign dict and list) while keeping the more 
specialized at the top (i.e: create error message, attached).

 > instead of
 > letting 3 options: for list(), dict() or self.var_value, I've only let
 > one that does:
 > <snip>
 > and let the '[]' selected for the user to change it.

Yeah... That should be reasonable for most users. I do this a lot
though, so I like my 'usual suspects' to be there from the start.

That's also the reason I split the actual incorporation into the 
assistant into three separate pyedit_*.py scripts, so that people could 
decide for themselves which ones that they would want to use. Perhaps I 
should have put a Bool check at the top of the scripts to help people 
turn it on or off? Say for example:

USE_THIS_ASSISTANT_PROPOSAL = True
if not USE_THIS_ASSISTANT_PROPOSAL:
     raise ExitScriptException()

Furthermore, I intentionally used list() instead of [], so that you 
reuse the parantheses for function calls, like so:

class MyClass:
     def method(self, arg = None):
         if arg is None:
             arg = self._get_value()
     ...

Oh, and speaking of selected things, I was wondering how do you do those 
tabbed field things that you get if you type 'inip' or 'classs' and then 
hit Ctrl-Space? I've whipped up a proposal for creating error messages 
(attached), and it would have been so much better if I could have tabbed 
fields for the message template, formatting vars and exception class.

I suppose I could have done this by just adding a code completion 
template for it, but since there are no code completion variables for 
'initial indent' and 'additional indent', the result would just be messy.

 > I did it mostly because I think that presenting too many options for a
 > very similar thing makes things a bit confusing (so, you actually have
 > to stop for a moment and read each option carefully

Yeah, I see your point. In fact, I already did before I read this mail 
:-) But since I use those similar ones a lot and didn't want to get rid 
of them, I hacked up that priority thing as a workaround which at least 
works well for me. I find that by stuffing the similar ones further down 
the list, you will in fact rarely read them if you're not actively 
looking for them, simply because the more specialized proposals will 
always be readily available at the top.

 > def met1(self, arg=None): |<-- ctrl+1 here would bring the suggestion,
 > instead of having to create another line with arg to make the choice
 > (and if more than one argument had '=None', add one option for each).
 >
 > What do you think?

Shouldn't be too hard. I'll see if I can find the time to implement it.

 > As for the assign code, I didn't add it because there was an option to
 > do it already (I've just relaxed the restriction of just doing it on a
 > call).

That's probably for the best.

Take care!
/Joel