You might be on to something here. I could see this editor working really well in a terminal environment.

You could try running it in neovim terminals.

At this point, the easier route to getting a text-based browser to support something like this would be creating a new one based on WebKit/Blink.

It would probably need to get the engine to draw to a fake screen buffer and run an OCR algorithm over that. And even if the OCR and layout worked well, there would be a lot other work necessary to get reasonable text based interactivity, though that's probably partially solved by projects like Vimium. Some interactions like dragging would likely never be supported.

Not easy at all, but somehow more reasonable than updating lynx to support all of today's new technologies. I wonder if anyone's already tried something like it.

I did! See brow.sh

It uses Firefox as a backend so can in fact run Wasm. However it doesn't use OCR, it uses the DOM to get precise coordinates for text nodes, this recreating a pure text representation of the page, using nothing but spaces and carriage returns for "formatting".

The vim browser demo uses pixels drawn to canvas though.

I just found Browsh[1] which seems to be basically this but with Gecko. It seems they don't need to do OCR which makes sense thinking about it more. Cool stuff. Haven't gotten to try it yet.

[1] https://www.brow.sh/

> OCR

Hey, dial back the blasphemy there. HTML is not PDF, it's usually made from text in the first place.

I'd guess you could force all text to use a monospace font, with fixed measures and line-height, and limit the width of the page. Then mostly dump the resulting text arrangement into the terminal.

Now, layouts from the various elements and CSS are probably a lot trickier, but snapping all margins and padding to multiples of a symbol's size should go a long way.

It seems that this could even be embedded at different levels in the browser: the layout engine or just the user's JS. (If JS can obtain the exact layout of text lines and elements―likely not, though, especially in forms. Maybe via devtools.)

> HTML is not PDF, it's usually made from text in the first place.

I don't know, man. Most websites would be smaller if they were replaced by a HD video of someone reading the contents.

> Hey, dial back the blasphemy there. HTML is not PDF, it's usually made from text in the first place.

Hey, dial back the blasphemy there. PDF is not an image, it’s usually[0] made from text in the first place.

As someone who has a bunch of experience both creating and parsing PDFs, it’s definitely very doable to extract the text content and render it in a similar way on a terminal. Yes, parsing the PDF format is much more painful than average HTML, but these days there’s libraries commonly available to assist.

[0] unless the PDF is a famous redacted DOJ document, then it’s a poorly scanned collection of image crammed into a PDF container.

How about this in emacs www mode?

It would need to have its HTTP code gutted and replaced with something that uses JS's XMLHttpRequest or the request API, but I think that's all you'd need to change.

Or write a C function called http_request, refactor all of Lynx to use just this one function, and then do something like

    #if PLATFORM === 'WASM'
    then
      fetch()
    else
      the actual sockets and stuff
    end

It would not be that simple, but yes.

What's a terminal? Every kid knows that anything that doesn't run in a browser can't be software.

Definitely doesn’t scale.

Oops, I forgot the /s at the end of my comment.

So did I.

You mean lynx.wasm?