Option to hide select module namespace prefixes from symbols?

[dlangBugzillaToGithub]

turkeyman reported this on 2019-06-13T21:16:05Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=19958

CC List

• r.sagitario

Description

So, compared to debugging C++, I'm finding that the fully-qualified names make understanding code a lot harder in a lot of cases.
Most of the time when I'm stepping code, all I can see if long namespaces before the panel runs out of horizontal space and truncates.

Consider the callstack view; you can often only see the namespace and not the actual function name (because the namespace is on the left), same story with the 'Type' column on the right of the watch window, you can usually only see the namespace, items in the __vfptr list, the base class members of classes, etc. Basically everywhere a symbol appears, D symbol names are so long, there's a chance it's truncated before you can see the useful bit.

I think when you're iterating in a codebase, you can assume the namespace prefix, so it'd be great if we had some way to specify a set of namespace prefixes that would be removed from symbol names, allowing us to see the useful part more easily?

One challenge is that this mechanic should be project-local, so shouldn't be a VisualD global configuration. Perhaps it could be specified in the project file and fed into the debugger when you launch for that configuration?
Alternatively, it could be a file in the root directory of your project that you commit to source control, like .gitignore or .travis.yml.

[dlangBugzillaToGithub]

r.sagitario commented on 2019-06-15T12:44:41Z

It doesn't look to bad for me, but that very much depends how much screen area you allow the respective windows to have and what your package hierarchy looks like. I remember having similar issues debugging D_Parser in C#, though.

How about dropping common scope information with the fully qualified function name? E.g. when debugging function dmd.root.filename.addExt symbol dmd.root.rmem.mem would be shortened to rmem.mem, and its type to rmem.Mem.

That doesn't work with the functions shown on the callstack. I just noticed that dmd even generates a FQN even for extern(C/C++) function.

[dlangBugzillaToGithub]

turkeyman commented on 2019-06-15T18:32:44Z

Your suggestion sounds like it might be quite elegant. I'd definitely like to try that out!