Web overlays inside text buffers?

Hello everyone! Is it possible to have a web-based interactive overlay inside a text buffer in Emacs? Something similar in UX to how images or org-transclusion overlays are displayed inside org-mode buffers. I am looking specifically for in-place rendering, not in a separate buffer. My use case is rendering html export blocks inside an org file to have an interactive notebook like experience, without exporting the whole document to html and viewing it in a browser. This would allow one to use Emacs as a self-sufficient interactive environment, bringing interactive plots, boards, diagrams, graphs, tables etc. directly into already powerful text editing environment. This functionality exists *a priori* in web-based applications like Obsidian, VS Code (even with inline web-views), but those either become slower with each notebook cell, have json as a file format, or do not have serious text editing capabilities. I realize that such overlays are niceties, and one can always export and view the documents, but I believe that the described approach is alluring to many because it does not force one to split their thinking between creating and viewing. If there is no such package at the moment, I would be willing to implement it myself; however, I want to ask people who looked into Emacs rendering and text overlay capabilities if something of that sort is even possible. Or is it easier to rewrite Emacs GUI with something like Tauri? :) I am also happy to hear about other approaches or views on this problem which worked for you!

Someone more experienced, please correct me: - the way Emacs displays text is as cells with text properties. Font, size, bold, underline, unicode glyph, etc. - the way emacs displays images is similar to characters except they take up more space and the rendering is jankier. Eg if you turn on line numbers an image will take up half the screen and have a tiny line number in front of it, behaving as the only character on that line. - the way emacs displays PDFs is by converting it to a PNG and displaying that as above. The third-party package pdf-tools does the same thing but more efficiently and with better integration, but it's still a big ad-hoc character glyph. - Emacs can render html as its own rich text by parsing the html markup itself. This is how `M-x eww` works. This handles text properties decently, images passably, and layout and style abysmally. In addition, it does not do Javascript interpretation. - some versions of Emacs are compiled with a built-in graphical browser `xwidget-webkit`. This was added years ago as sort of a hack, and has not improved since. It can display any remote or local html, it is literally just webkit like most "minimal" browsers are based on, but the way it interoperates with emacs is not reliable, especially when on some platforms (windows!!!) you can't even get it at all. Needless to say, it occupies its own buffer. Tl;Dr: you will probably try to implement this yourself, and you will probably fail.

Thank you for the reply! This is a bit disheartening. I was hoping that it was possible with something like [EAF](https://github.com/emacs-eaf/emacs-application-framework). I think the easiest solution is to shift my mental model from "interactive notebook" to "source code for interactive notebook" and polish export configurations. Maybe also write a small application that would display a lightweight window/buffer containing a rendered html block on demand, just like a source code block would display, for instance, a matplotlib window with a plot. To imitate a notebook "feel" it might even place a clickable screenshot of the rendered contents back to the buffer as an overlay. The lack of rich interactive web elements inside of Emacs is a pain point for me, but Emacs is too powerful to trade it for VSCode or Obsidian just for such niceties.

And in principle if one then splits the original buffer around the image preview, then places the new buffer with rendered html into the split, and synchronizes location of the html buffer with scrolling of both splits, it is effectively an html overlay.

Xwidgets are supposed to be the answer to this IIUC, read this thread by the original author of the feature: https://lists.gnu.org/r/emacs-tangents/2015-11/msg00020.html. EDIT: You might be interested in https://github.com/Jimx-/emacs-gl. There was a reddit post about this too I think.

> some versions of Emacs are compiled with a built-in graphical browser xwidget-webkit. This was added years ago as sort of a hack, and has not improved since. It can display any remote or local html, it is literally just webkit like most "minimal" browsers are based on, but the way it interoperates with emacs is not reliable, especially when on some platforms (windows!!!) you can't even get it at all. Needless to say, it occupies its own buffer. Po Lu put a lot of work into making it stable. Apart from webkit version kludges, it should work fine now. About it occupying the entire buffer, see https://lars.ingebrigtsen.no/2021/11/09/finally-videos-in-eww/ where Lars describes the newly added in-buffer video player that eww has when built with xwidget. Also IIRC, a lot of kludges wrt webkit support had to do with how webkit wanted to render stuff and how Emacs wanted it to render stuff. >This is how M-x eww works. This handles text properties decently, images passably, and layout and style abysmally. In addition, it does not do Javascript interpretation. One man's trash is another man's treasure. ;-)

Thanks for the info on webkit! I stand corrected.