I've been having a lot of issues with visual D. I'm not sure if it's just dysfunctional, has a few bugs, new bugs were introduced, or what has happened. Some things have always been like then. I have a potential solution though.

I will invest quite a bit of time documenting the issues I have using video, pictures and text, explaining why these problems are bad and even give the source code so you can use it to help fix these problems.

Most of these problems seem like bugs, some are inadequacies, some are probably just incomplete features, some may be expected behavior for some peoples workflow but doesn't work in mine.

If I do this will you be willing to take a serious look in to these problems and try to resolve them if we can come to an agreement that they are problems? (and that might simply be that it is an issue on my side if everything works as they are suppose to on yours)

Why I'm asking is that I am extremely unproductive in D because of it's arcane debugging problems that I seem to run in to quite often. I'm sure if these problems could be fixed(or the major ones), I'd be far more productive and enjoy the experience more too.

But there is no point in me doing this if you won't or can't invest the time(it's not a demand or insult, I just don't want to waste my time).

I've already brought up many of these problems so you basically know about them more or less. I realize it's hard to really know what's going on much less fix them without really seeing the problem and knowing why it is a problem(most of these problems have solutions but the solutions/work-arounds are extremely time consuming compared to what the debugger/ide can do). This is why I would invest the time to really show these problems in detail and explain why the alternative is better(and these things are not arcane issues I have, at least most of them).

I realize some of these problems are not solvable in any satisfiable sense but some are definitely needed for efficiency. Some of the harder ones could be long term goals to work on a little at a time so they eventually get fixed.

Since I'm not proficient and already have too much on my plate, I can't learn the inner workings of Visual D and try to fix these things myself, hence why you'll have to do it if you choose to.

Of course, you have none to lose to pretend that you'll invest your time... but I hope you wouldn't do that to me. No big deal if you really don't want to or can't. Life is more important, but if these fixes can persist(not regress) then they should make programming in Visual D much more friendly for most people that use it in the future.

Thanks.

On 11/10/2018 06:34, James Japherson wrote:
> I've been having a lot of issues with visual D. I'm not sure if it's just dysfunctional, has a few bugs, new bugs were introduced, or what has happened. Some things have always been like then. I have a potential solution though.
> 
> I will invest quite a bit of time documenting the issues I have using video, pictures and text, explaining why these problems are bad and even give the source code so you can use it to help fix these problems.
> 
> Most of these problems seem like bugs, some are inadequacies, some are probably just incomplete features, some may be expected behavior for some peoples workflow but doesn't work in mine.
> 
> If I do this will you be willing to take a serious look in to these problems and try to resolve them if we can come to an agreement that they are problems? (and that might simply be that it is an issue on my side if everything works as they are suppose to on yours)
> 
> Why I'm asking is that I am extremely unproductive in D because of it's arcane debugging problems that I seem to run in to quite often. I'm sure if these problems could be fixed(or the major ones), I'd be far more productive and enjoy the experience more too.
> 
> But there is no point in me doing this if you won't or can't invest the time(it's not a demand or insult, I just don't want to waste my time).
> 
> I've already brought up many of these problems so you basically know about them more or less. I realize it's hard to really know what's going on much less fix them without really seeing the problem and knowing why it is a problem(most of these problems have solutions but the solutions/work-arounds are extremely time consuming compared to what the debugger/ide can do). This is why I would invest the time to really show these problems in detail and explain why the alternative is better(and these things are not arcane issues I have, at least most of them).
> 
> I realize some of these problems are not solvable in any satisfiable sense but some are definitely needed for efficiency. Some of the harder ones could be long term goals to work on a little at a time so they eventually get fixed.
> 
> Since I'm not proficient and already have too much on my plate, I can't learn the inner workings of Visual D and try to fix these things myself, hence why you'll have to do it if you choose to.

Pedantically, Visual D has only very little influence on the debug experience, it is a combination of the compiler-generated debug information, the VS debugger and the mago debugger-plugin or mago debug-engine depending on what engine you select.

> 
> Of course, you have none to lose to pretend that you'll invest your time... but I hope you wouldn't do that to me. No big deal if you really don't want to or can't. Life is more important, but if these fixes can persist(not regress) then they should make programming in Visual D much more friendly for most people that use it in the future.

I'm interested in making the debug experience better, but I can't promise I can solve all issues. Visual D and mago are still more-or-less one-man-projects I do in my spare time.

Videos are good if the issue is hard to demonstrate or not easily reproducible. Small reproducible test cases are often a lot easier to get started, though.

Please post issues to https://issues.dlang.org, so they don't get lost in forum discussions.