Feature: Syntax highlighting

[SharpGIS]

It would be awesome if we could have syntax highlighting in the lister.

Yeah... I know there are plugins out there that does the same thing, but these listers either way overkill or they really suck. I LOVE the listers simplicity. The only thing I'm missing is coloring of specific words depending on the extension.

Basically there should just be another option in the lister menu for turning highlighting on/off. For quick access to a huge collection of highlighting languages and words, we could just reuse the syntax of the wordfiles in UltraEdit (maybe they could even share the same file).

[SanskritFritz]

I LOVE the listers simplicity.

I LOVE listers speed.

but these listers either way overkill or they really suck.

Can you give us an example?

[m^2]

I LOVE the listers simplicity.

I LOVE listers speed.

So do I. When I read SharpGIS's post I wanted to answer exactly this way. But is syntax highliting such slow down? I don't think it is.

[RID500]

I LOVE the listers simplicity.

Then let it as it is.

Just install one of this plugins
then you have syntax highlighting in the lister.
Just press F3 as usual.
Then press '1' for plain text or '4' for to switch to the installed plugins:

hpg_ed http://www.totalcmd.net/plugring/hpg_ed.html
Syn 1.5 http://www.totalcmd.net/plugring/syn.html

[ghisler(Author)]

But is syntax highliting such slow down?

Unfortunately yes. Lister would have to read the entire file from the beginning for correct syntax highlighting. Why? Immagine the situation where the file starts with a "start comment" sign. Then the entire file up to the next "end comment" sign would be a comment! That's why reading only a small part of the file (as lister currently does) wouldn't be sufficient.

[m^2]

But you CAN stop at the end of the screen. The comment wasn't closed? So mark everything as comment and remember this.
In this case it's even faster than html parsing - you can't stop there. The only thing that may slow it down is the necessity of parsing a syntax definition file.

[Sir_SiLvA]

Sorry but Syntax-Highlighting is definitiv a thing that belongs into a Plugin NOT into Lister as Lister should give
me a fastlock at a file - if i need a SH i use a plugin...

[m^2]

Sorry but Syntax-Highlighting is definitiv a thing that belongs into a Plugin NOT into Lister as Lister should give
me a fastlock at a file - if i need a SH i use a plugin...

So do I. But all the plugins with this feature that I know are slow
It's the only reason I'm for having this buit-in.
HTML view is quite similar thing to SH and it's implemented already. As in title: it's a future request, we have some time to discuss it.

[Sir_SiLvA]

So do I. But all the plugins with this feature that I know are slow

a) this depends on ur machine when ur usbstick is so slow its not tcs fault
b) building it in doenst make it faster

HTML view is quite similar thing to SH and it's implemented already. As in title: it's a future request, we have some time to discuss it.

This is not the same
There is C, C++, D, Pascal, CSS, etc, etc, so Building in SH make the Lister very much too slow...

[m^2]

So do I. But all the plugins with this feature that I know are slow

b) building it in doenst make it faster

Take a DVD image. Change it's extension to txt and open with lister (w/o plugins). Then turn off syntax highliting for .txt in SynPlus (if you have it). Open with SynPlus.
This is artificial example, but i.e. logs also can be really big.
Building SH in TC won't make it significantly faster, but efficient implementation is a thing that matters. As I said before, I don't know a fast plugin with this feature, which doesn't mean there's no such plugin. ( I've tested most plugins on totalcmd.pl / totalcmd.net. ) And I believe that Ghisler's version will be better.

HTML view is quite similar thing to SH and it's implemented already. As in title: it's a future request, we have some time to discuss it.

This is not the same
There is C, C++, D, Pascal, CSS, etc, etc, so Building in SH make the Lister very much too slow...

I wrote this before: It's a matter of reading a syntax definition. Is it such a problem? If you won't use a big ones, yours lister will be as fast as it's now ;D.
I checked how big are my SynPlus definitions:
The biggest one is Laser Scan User Language.hgl (145 550 bytes). Yes, it may slow lister down.
The biggest I may use one day: JSP.hgl (58 043 bytes). Still quite big.
All files 328: 4 258 462 bytes, which gives 12983,115854 bytes average. And this is definitely no problem.

I checked further, currently I have many editors

TextPad:
Max: 47 847
Average: 11371,864865 (37 files)

PSPad:
Max: 237 136 ( )
Average: 9023,2916667 (120 files)

Notepad++:
A single file with defs for 47 languages: 71 891 bytes, which gives 1529,5957447 b average.
(No, it's not a zip )

SciTe:
I'm not sure if these are definitions, but the biggest is 20 939 b, average: 1437,82 (50 files).

Conclusion: The biggest definitions will slow lister down. Average won't.
Choice of a proper format can significantly reduce a definition size - which I expect to be the biggest problem.

[Alextp]

2m^2
Besides slowdown of Lister, this will give a big increase of Totalcmd.exe size. I think, by 200-300 Kb.
Note that Ghisler should also make dialogs that allow to edit SHs.

[m^2]

2Alextp:
Good point. But I think you're too pesimistic here. Even uncompressed exe size increase shouldn't be so big, I think it would be possible to adapt most things from html parsing code (except dialogs, of course, but it's not that big). I doubt 100 kb increase with compressed exe. But even this is quite much. Too much? For me it's not, having this, I would be able to delete a plugin, so the size would be actually smaller.

The size of syntax definitions is also important here. Even a couple of basic ones (from N++) is 70 KB.

[Alextp]

But I think you're too pesimistic here. Even uncompressed exe size increase shouldn't be so big, I think it would be possible to adapt most things from html parsing code (except dialogs, of course, but it's not that big). I doubt 100 kb increase with compressed exe.

Well, you cannot adapt things from html parsing code.
It's much better to use one of wellknown SH components. Scintilla, for example.
And they have rather big size...

[m^2]

But I think you're too pesimistic here. Even uncompressed exe size increase shouldn't be so big, I think it would be possible to adapt most things from html parsing code (except dialogs, of course, but it's not that big). I doubt 100 kb increase with compressed exe.

Well, you cannot adapt things from html parsing code.
It's much better to use one of wellknown SH components. Scintilla, for example.
And they have rather big size...

I don't know Ghislers implementation, but I would write a lexer that takes grammar as parameter. Even if it would not be universal enough, it would be easily adaptable. The rest is output modification depending on the things comming from lexer - this is completely different, so definitely to be written from scratch.

But I agree that using components that are working already is usually the best way to go.
TBH I know nothing about such libraries.