Visual D Debugger "complaints" (Mago?)

[Rainer Schuetze via Digitalmars-d-ide]

On 22.06.2016 00:34, Joerg Joergonson wrote:
> On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>>
>> On 18.06.2016 17:57, Joerg Joergonson wrote:
>>> On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
>>>>
>>>> Visualizer code in the binary sounds like an interesting idea. Given
>>>> some convention on naming so that symbols are discoverable and rather
>>>> safe to call, that could be doable.
>>>>
>>>> Mago does not yet support calling code in the debugged process, so
>>>> that would be a first step to implement such kind of visualizers.
>>>
>>> It would be interesting, easy on the end user, and "portable" if it
>>> could be done.  Having it stored in modules could allow mago/VD to
>>> compile the code(since we know we have the compiler) outside the
>>> project. Generic debugging helpers could be written and shared. It just
>>> depends on the difficulty of implementing properly ;)
>>
>> Visualizers in a separate module or even binary have the problem of
>> not being able to access private symbols. Having it in a DLL built and
>> loaded by mago/vd needs an extensive API for reflection and memory
>> access. This seems like a larger project...
>>
>> I'd rather start with some functions in the debuggee itself to be
>> searched for the type data to be displayed, e.g.
>>
>> string mago_visualizer(ref T data);
>> string mago_visualizer(T)(ref T data);
>>
>> or some sink-delegate-version to avoid allocations.
>>
>> mago will try to resolve these for T and its base classes. If it finds
>> one, it is called and the string result is displayed.
>
> I have no problem with that, anything that makes life easier is a + for
> me ;)
>
> A side note, intellisense shows all the possible invocations on a type.
> It would be nice to make a distinction of direct members, and such
>
> e.g., a list
>
> Type
> method1
> field1
> ...
> Base
> method1
> field1
> ...
> External
> ....
>
>
> When looking for a method that I'm not aware of I have to scroll through
> all the module imports(e.g., min, max, Date, abs, etc...). If all this
> stuff was at the button of the list and the more relevant stuff was at
> the top, it would be better. A line separator is all that is needed to
> distinguish.

I guess the less relevant stuff comes from matching UFCS functions with 
broad constraints. You can disable these on the language option page.

>
> Basically break the list in to derivation type and sub-sort
> alphabetically rather than using a flat list sorted alphabetically.

It can be quite confusing if you are looking for some of the "less 
relevant" functions by typing the first characters, but these don't 
appear due to non-overall sorting. Other suggestions have been to use 
coloring or different fonts.

>
> Probably something quite easy to do? Could be an option.

Unfortunately, adding something to the UI that is not available by the 
standard control usually means reimplementing the full control.