w3m text-mode web browser

Just trying to make a new post usking w3m text-mode/command line web browser.

The editing interface uses the vim edit mode, which I am unfortunately not familiar with. However it can, somehow, include graphics in text mode, I do not know by which technical miracle.

Under X11, it gets hold of the X11 handle for the X terminal that it's in, and then uses a call to XCopyArea to blit the image into the right place in the window containing the terminal.

Under windows, it instead uses a call to Gdiplus::Graphics::DrawCachedBitmap

Well it was under neither, just under the real command line (with no graphical interface service started).

Well, there's the framebuffer method also. That's by far the least magical.

But how come there's a frameuffer in console mode? I tought console mode had a text buffer and graphics mode a framebuffer (at least that's what makes most sense to me).

What you used wasn't likely a 80x25 VGA text mode, but a 1920x1080 KMS framebuffer mode (or whatever your screen is at). Was the font as big as in the old BIOS screens? If it wasn't, you were in a framebuffer mode.

We've long since stopped using the video card's native text mode hardware. The last time it was really useful was with SVGATextMode's final release 16 years ago; since then we've mostly grown framebuffer-based text modes. (And even now, that specific mechanism is mostly being deprecated in favor of the Kernel ModeSetting infrastructure)

Version 3 and up of VESA VBE has allowed deprecating all sorts of pure-VGA compatibility things. I wouldn't be surprised if modern video cards can't be configured to to draw a 16 color planar mode, and if the mode 3h text mode is a vestigial stub that does something really weird underneath.

Sure, that's no big surprise, but form a software p.o.w. it doesn't matter how the text mode is rendered in hardware, if this is done by a geniune chip or a piece of firmware that renders it to a modern framebuffer-based system.

So that means lynx just abuses the firmware underneath and uses it to write images to the framebuffer?

Yup, correct -- as I understand it, they just interact with the framebuffer "directly" (through the kernel in some fashion). There's even w3m-img that apparently will render images/etc. using the same methodology.

There are many of us who still prefer the old classic 80x25 text mode and not use framebuffers -- I find the latter to be incredibly slow during screen scrolling of text (dmesg output on Ubuntu is a good example), even on systems with dedicated framebuffers. But then again, I also don't use *IX machines as desktops/workstations, so my desire for an actual framebuffer is virtually nil (I'm of the "if you're gonna go that far, might as well just run X.org" stance).

At least in linux, the in-kernel VT100 emulator transparently updates the contents of the framebuffer in response to writes to /dev/tty. i.e. w3m thinks it's interacting with a dumb terminal, but w3m-img says "oh, hey, I'm in a framebuffer, let me go scribble all over everything" ... i.e. the point is that w3m-img breaks the abstraction.

w3m, sure? Not lynx or or the other ones that are just in the emulated text mode.

Before the KMS mess (linux's democratizing "no one can have a good interface, everyone must use the same awful one"), many of the in-kernel framebuffer drivers had hardware acceleration that made it feel as fast as the native text mode hardware.

Of course, the useful not-KMS drivers also date to when we had more than three serious video card vendors.

The better way to draw pictures on a terminal would be to use Sixel graphics (as far as I know, only xterm currently implements this feature).