Vscode: Custom peek widgets

[mikewl]

LightTable and Swift allow for inline evaluation which also places the results in line with the particular line of source which was evaluated.

A new widget would be necessary for this. This widget would be able to hold values or arrays or plots with arrays and plots requiring expansion to be shown fully as to not clutter the editor. The widget would not be dismissed upon losing focus and multiple widgets are possible in the editor.

https://github.com/JunoLab/atom-ink and https://github.com/nteract/hydrogen are two examples of this done in atom.

Below are two example images from Juno which is based on LightTable.

[joaomoreno]

A first good step would be to write an extension and use the registerHoverProvider API.

ping @jrieken

[mikewl]

A hover provider should make a decent stopgap for everything but arrays I think. Will see what can be done with that so long.

On 22 Feb 2016, at 11:34, João Moreno [email protected] wrote:

A first good step would be to write an extension and use the registerHoverProvider API.

ping @jrieken

—
Reply to this email directly or view it on GitHub.

[mikeball]

+1 This would be a great feature!

[jrieken]

Maybe we should think about making the peek experience more rich. Like allowing to preview an html document inside peek

[andyshand]

+1 also. Would love to work on an extension for inline evaluation of Typescript/Javascript using something like this.

Something similar to how Jetbrain's tools show inline results in a simple text representation as comments at the end of each line could also be good, but I think allowing more visual representations with arbitrary HTML would be much more valuable and obviously flexible.

I've made a few attempts at doing this myself but I don't really know where to start.

[mikeball]

I feel there's real value in being able to display results and other items like documentation on the same editor surface. I suspect this sort of "same surface" in line results will require core editor support.

more visual representations with arbitrary HTML would be much more valuable and obviously flexible.

Completely agree with @andrewshand, having the results be html with their own css would make it possible to for instance display exceptions in smaller red font contained in a box, or display docs just below a function/method name. While smaller/shorter items go well at the end of a row of text, larger inline results/errors/docs/etc need to be below and not overlay the lines below, just move lines down.

[jrieken]

We are exploring this in September and will likely make this happen in October - stay tuned and drop a line about your use-cases/requirements but keep the scope in mind pls.

[mikeball]

@jrieken It looks like sublime text just added something similar, Phantoms, which is worth looking at for ideas.

https://www.sublimetext.com/blog/articles/sublime-text-3-build-3124
http://www.sublimetext.com/docs/3/api_reference.html#sublime.Phantom

Also, can I ask a question, when you say "drop a line about use-cases/requirements", do you mean to post messages on this thread, or to send you messages directly?

[jrieken]

@mikeball drop a line here

The current thinking is to keep this simple and one-way'ed so very similar to the previewHtml command. The underlying implementation will likely use a web view which means full html+js+css available (isolated in a separate process). We still have to explore/revisit the technical limitations that has, like not being able to reparent a web-view et al

[mikeball]

Use Case REPL: This feature would be ideal to build language extensions that run integrated REPL's, specifically clojure (github.com/avli/clojureVSCode), but it should work for pretty much any language that can benefit from REPL interaction. I think it makes the act of coding much more intimate because you're not continually referencing consoles to determine what is happening.

Ideally for functions that return void, there would be a way to display a successful code evaluation. For functions that do return data, the ability to show small/short results on the same line, but then have longer/larger results wrap to new line would be nice. Most larger items might not be fully expanded(imaging a very long list of items) and for the editor to be able to expand in some fashion could be nice. For errors displaying them in red and formatted nicely would be good. For documentation it would be nice to display subtle text above a line, so perhaps a feature to show above or below an attached line, and perhaps attach to a column as well. One element of VS Code that does bother me from time to time is showing docs on mouse hover, it would be nice to show docs in a more persistent way for reference while working.

I believe it's important to have an option for results be "attached" to a line until they are dismissed in some fashion, say right click and hide, or perhaps a very small x in upper right to dismiss/close the window. So lines entered above would cause the result to move down with the line. It probably should auto-dismiss if the expression it's attached to is edited because it's no longer a valid result of the displayed expression. A way to clear/hide all results would also be nice.

Widgets that could be styled to appear as part of the editor surface would be nice so they allow focus to stay on the text/code and not be too visually distracting from the act of editing the actual code.

I can also see there being quite a lot of results open at once, so there might be concerns with memory usage.

[leaxoy]

Swift playground

[jrieken]

We have finished our exploration which was about using the webview-tag inside editors. Unfortunately it has many technical challenges (zooming bugs, layout bugs, reparenting etc) that we first have to analyse and understand better.

[mikeball]

