Am 01.09.2011, 09:19 Uhr, schrieb Bernard Helyer <b.helyer@gmail.com>:

> On Tue, 30 Aug 2011 11:57:48 +0000, Bernard Helyer wrote:
>
>> Good stuff. Nice to see Indigo support.
>
> I'm seeing some serious performance problems (Eclipse typing lagging and
> stuttering when working with templates and structs and big files in
> general). Anyone else seeing this?

Yes, I can definitely type faster than my CPU can handle DDT. :D
I'm close to switching to a pure text editor, but then again, I could first try to disable some features.
Also I realized that non-ASCII characters are sometimes errors where DMD would not complain. Sometimes when the non-ASCII is inside an identifier, not at the start or end.

On Tue, 18 Oct 2011 07:39:30 +0200, Marco Leise wrote:

> Yes, I can definitely type faster than my CPU can handle DDT. :D I'm close to switching to a pure text editor, but then again, I could first try to disable some features.

Yeah, I switched to emacs for the moment, as DDT is too painful to use.

DDT is a great help in learning about how the D language is used by providing  the ability to poke around in the library code ... especially the ability to find all references and opening the definitions.  I'm using VisualD for debug, but DDT for editing due to its superior completion and context pop-up help.  Thanks a lot.

On 18/10/2011 06:39, Marco Leise wrote:
> Am 01.09.2011, 09:19 Uhr, schrieb Bernard Helyer <b.helyer@gmail.com>:
>
>> On Tue, 30 Aug 2011 11:57:48 +0000, Bernard Helyer wrote:
>>
>>> Good stuff. Nice to see Indigo support.
>>
>> I'm seeing some serious performance problems (Eclipse typing lagging and
>> stuttering when working with templates and structs and big files in
>> general). Anyone else seeing this?
>
> Yes, I can definitely type faster than my CPU can handle DDT. :D
> I'm close to switching to a pure text editor, but then again, I could
> first try to disable some features.
> Also I realized that non-ASCII characters are sometimes errors where DMD
> would not complain. Sometimes when the non-ASCII is inside an
> identifier, not at the start or end.

I would really welcome some test cases, so that I could try this myself, and identify the issue. I know the current parser has several performance issues (known and unknown ones), but at least there should not be performance regressions (getting worse in new versions).

-- 
Bruno Medeiros - Software Engineer

Does DDT use a separate thread for parsing?
Editing bigger files can be extremely laggy.

On 27/11/2011 18:29, Trass3r wrote:
> Does DDT use a separate thread for parsing?
> Editing bigger files can be extremely laggy.

It does use a separate thread for parsing (standard practice with any Eclipse IDE). Doesn't mean there can't be issues causing laggyness.

I'm getting increasingly concerned with these reports of DDT becoming slow when editing large files, but I don't know how to replicate them (I don't program in D with large enough files to ever come across it), so unless someone gives me some test data - the files they are editing, machine specs, what they were doing (just typing or also doing content assist, etc.) - it will be very hard to address this issue!

-- 
Bruno Medeiros - Software Engineer

>> Does DDT use a separate thread for parsing?
>> Editing bigger files can be extremely laggy.
>
> It does use a separate thread for parsing (standard practice with any Eclipse IDE). Doesn't mean there can't be issues causing laggyness.
>
> I'm getting increasingly concerned with these reports of DDT becoming slow when editing large files, but I don't know how to replicate them (I don't program in D with large enough files to ever come across it), so unless someone gives me some test data - the files they are editing, machine specs, what they were doing (just typing or also doing content assist, etc.) - it will be very hard to address this issue!

Ok, I'll try to come up with some test set the next time I experience this.

btw, 2 other small issues:
- if you use autocompletion when the cursor is at the start of another identifier, it overwrites it instead of inserting.

So the cursor is left to foo, I press Ctrl+Space, choose something and it overwrites foo.
Partial completion works correctly though: |foo -> dem|foo -> Ctrl+Space -> demangle|foo -> I choose my own demangleBla -> demangleBla| -> no foo anymore

- Is there a way to disable automatic builds on every save?
I currently just delete the response file contents in D Compile Options and replace the command with echo "ok".

On 2011-12-01 16:18, Bruno Medeiros wrote:
> On 27/11/2011 18:29, Trass3r wrote:
>> Does DDT use a separate thread for parsing?
>> Editing bigger files can be extremely laggy.
>
> It does use a separate thread for parsing (standard practice with any
> Eclipse IDE). Doesn't mean there can't be issues causing laggyness.
>
> I'm getting increasingly concerned with these reports of DDT becoming
> slow when editing large files, but I don't know how to replicate them (I
> don't program in D with large enough files to ever come across it), so
> unless someone gives me some test data - the files they are editing,
> machine specs, what they were doing (just typing or also doing content
> assist, etc.) - it will be very hard to address this issue!

Well, just put a large library in a project, like Phobos, Tango or DWT. std.datetime in Phobos is 35+k lines of code. Then try different features like autocompletion and similar.

-- 
/Jacob Carlborg

Am 01.12.2011, 17:54 Uhr, schrieb Trass3r <un@known.com>:

> btw, 2 other small issues:
> - if you use autocompletion when the cursor is at the start of another identifier, it overwrites it instead of inserting.

That is actually a matter of preference - believe it or not! Some IDEs offer the option to either insert or overwrite on auto-complete.

My personal wish list is:
- Check Unicode identifiers. They are sometimes confusing the parser. (I should post example code here, really.)
- Inference of 'auto' types like 'x' in 'foreach (ref x; list)'
- I am using a symlinked Makefile in my projects instead of the build.rf. It's not like I'm doing anything fancy there for a debug build, but it has the advantage that updates to the options are propagated to all projects and I have the other targets (profile, unittest, release, ...) all in one place. Some way to support a custom Makefile build would be nice, even though the auto-generated script is quite handy to get started with D.
- GDB support would be awesome of course, but no hurry.

>> btw, 2 other small issues:
>> - if you use autocompletion when the cursor is at the start of another identifier, it overwrites it instead of inserting.
>
> That is actually a matter of preference - believe it or not! Some IDEs offer the option to either insert or overwrite on auto-complete.

If you want overwrite mode, press your INS key ;)
I'm ok with it becoming an option, but the default has to be insertion.

> - GDB support would be awesome of course, but no hurry.
Already done in trunk.