better support for long lines (abbreviated, wrapping, etc)

[op2786]

Let's say I have a line like this:

sprintf_s(Buffer, 512, "Hello! Result=%d, Result2=%d, Result3=%d", LongFunctionName1(), LongFunctionName2(), LongFunctionName3());

I think this line and other lines long like this should be shown like this:

sprintf_s(Buffer,
    512,
    "Hello! Result=%d, Result2=%d, Result3=%d",
    LongFunctionName1(),
    LongFunctionName2(),
    LongFunctionName3());

Little things like those makes reading decompiler output way more easier.

[alexrp]

Those lines are identical?

(That said, totally agree that some lines in the output can get unreasonably long.)

[op2786]

Sorry, I fixed it now.

[jborean93]

It would also be great if this could also apply to function signatures and not just the inline code. For example instead of

int64_t SpAcquireCredentialsHandleW(LPWSTR pszPrincipal, LPWSTR pszPackage, uint32_t fCredentialUse, PLUID pvLogonID, struct CREDSSP_CRED* pAuthData,  SEC_GET_KEY_FN pGetKeyFn, PVOID pvGetKeyArgument, struct SecHandle* phCredential, int64_t* ptsExpiry)

It would could be configured to show

int64_t SpAcquireCredentialsHandleW(
    LPWSTR pszPrincipal,
    LPWSTR pszPackage,
    uint32_t fCredentialUse,
    PLUID pvLogonID,
    struct CREDSSP_CRED* pAuthData, 
    SEC_GET_KEY_FN pGetKeyFn,
    PVOID pvGetKeyArgument,
    struct SecHandle* phCredential,
    int64_t* ptsExpiry)

[alexrp]

FWIW, as BN is gaining more and more sidebar widgets (especially now with Sidekick) and the right sidebar is actually fully usable, I think this issue is becoming more pressing.

Signatures like this are just not very readable:

As the previous comment suggests, this would be much better:

void S1DataQueryStep::NarrowSearchSpace(
    struct S1DataQueryStep* this,
    int32_t keyIndex, 
    uint32_t nodeNameIndex,
    struct S1DataNodeIterator* children,
    int32_t* start,
    int32_t* count, 
    struct S1DataQueryContext* context)

(~Besides that, an option to not render the struct/union/enum tags in the linear view would also go a long way in saving precious screen real estate. I wonder if there's an existing issue tracking this?~ Ah, #3963.)

[psifertex]

I agree about the increasing need. We tentatively have this scheduled for the next stable accordingly--though take that with a bit of a grain of salt as we are often overly optimistic early in the dev cycle for a release.