Qian Xu escribió:
> Ary Borenszweig wrote:
>> Enjoy :-)
> 
> Great work.
> 
> BTW: Is there any plan to make a "Organize Imports" feature? It would be
> very helpful.

Well... now that I've looked at some of JDT's code about this, seems a pretty hard thing to implement (to translate from Java to D, actually). But I'll try to do it, little by little.

One question about this. Imagine you have:

void foo() {
  auto name = readln();
  writefln("Hello %s!", name);
}

When requesting "Organize Imports", which one would you prefer?

1.
import std.stdio;

void foo() {
  auto name = readln();
  writefln("Hello %s!", name);
}

2.
import std.stdio: readln, writefln;

void foo() {
  auto name = readln();
  writefln("Hello %s!", name);
}

I think the second one is better because it's easier to understand the code, but the list of names might get very long. But I remember there were bugs related to selective imports, and I can't remember which were them. (and maybe it's also harder to implement)

2 is very nice towards the namespace
how will you do regex.find vs string.find?

"Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:h4pcpc$2ef6$1@digitalmars.com...
> Qian Xu escribió:
>> Ary Borenszweig wrote:
>>> Enjoy :-)
>>
>> Great work.
>>
>> BTW: Is there any plan to make a "Organize Imports" feature? It would be very helpful.
>
> Well... now that I've looked at some of JDT's code about this, seems a pretty hard thing to implement (to translate from Java to D, actually). But I'll try to do it, little by little.
>
> One question about this. Imagine you have:
>
> void foo() {
>   auto name = readln();
>   writefln("Hello %s!", name);
> }
>
> When requesting "Organize Imports", which one would you prefer?
>
> 1.
> import std.stdio;
>
> void foo() {
>   auto name = readln();
>   writefln("Hello %s!", name);
> }
>
> 2.
> import std.stdio: readln, writefln;
>
> void foo() {
>   auto name = readln();
>   writefln("Hello %s!", name);
> }
>
> I think the second one is better because it's easier to understand the code, but the list of names might get very long. But I remember there were bugs related to selective imports, and I can't remember which were them. (and maybe it's also harder to implement)

Saaa escribió:
> 2 is very nice towards the namespace
> how will you do regex.find vs string.find?

Just what JDT does: show you the matches of "find" and allow you to choose one of them.

>> 2 is very nice towards the namespace
>> how will you do regex.find vs string.find?
>
> Just what JDT does: show you the matches of "find" and allow you to choose one of them.

never used JDT for anything but your descent :)
but I should have known this is handled nicely already

Trass3r wrote:
> Ary Borenszweig schrieb:
>> Please report these things into the bug tracket:
>>
>> http://www.dsource.org/projects/descent/newticket
>>
> 
> 
> I'd have done that, if I had managed to narrow down the problem.

If you close and open all the projects, does it still happen?

Just created a fresh project with a single file to test:

/**
 *
 */
module main;

import std.file;
import std.stdio;

void main()
{
	writefln("");
	
	read("test");
}

Hovering over writefln works like a charm, also with Shift or Ctrl+Shift.
Normal hovering over read also works, but if I then hover over writefln again, I get 2
descent.core.JavaModelException: read(creal) [in Win32 [in file.d [in std [in D:\dmd\src\phobos]]]] does not exist

After that every time hovering over read yields 6 of those exceptions. Closing and reopening the project "resets" this.




Java Model Exception: Java Model Status [read(creal) [in Win32 [in file.d [in std [in D:\dmd\src\phobos]]]] does not exist]
	at descent.internal.core.JavaElement.newNotPresentException(JavaElement.java:518)
	at descent.internal.core.JavaElement.openWhenClosed(JavaElement.java:549)
	at descent.internal.core.JavaElement.getElementInfo(JavaElement.java:276)
	at descent.internal.core.JavaElement.getElementInfo(JavaElement.java:259)
	at descent.internal.core.Member.getFlags(Member.java:176)
	at descent.internal.core.SourceMethod.isConstructor(SourceMethod.java:220)
	at [...]

Sat, 25 Jul 2009 02:55:51 -0300, Ary Borenszweig wrote:

> Ary Borenszweig escribió:
>> Hi!
>> 
>> I just uploaded a new version of Descent that implements the "Open Type Hierarchy" funcionality.
> 
> And now that type hierarchy funcionality is in place, I implemented the "override indicators", and "override method" proposals, just like in the Java plugin for Eclipse. I uploaded a new version.
> 
> Here's a video about it:
> 
> http://www.youtube.com/watch?v=E_CUTimf9jE

This is simply great, thank you!  Too bad I'm not using IDEs...  I might just start, after all.

Minor suggestion:

import tango.text.Regex;
int main()
{
	// tango.text.Regex.
	return 0;
}

When i type "tango.text.Regex", then '.', Descent should list only elements inside module/namespace tango.text.Regex.

Thanks.

Major suggestion:

The auto compleat drop down is very un-aggressive. I'd love to see it be Google style sort based rather than ordered-list/browse based.

The kind of thing I'm thinking of is having a live sort of the options based on (among other things) what you have typed and the current context. For instance, pull things to the top of the list that are of the correct type for this context (or to a lesser extent, if they have members that are of the correct type), and do infix matches rather than just prefix matches. Also nice would be history based sorting (the more often I use something, the higher up it is).

BCS wrote:
> Major suggestion:
> 
> The auto compleat drop down is very un-aggressive. I'd love to see it be Google style sort based rather than ordered-list/browse based.

JDT definitely has this and Descent has some.

> The kind of thing I'm thinking of is having a live sort of the options based on (among other things) what you have typed and the current context. For instance, pull things to the top of the list that are of the correct type for this context 

Already (sorta) does this.

> (or to a lesser extent, if they have members that are of the correct type), and do infix matches rather than just prefix matches. 

Infix matches would be cool, but... where should they be presented in the list?

There is a feature in the Open Type dialog where you can type acronyms, i.e. "DQL" and get "DatabaseQueryListener" as a suggestion. Not sure how practical/useful this would be to implement in autocomplete.

> Also nice would be history based sorting (the more often I use something, the higher up it is).

VS has this & it's a nice feature.