Daniel Martí

We're not even sure if we want this feature or how it would work, see the previous discussion and the `NeedsInvestigation` label. This is also not a particularly good issue...

Thank you for opening this issue and raising a PR. I agree this would be a useful feature and indeed I planned for it some time ago as well. I...

Thanks for the update. Perhaps hold off on spending too much time on the PR, because I'm not yet convinced about how to design this feature. The way you designed...

> What wails needs is the ability to predict _at compile time,_ for any given package, public type, method or field, _which strings will be reported by Go's reflection methods._...

> However, it still reports obfuscated strings for package paths and type names, which are accessible through reflection as well. The reason why we need those is to be able...

I have just sent a PR, if you would like to give it a go: https://github.com/burrowers/garble/pull/904 We already supported deobfuscating type names, just like we did for method names and...

Thanks @fbbdev for your update, and particularly for the reproduction steps with Wails. I need to sit down and investigate that, probably with a second attempt at this. For the...

Still seems to happen as of 23f252784fe2e031dbc81d098709749477d04fb1: ``` exec cue eval -e result in.cue -- in.cue -- #Test: { name: string tests: [...#Test] } #Resolver: { parent?: #Test self=test: #Test...

As far as I can tell, the LSP is not yet ready for use. cc @myitcv

Still seems to happen as of v0.13.0-alpha.4.