mcview: color output (ansi escapes) support

[gotar]

This is similar to #28, however my approach is entirely different and much simpler. Instead of using editor's syntax highlighting (or better: apart from it) mcview should simply have the ability to display color control sequencies (similar to less -r/-R switches).

Having this we're almost done - all we need is some internal (via mcedit code) or external (like highlight package) formatter to colorize output. So for example we could define View=%view{ascii-color} to pass through "highlight --xterm256 --style=darkblue" command and that's it. %view{ascii} and %view{ascii-color} could be switched either in mc.ext/bindings file or some function within viewer itself.

Of course some movement issues would appear, but it should be enough to colorize only currently visible part of the screen or sth like this.

[gotar]

Oh, and just take a look how we did this in PLD: ​http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/lesspipe/lesspipe.sh
Also there is mainstream ​http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html with code2color experimental support, but highlight seems the best colorizer available ​http://www.andre-simon.de/

[zaytsev]

FYI: there's a very nice syntax highlighting library called Colorer ( ​http://colorer.sourceforge.net/mc.html ) ... They already have patches for mc.

Although it seems that it's no longer actively developed, it's what FAR use a syntax highlighter.

[gotar]

Nice, but it's only for editor (and I'm not sure how it is superior compared to native syntax highlighting). I'd like to have this feature on viewer, just like my 'less' has.

[egmont]

I was thinking about this while working on #3250, but decided not to address. I see two major problems.

• MC uses either ncurses or slang, meaning its capabilities are pretty much limited to the common features of them. Both of them use a small (256 or so) palette of preconfigured color pairs and can only use those (whereas nowadays most terminals support 256 colors, and some also support 16M true colors). This would mean we need to dynamically change the palette which is already cumbersome, and would be in trouble as soon as the file asks for more than ~180 color pairs to be displayed at the same time. MC should instead first migrate to a screen drawing library where there's no color palette at all and each cell stores its own colors (I'm not aware of any such library), or it should do its own screen drawing (just as "less" does). Or we should only recognize the legacy 8 colors, which sounds to me a stupid move in 2014.

• The current and my reimplemented viewer are both designed not to carry any state across a newline character. This makes it possible to scroll backwards and still display everything correctly (including the colors) by walking back up to the previous newline only and reparsing from that point. -R support would need us to carry the color across newlines, and hence when scrolling backwards we'd need to potentially reparse the whole file. This is not a problem with small files, but becomes a bit expensive with large but realistic files (couple of MBs), and mcview should even be able to reasonably display giant files (e.g. disk images) too, being able to quickly jump to the end etc. without consuming tons of CPU time or tons of memory.

[ossi]

seems like a straight duplicate of #31 to me.

[zaytsev]

Ticket #31 has been marked as a duplicate of this ticket.

[zaytsev]

You are right, thanks! I would close the original ticket though and edit this one - sorry about that - some discussion has happened here and more people are on CC.