@jrieken Thanks for the report, it's good to know status. Based on explorations so far do you believe that a feature like this can/will ever be added to vscode? Is it something that's still a goal to add at some point in the future?

[jrieken]

@mikeball This is still high up on our list

[kentaromiura]

@orta this looks interesting, maybe track this if you plan to implement https://github.com/facebook/jest/pull/2629 ?

[ckib16]

For ruby users looking for in-line evaluation, you can look at seeing is believing

VS Code implementation by @brandoncc : seeing_is_believing
Original gem by @JoshCheek : https://github.com/JoshCheek/seeing_is_believing

[mikeball]

Any news or updates on this feature? Is this simply not likely to happen because of need to change core editor rendering or something like that?

[davidanthoff]

One twist to this would be the ability to just show arbitrary HTML widgets between lines of code, i.e. those widgets would always be full width of the editor, but could have an arbitrary height.

That kind of feature would allow us to add something like the R Notebook feature in RStudio to the julia VS Code extension, something I have wanted to do for a while.

[mikeball]

@davidanthoff I'm in the same boat, I don't really care about nor want a full peek widget, just would like to be able to add small html snippets above/to the right and below some point in the editor and have the text/lines moved so that they not covered by the inserted html.

I have a sneaking suspicion that part of the low level problem is optimizations that allow smooth viewing on large files snapshot portions of the editor as an image, and thus are not easy or possible to pop a widget into. Personally I don't need to handle files more than a couple hundred lines long, but some insist in being able to open files millions of lines long.

Stumbled across another extension that would like this feature https://github.com/JuliaEditorSupport/julia-vscode/issues/178

[leocb]

Does this issue benefit from #43713 in any way? I believe now that the new webview API is almost ready, we should see some progress on this too?

[TomasHubelbauer]

I have the same question as @leocb. Looks like the web view can be only inserted as it's own view in the columns of the editor area, but not as a body of a peek window or (which we be the greatest) as something you could snap on top of a line and has full width of the editor and arbitrary height.

The last UX I strive for because it would enable very interactive experiences to be implemented - intermediate results.

[MatthiasWinkelmann]

I've been trying to find a way to render markdown and diagrams inline with the code. We have a lot of mathematical notations and flowcharts that should ideally be shown right in the comments, instead of just being linked.

I agree with the idea above by @davidanthoff to have full-width, variable-height regions. And @jrieken's description would also fit with my use cases.

Thanks for all your work!

[PEZ]

Is this still being considered, @jrieken? My Clojure extension, Calva, today uses :before and :after decorators to achieve _some_ level of inline evaluation. Looks like so:

But being able to display datasets for exploration would be so much richer and more useful. This lack keeps Clojure coders sticking with inferior code editors.

I keep looking at the tree views in the sidebar and wish I could use such views for this inline evaluation use case, complete with context menus and all.

[twadleigh]

Please, PLEASE, _PLEASE_! This!

This is the last piece of functionality that vscode needs before I'd be ready to go all-in with it. When it is, everything I want can be implemented in an extension.

I think I might be willing to invest some time to help make this happen if I could depend on a modicum of guidance from others with the capability but not necessarily the availability. I'll start by looking at #66418, of course, but my impression is that the right implementation for this is architecturally pretty different from that solution.

[MikeInnes]

FWIW, although the Juno support in LightTable and Atom was designed for arbitrary HTML, we haven't really made use of that. For plots and images, for example, we now have a dedicated plot pane and the inline result is just a tick to confirm that the block was evaluated.

For our purposes what we'd need, in order of priority, is:

1. Multi-line after-like decorators that expand to show their full content when clicked;
2. Some light formatting options and URLs (so we can turn paths in stack traces into links);
3. As a bonus, tree views for more complex data structures (as in the debug variables view or Chrome's devtools). Nice if it can load sub-trees lazily.

I suspect that'd cover the vast majority of what people want from this feature, while perhaps being easier to implement than general webviews.

[agigao]

Darn, I've tried PyCharm, Jupyer(lab, notebook), Sublime, Emacs, Vim, VSCode (Python), Atom + Hydrogen but Hydrogen is the highest standard of all; the way it does approach to data science. Live Share is a killer feature with calls and chat and only thing VSCode lacks is Hydrogen-like workflow, please make it happen!

[ctr26]

I'd be super grateful of this functionality, hydrogen is the only thing keeping me with atom

[flux627]

@ctr26 Would you call that a... hydrogen bond?

[sauvala]

This feature would be great to have. Clojure and other language users who uses REPL would benefit a lot from inline evaluation and structure navigation.

[kongdd]

Any solution for Python inline result?