On 9/1/13 11:52 AM, Andrej Mitrovic wrote:
> On 9/1/13, Manu <turkeyman@gmail.com> wrote:
>> Perhaps the dev's here use relatively few, or very simple classes?
>
> I think it's the latter. Plus we have UFCS, so we don't necessarily
> have to define everything as a member function. Also remember that D
> isn't so reliant on classes for "polymorphic" behavior, we have
> templates. All of this contributes to much fewer uses of classes than
> in, say, C#.
>
>> And why would you want to indent every line of function code by a few tabs?
>
> I think this is a result of not being able to define the methods
> outside of the class. You still want a visual clue that they're member
> functions, so you indent them. Otherwise I'd personally love to be
> able to define the methods outside.
>
> Btw, I found Andrei's post where he proposes your suggestion:
>
> http://forum.dlang.org/thread/j0cs8r$mch$1@digitalmars.com#post-j0cs8r:24mch:241:40digitalmars.com
>
> At #1 is:
> 1. The compiler shall accept method definitions outside a class.

I still think there's value in accepting that, and IMHO it's a no-brainer requirement if hand-written .di files are to be used systematically. The argument for all-in-one classes is less duplication of signatures. Our current approach makes for _more_ duplication in projects using hand-written .di files because the duplication includes class state.

Andrei

On 9/1/2013 9:26 PM, Manu wrote:
> Might I suggest one step further to you Walter, that it might be worth-while for
> you to take an interest personally into Visual-D, and maybe Mago. Since you're
> probably the primary Windows contributor?
> Perhaps try and work with these tools on a daily basis for a while. Especially
> try some intensive debugging sessions under Visual-D/VS.
> You might find that it may short-circuit a lot of micro-bug reports in the
> debugging experience.

At some point I have to delegate. I can't personally take charge of everything.

You are an expert with VS, you work extensively with others who use VS, and you know exactly what you need VisualD to do. Please work with the VisualD developer (Rainer)!

I'm the wrong person to do this. I try IDEs now and then, and have never been happy with them. I don't need the features they have. I know I'm out of step because of that, but it makes me the wrong person to fix it.

On 2013-09-02 17:16, H. S. Teoh wrote:

> OK, excuse the vim fanboyism, but I think any serious D IDE ought to
> have this kind of functionality to ease navigation through source code.
> Scrollbars are so last century. (Not to mention totally worthless when
> dealing with 10,000-line files when the bar is 1 pixel high and
> scrolling by 1 pixel maps to 5 pages -- totally worthless for
> navigation.)

I would say you have too big files then, but that's another discussion :)

-- 
/Jacob Carlborg

On 9/1/2013 8:28 PM, Manu wrote:
> D probably appeals more to ex-C++ users (I'm not aware of any sensis, but D's
> main offering at least to me, is an evolution from C++). We are used to being
> able to gather a quick summary of a class at a glance.
> D (or perhaps just me) makes extensive use of local functions. If the outer
> function is at the leftmost tab level, it's easy to recognise if you're reading
> the code from a local function or not. If the outer function is already a few
> tab levels deep, I frequently find myself becoming unsure of what/where I'm
> actually reading.

I don't know if this is an IDE feature or not, but I've often thought of adding a command to my editor (MicroEmacs) to collapse/expand function bodies. This would make it convenient to navigate larger files - just collapse, move to the function you want to examine, then expand. It would also mitigate the issue you have. I theorize that VS doesn't have such a feature? Maybe IDEs are solving the wrong problem? :-)

One that collapses out the comments would be great, too, as I've found one downside of Ddoc is it can get hard to find the code amongst the doc comments.

On Monday, 2 September 2013 at 17:29:21 UTC, Walter Bright wrote:
> On 9/1/2013 8:28 PM, Manu wrote:
>> D probably appeals more to ex-C++ users (I'm not aware of any sensis, but D's
>> main offering at least to me, is an evolution from C++). We are used to being
>> able to gather a quick summary of a class at a glance.
>> D (or perhaps just me) makes extensive use of local functions. If the outer
>> function is at the leftmost tab level, it's easy to recognise if you're reading
>> the code from a local function or not. If the outer function is already a few
>> tab levels deep, I frequently find myself becoming unsure of what/where I'm
>> actually reading.
>
> I don't know if this is an IDE feature or not, but I've often thought of adding a command to my editor (MicroEmacs) to collapse/expand function bodies. This would make it convenient to navigate larger files - just collapse, move to the function you want to examine, then expand. It would also mitigate the issue you have. I theorize that VS doesn't have such a feature? Maybe IDEs are solving the wrong problem? :-)
>
> One that collapses out the comments would be great, too, as I've found one downside of Ddoc is it can get hard to find the code amongst the doc comments.

I'm pretty certain most IDE's do have code folding in some form or other. I can't remember ever noticing it not being there in anything I've used.

