Closed burner closed 1 year ago
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.
Your suggestion sounds like it might be quite elegant. I'd definitely like to try that out!
turkeyman reported this on 2019-06-13T21:16:05Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=19958
CC List
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
.