Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[David De La Harpe Golden]

Alan Mackenzie wrote:

> It's a big deal for me.  Probably for lots of other TTY users, too.


These days, a lot text terminal emulators support 256 color mode. 
Unfortunately, the linux kernel console in particular doesn't seem to, 
but framebuffer (rather than hardware text mode) consoles on PC SVGA and 
similar hardware certianly *should* be able to in principle, it's 
possible just no-one's bothered writing the support.  Hmm.

>  And
> if font-locking is secondary, surely region highlighting is tertiary?

? Stuff is still legible without font locking, you can't even
see the region without region highlighting...

> No, not at all.  On the specific matter of the interaction between region
> hilighting and font-locking/hi-locking, I raised a bug report last
> summer, as requested by Stefan.  Until yesterday there had been no
> discussion of it at all, as far as I am aware.

I thought I posted something about the IMO nicest solution being to 
allow alphablending computation to mix the various foreground and 
background colors coming in from the overlaid faces somewhere around 
face realization time rather than just having higher priority override 
lower priority, but maybe I hallucinated actually saying that publically 
or thought I'd wait till I had a patch to do it.

Such a solution still wouldn't work exactly amazingly on an 8-color 
terminal to solve your "hi-lock background popping" problem, but would 
on 256 color text terminal or bitmap gui emacs - i.e. the region face 
could supply a translucent-looking tint instead of nuking the background 
(and maybe foreground).