> from org.python.pydev.core.docutils import ParsingUtils
> ParsingUtils.eatLiterals (document,
>                          StringBuffer(),
>                          initialOffsetOfLiteral)

Who put StringBuffer in my scope? I can see it's there but I didn't
declare it? Is it a Jython thing? Where can I read  up on this?

It is a java thing -- comes from java.lang... Actually you should import it into your scope: from java.lang import StringBuffer.
You can check its javadocs at: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html


Oh, and is there something similar for retrieving the contents of
parantheses? I tried:

iOffset = oSelection.absoluteCursorOffset
oStrBuf = StringBuffer()
print iOffset
print ParsingUtils.eatPar(document, iOffset,  oStrBuf)
print oStrBuf

which returns offset of the paranthesis that closes the closest nested
paranthesised _expression_ in which the cursor currently is placed, but
oStrBuf is left empty. I was thinking maybe I should use this to detect
parameters instead, since that might be an easy way of dealing with line
continuations, comments and code directly after the scope opening colon
on def lines. What do you think?

Actually, the current version seems nice to me... It actually uses the ParsingUtils to get the parents, so, it should be ok.  Also, in the tuple you have in the return, 'tuple.o2' will give you the parenthesis end
-- You can check that function at: http://cvs.sourceforge.net/viewcvs.py/pydev/org.python.pydev.core/src/org/python/pydev/core/docutils/PySelection.java?view=markup

> So, what were your first impressions on pydev scripting?

It's great. It gives me great opportunity for customisations, which
otherwise would be impossible (since I don't Java :-). It's all still a
little bewildering since I'm not yet used to how the internals of
neither eclipse or pydev work. The learning curve seems steep (but not
vertical). The dir utils you posted proved to be life savers. It's a
pity the code is cropped when viewed in the html repository at
sourceforge, so maybe you could put it somewhere accessible so that
people not currently on this list also can benefit from them?

Sure... Actually, I have in my 'todo-list' doing a developers manual, on how to get the code, so, I guess I'll put this there too.

One impression is that there seem to be very little documentation. Maybe
I've got myself to blame since I must admit I still haven't pulled down
the pydev source. To my defense, I've been confined to WinXP the last
couple of days and I don't really know how to cvs from that... On the
other hand, this list has been a great help with speedy and constructive
responses.

Well, actually most code has javadocs, so, probably doing at least a javadoc from pydev code and making it available would be a good addition to that. As for the cvs stuff, that developers manual would surely help -- It should be pretty easy getting the pydev code in Eclipse.

> I'd really like to know ways to improve it...

It's too early for me to tell, I think. I need to mess around with it
for a while first, but I'll get back to you once I come up with
something solid. Should I post those feature requests to this list or to
the tracker at sourceforge?

If you want to elaborate on them, you can put it in this list (and put it later in the tracker), now, if you're sure of what you want, just toss it in the tracker .

Cheers,

Fabio

Reply via email to