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 notifications@github.com 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?

[zzzz465]

is this feature still not implemented yet?

[MatthiasWinkelmann]

is this feature still not implemented yet?

Considering it's still open, best guess would be no, it's not implemented "yet". The notebook support is, however, really taking form and a rather close cousin.

Personally, I've started citing the VSCode team as a glorious example of the pure, undiluted, steamrolling power of a small but dedicated, highly professional, well-managed team of what I can only assume to be overqualified veterans who each made some unfortunate-but-excusable mistake early in the movie that had them assigned to this mission out there in the jungle that everyone considers a death trap but from which they are about to return, riding exotic animals and smoking funny cigars....

But, I guess, my perspective may not exactly match everyone's.

Still, as general rule, I've found a remarkable correlation between entitled requests for features to be implemented and the sudden appearance of entirely plausible reasons for said features being, unfortunately, not quite possible to implement at this time.

[kkukshtel]

Just want to +1 this to add to the conversation. Being able to do webview-esque things in a peek window using the underlying language server would offer some pretty incredible possibilities.

[HanSeoulOh]

My heart was broken when I found out that Facebook dropped nuclide support. The atom-ide together with hydrogen has been the ultimate data scientist's and research engineer's wet dream. I'm really hoping this becomes a thing for vscode as I'm seeing the writing on the walls that atom support is slowly being orphaned. @jrieken I'm hoping this get revisited soon as the functionalities remain very popular.

[Dermotholmes]

👀

[kkukshtel]

I'm wondering if this is less of a priority as Code fleshes out its Notebook support. Custom peeks would still be great but it's also hard to think of a case that isn't solved by Notebooks.

[Ghost4Man]

Some potential uses of custom peek widgets not covered by notebooks (notebooks are not ideal for larger codebases):

• one-way (read-only):

  • rich library/language help (with links, images, videos)
  • boolean truth table
  • expression/function plot inside a regular source code for a game/app (without needing to create a special notebook)
  • interactive preview of macro expansion / compile-time evaluation
  • exception info – nested/inner-exceptions, stack traces (expandable)
  • preview of selected Markdown/HTML

• two-way (read-write):

  • inline documentation above functions/classes with text/Markdown/WYSIWYG editor (while maybe keeping docs in separate files)
  • inline editors for colors/gradients/images (as alternative to hover)
  • array data visualized/editable as tables
  • settings/config panels for UI components, URL routing, ...
  • extensions could add things like task-list or comments – either inline or at the top of each file

[PEZ]

@jrieken :

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

Back when I read this the first time I didn't really understand what was meant by the peek experience. But now I think I do. I can only conclude that this wouldn't be as good as the suggestion. Personally I get confused when the peek appears and I find myself trying to avoid it. The suggestion in OP is something completely else, as.I read it. Especially if we use LightTable as an inspiration. There this kind of widget can start out almost as a line decoration, and the user can then chose to expand it and start drilling down, without causing (to me) anything near the confusion that the current peek experience in VS Code does. It is more like a sticky hover, and there can be several opened at the same time.

[bpringe]

As a maintainer of Calva, a Clojure extension, along with @PEZ, I second what he says in this comment above. It would be awesome if we had an experience as the OP describes and shows exists in other editors.

[kkukshtel]

I think to @PEZ's comment, why not both? Starting with extending the current peek experience to render a custom HTML view (pulling in language server hooks and other background processes?) and then move on to more specific custom widget type behavior. One thing I'd love to do (as a game developer), is to declare a public Sprite field in my code, then be able to peek into that and draw the sprite in paint widget that exists in peeking, and have that (through my own code) bind to that field. I know that requires a lot of backend work on my side and API work on the code team's side, but it would be a game changer if something like that would be possible.

[Timmmm]

Would this be easier if it only supported images? Obviously there are lots of interactive things people would like to do but I imagine just showing static images is the biggest reason to want this (#28083, #98194, #41775), and maybe that avoids the zooming and layout issues that were encountered when using a full web view.

[mnesarco]

In the mean time, I am trying something different here:

https://github.com/mnesarco/vscode.imagecomments

Images are shown in a side panel automatically based on cursor context.

[Thiti-Dev]

any workaround for this?

I am also struggling to display multiple lines by using the property -> contentText of ThemableDecorationAttachmentRenderOptions

[Linzecong]

any workaround for this?

I am also struggling to display multiple lines by using the property -> contentText of ThemableDecorationAttachmentRenderOptions

Me too!. Need something like 'virtual lines' to create a blank space to show something.

like this area

Is there such an API to create 'virtual lines' ?

[Thiti-Dev]

any workaround for this? I am also struggling to display multiple lines by using the property -> contentText of ThemableDecorationAttachmentRenderOptions

Me too!. Need something like 'virtual lines' to create a blank space to show something.

like this area

Is there such an API to create 'virtual lines' ?

For now, to make multiple-line works, I have to do some custom width calculation and break the line automatically by the use of white-space:initial, but this only works perfectly for the 2 line paragraph/string

[ihdavids]

Any update on this?

[asiloisad]

up

[anaderix]

upup

[Linzecong]

I noticed that Copilot is able to insert some "Virtual text". Does anyone know which API can achieve this? Like this

The decoration api can insert some "Virtual text" in one line. but i want to insert a block of "Virtual text"

[gulshan]

@Linzecong I think it is named "inline completion".