Feature request: Line lens for pipeline steps

[rmunn]

#422 just gave me an idea. When I write a long, complex pipeline, I will often make a type error somewhere in the pipeline. What I've been doing to solve those type errors is to turn a pipeline into a series of let statements, so that the code lens will tell me what type my data is at each step of the pipeline. But it would be useful to be able to get code lens results on intermediate steps of the pipeline. E.g.,

[ 1..10 ]
|> List.map (fun i -> i * i)
|> List.map float
|> List.map (fun n -> n / 2.0)
|> List.map string

would display something like (if the comments below were actually code lens displays):

// int list
[ 1..10 ]
// int list
|> List.map (fun i -> i * i)
// float list
|> List.map float
// float list
|> List.map (fun n -> n / 2.0)
// string list
|> List.map string

Of course, in this trivial example, it's easy to follow the types "in your head". But when the pipelines involve more complex types like async<HttpContext option> or lists of lists that you're flattening with List.collect id, or other such complicated scenarios, then having code lens for each step of the pipeline would be handy instead of having to write:

let start = [1..10]
let step1 = start |> List.map (fun i -> i * i)
let step2 = step1 |> List.map float
// ... etc.

UPDATE: as mentioned in a comment below, I'd much rather use linelens now for this than codelens. E.g., I'd like to see something like the following for the trivial example:

[ 1..10 ] // int list
|> List.map (fun i -> i * i) // int list
|> List.map float // float list
|> List.map (fun n -> n / 2.0) // float list
|> List.map string // string list

With linelens, the drawback that @czifro mentions below would be almost entirely eliminated. (In some cases with long pipeline steps or types, the line lens might cause that one line to wrap, so there would be some cases where it could still increase the visual length of the file).

[czifro]

My only reservation is for the trivial scenario like your example code. If I have many functions and each use several pipe operators, the visual length of my file will be nearly doubled (it appears that code lens uses a full line height). I am not opposed to the idea, especially for the non-trivial scenarios, but if there was another way to do this that did not aesthetically bloat my IDE, I personally would prefer that. Sort of like:

where you could hover over/click on the dot to see such info? Just a thought.

[rmunn]

I forgot to mention that I'd want to have this feature OFF most of the time, and only toggle it on from time to time when I want to debug. What I was thinking is that it could have its own setting, separate from the global editor.codeLens setting, so that I could turn off the "pipeline code lens" option while keeping the current code lens behavior turned on.

But @czifro's comment made me think of another possibility: toggling the feature only for a certain range of code, say the currently-selected blocks. So I select the pipeline I want to examine more closely, hit whatever shortcut key I've defined (or pick the command from the F1 menu), and the pipeline code lens turns on only for those few lines.

[piaste]

@rmunn

When I write a long, complex pipeline, I will often make a type error somewhere in the pipeline. What I've been doing to solve those type errors is to turn a pipeline into a series of let statements, so that the code lens will tell me what type my data is at each step of the pipeline.

I must be missing something here. Since when does the code lens work for local declarations?

Or do you just turn every local variable into a class / module level declaration when you do this? If that's what you meant, then I would think showing local declarations in code lens should come before pipelines.

[rmunn]

@piaste - You're right. I must not have had VS Code open in front of me when I wrote that, because what I wrote makes no sense. What I meant to write was that I can hover over the let declaration to get its type signature, so by breaking up a pipeline into multiple let declarations I can see the types of the values flowing through the pipelines at each step -- and it would be nice to get a local code lens that did that for me, toggled by a shortcut key, to save me the time involved in rewriting a pipeline into a series of let statements.

[Krzysztof-Cieslak]

See my comment in other issue: #422 (comment)

[rmunn]

Now that #510 is merged, I wonder if that might provide a better UI for this idea? The implementation difficulties mentioned in #422 (comment) still apply, though.

[rmunn]

Having played with linelens a little bit, I now would MUCH rather this be implemented with linelens than with codelens, if someone does manage to implement this idea. I've updated the issue description accordingly.

[OkayX6]

Agree this is helpful.
Just for our information, here is a similar feature implemented JetBrains WebStorm in Typescript - apparently they only do it for standard library array operators (but the type displayed is the one in input).

[Krzysztof-Cieslak]

This is done.