On Mon, Sep 02, 2013 at 07:25:22PM +0200, Jacob Carlborg wrote:
> On 2013-09-02 17:16, H. S. Teoh wrote:
> 
> >OK, excuse the vim fanboyism, but I think any serious D IDE ought to have this kind of functionality to ease navigation through source code.  Scrollbars are so last century. (Not to mention totally worthless when dealing with 10,000-line files when the bar is 1 pixel high and scrolling by 1 pixel maps to 5 pages -- totally worthless for navigation.)
> 
> I would say you have too big files then, but that's another discussion :)
[...]

Well, personally I like to structure my code so that such big files don't happen. :) But then again, there's *cough*std.algorithm*ahem*...

But I have to say that even with overly-large files, vim's concept of using search to find stuff instead of scrolling and trying to find things visually, helps one get into a mindset that makes navigating large source files more manageable. I used to be a big fan of visual navigation -- pgUp, pgDn, paragraph up, paragraph down, etc., but beyond 500 lines or so, they quickly become impractical. Having a 1-key search function (that doesn't involve popups and other such annoyances) with reversible direction is a far superior approach. It also saves a LOT of keystrokes spent navigating horizontally when trying to reach a specific point on a line: no need to hit left/right keys 40 times or move your hand to the mouse and back, just search for a pair of characters (3-4 keystrokes) and you're exactly where you need to be. It took me a while to get used to this mode of navigation, but I found it far superior to whatever it was I used to do.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On 9/2/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> It took me a while
> to get used to this mode of navigation, but I found it far superior to
> whatever it was I used to do.

I once wrote a VIM mode for Scintilla, using AutoHotkey (win32 tool
for keyboard shortcuts).

It even had a sort-of command interpreter, where I could write in "10w" and it would skip the cursor after 10 words. But it was still a pain in the ass to use (you can't get it perfect), so I just dropped using it altogether.

On Monday, 2 September 2013 at 17:57:50 UTC, H. S. Teoh wrote:
> On Mon, Sep 02, 2013 at 07:25:22PM +0200, Jacob Carlborg wrote:
>> On 2013-09-02 17:16, H. S. Teoh wrote:
>> 
>> >OK, excuse the vim fanboyism, but I think any serious D IDE ought to
>> >have this kind of functionality to ease navigation through source
>> >code.  Scrollbars are so last century. (Not to mention totally
>> >worthless when dealing with 10,000-line files when the bar is 1 pixel
>> >high and scrolling by 1 pixel maps to 5 pages -- totally worthless
>> >for navigation.)
>> 
>> I would say you have too big files then, but that's another discussion
>> :)
> [...]
>
> Well, personally I like to structure my code so that such big files
> don't happen. :) But then again, there's *cough*std.algorithm*ahem*...
>
> But I have to say that even with overly-large files, vim's concept of
> using search to find stuff instead of scrolling and trying to find
> things visually, helps one get into a mindset that makes navigating
> large source files more manageable. I used to be a big fan of visual
> navigation -- pgUp, pgDn, paragraph up, paragraph down, etc., but beyond
> 500 lines or so, they quickly become impractical. Having a 1-key search
> function (that doesn't involve popups and other such annoyances) with
> reversible direction is a far superior approach. It also saves a LOT of
> keystrokes spent navigating horizontally when trying to reach a specific
> point on a line: no need to hit left/right keys 40 times or move your
> hand to the mouse and back, just search for a pair of characters (3-4
> keystrokes) and you're exactly where you need to be. It took me a while
> to get used to this mode of navigation, but I found it far superior to
> whatever it was I used to do.
>
>
> T

This is exactly my experience now i use gVim. I haven't used a scrollbar in years while coding (i even have the menu disabled). Coupled with the Ctrl-P plugin and you can browse and search among massive files in literally a few keystrokes. Before that i used Visual Studio on Windows and even with all it's fancy folding, regions, class outlines and diagrams i still feel much more faster at traversing and understanding code now in Vim.

I just miss the debugger!!! Seriously agree with other comments regarding this, D needs a better debugger. Even just a standalone one. GDB seriously does not cut it. I use it with DDD (which works just) but is horrible. Usually i make do with writeln(). :(

On Monday, 2 September 2013 at 13:51:04 UTC, Andrej Mitrovic wrote:
> On 9/2/13, Manu <turkeyman@gmail.com> wrote:
>> But I still barely see this as an inconvenience when compared to not being
>> able to read a class definition.
>
> How about not being able to read the include paths in VS? I'm talking
> about this:
>
> http://i.stack.imgur.com/0cTZG.png
>
> You can view 2 lines at a time. After almost 20 years they still
> haven't fixed this. Where is their core dev team that should make the
> IDE experience great?

You can stretch that window larger.  I believe prior to 2010 it was a fixed size though.  Pretty ridiculous.

On Monday, 2 September 2013 at 17:24:47 UTC, Walter Bright wrote:
> At some point I have to delegate. I can't personally take charge of everything.
>
> You are an expert with VS, you work extensively with others who use VS, and you know exactly what you need VisualD to do. Please work with the VisualD developer (Rainer)!
>
> I'm the wrong person to do this. I try IDEs now and then, and have never been happy with them. I don't need the features they have. I know I'm out of step because of that, but it makes me the wrong person to fix it.

The #1 quality of a (wo)man is to recognize what (s)he is not competent at. You have that quality.