[IronPython] IronPy Tools for VS - Bugs

[Steve Dower]

On Thu, May 6, 2010 at 08:56, Dino Viehland <dinov at microsoft.com> wrote:
> >
> > Completions should not start within strings (single-line strings
> > aren't recognised as strings until the closing quote is added).
>
> Can you give an example of exactly what you type to make this happen?  I
> can't currently repro it.
>

Judging from the text colour, strings aren't recognised until there is
both an opening and closing quote. I am not in the habit of putting
both quotes immediately and then typing within them (I put the first
one, type the string and then close it) and so until I reach the end
of the string everything I type is interpreted as an error (unexpected
token 'NEWLINE in single-quoted string') and every time I press space
the completion dropdown appears. Once the string is terminated
everything works fine.

Triple-quoted strings work fine, even though an unexpected EOF causes
the entire block to be an error, but the text changes to string colour
regardless. This is the behaviour I would expect for single/double
quoted strings as well - consider everything up the the EOL a string
and include some "unterminated" error.

> >
> > Tooltip for first parameter doesn't always disappear when moving to
> > the next parameter (ie. typing ',').
>
> Do you know what sort of callable this was on?   E.g. a built-in function
> or a Python function or something else?
>

I don't recall what the original one was, but I was able to reproduce
this using str on a line by itself using these steps:

1. Type "str(" (parameter information "1 of 13 str()" appears)
2. Press space (completion dropdown appears)
3. Either commit or abort completion (it doesn't matter which)
4. Type "," (parameter information "1 of 13 str()" appears a second time)
5. Repeat steps 2-4 to get lots of tooltips.

I also noticed that the left and right arrow keys don't affect the
current parameter. Not having coded this myself before I'm not sure
how one would go about adding that, but C# does it so I'm guessing
it's just something in the command filter.

> >
> > Keyword tooltips only parse from the character hovered over to the end
> > (ie. hover over 'r' in print shows "rint", over 'e' in def shows "ef",
> > etc.).
> > Whitespace immediately before a real number shows tooltip for the integer
> > part.
> > Tooltip for an equals sign immediately followed by a number shows
> > '=<ipart(number)>: tuple'
>
> These 3 are actually all the same basic issue...

I suspected as much, which is why I put them all together.