Far viewer and editor

[m***@centrum.cz]

Hello,



I'm sorry if someone already asked this, but the mail archive search doesn't work.



Could be the Colorer plug-in integrated with the Far viewer? The Far
viewer can display huge files, so that the Colorer plugin cannot depend
on syntax  analysis of the whole file. An incomplete information from
the displayed part of the file and its small neighbourhood would have
to be suffient for the Colorer to do its job.



More info:



As an experiment, I measured how long it takes to color the whole text
in Far editor. Up to about 6k lines/200kB file it takes about 1 sec per
1k lines for Far to open the colored file. For bigger files, Far opens
the file immediately, not waiting for the Colorer to finish - which
takes more than 10 secs. I experimented on .cpp and Far's .m4 files.
The colorer in Visual Studio colors these .cpp files immediately.



I didn't perform this experiment to benchmark the Colorer engine, I
don't know whether this is result of the Colorer slowliness, or a
restriction of the Far editor API. However it shows that syntax parsing
in the viewer cannot be done on the whole file, not even for small
files.



Thank you,

Martin.





-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Igor Russkih]

Martin,

Probably you are right, this could be possible. However there is a few
practical problems with this.

First, FAR doesn't have text coloring support in viewer (this could be
solved, since FAR is opensource now)
Second, partial parsing (which will be required in the viewer) often will
fail to correctly show syntax. many languages depends strongly on a context
(XML is an obvious example). For such a cases you may get a "red mess" of
syntax errors highlighing, because colorer will loose context information.

Beside these two problems I think there is no anything to prevent this
proposal.


2007/11/28, ***@centrum.cz <***@centrum.cz>:
>
> Hello,
>
>
>
> I'm sorry if someone already asked this, but the mail archive search
> doesn't work.
>
>
>
> Could be the Colorer plug-in integrated with the Far viewer? The Far
> viewer can display huge files, so that the Colorer plugin cannot depend
> on syntax analysis of the whole file. An incomplete information from
> the displayed part of the file and its small neighbourhood would have
> to be suffient for the Colorer to do its job.
>
>
>
> More info:
>
>
>
> As an experiment, I measured how long it takes to color the whole text
> in Far editor. Up to about 6k lines/200kB file it takes about 1 sec per
> 1k lines for Far to open the colored file. For bigger files, Far opens
> the file immediately, not waiting for the Colorer to finish - which
> takes more than 10 secs. I experimented on .cpp and Far's .m4 files.
> The colorer in Visual Studio colors these .cpp files immediately.
>
>
>
> I didn't perform this experiment to benchmark the Colorer engine, I
> don't know whether this is result of the Colorer slowliness, or a
> restriction of the Far editor API. However it shows that syntax parsing
> in the viewer cannot be done on the whole file, not even for small
> files.
>
>
>
> Thank you,
>
> Martin.
>
>
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> colorer-talks mailing list
> colorer-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>



--
Igor

[m***@centrum.cz]

Igor,

what kind of events and methods in particular are missing in the Far viewer API?
I haven't look at the Colorer source code, but according to the documentation it seems that once Colorer creates its internal line parsing structures, it never releases them, which could be a problem on huge files. Also, it seems that when you edit a file and you paste a piece of text at the file beginning, Colorer reparses everything, instead of just updating the internal parsing structures. This would have to be changed too, in my opinion. What do you think?

I'm asking because I would like to initiate these changes in Far, but for this I need more information.

> Second, partial parsing (which will be required in the viewer)
> often will fail to correctly show syntax. many languages depends
> strongly on a context (XML is an obvious example). For such
> a cases you may get a "red mess" of syntax errors highlighing,
> because colorer will loose context information.

Yes, but do you consider this fatal? In my experience, incorrect coloring afects only a few first lines, in the rest of file it gets corrected. But maybe I don't have sufficient imagination, my experience is restricted to such languages like C++, VisualBasic or XML only.

Thanks,
Martin.


______________________________________________________________
> Od: ***@gmail.com
> Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> Datum: 28.11.2007 21:06
> Pøedmìt: Re: Far viewer and editor
>
>
Martin,

Probably you are right, this could be possible. However there is a few practical problems with this.

First, FAR doesn't have text coloring support in viewer (this could be solved, since FAR is opensource now) >
Second, partial parsing (which will be required in the viewer) often will fail to correctly show syntax. many languages depends strongly on a context (XML is an obvious example). For such a cases you may get a "red mess" of syntax errors highlighing, because colorer will loose context information. >

Beside these two problems I think there is no anything to prevent this proposal.


2007/11/28, ***@centrum.cz < >***@centrum.cz>:Hello,



I'm sorry if someone already asked this, but the mail archive search doesn't work. >



Could be the Colorer plug-in integrated with the Far viewer? The Far
viewer can display huge files, so that the Colorer plugin cannot depend
on syntax analysis of the whole file. An incomplete information from >
the displayed part of the file and its small neighbourhood would have
to be suffient for the Colorer to do its job.



More info:



As an experiment, I measured how long it takes to color the whole text >
in Far editor. Up to about 6k lines/200kB file it takes about 1 sec per
1k lines for Far to open the colored file. For bigger files, Far opens
the file immediately, not waiting for the Colorer to finish - which
>takes more than 10 secs. I experimented on .cpp and Far's .m4 files.
The colorer in Visual Studio colors these .cpp files immediately.



I didn't perform this experiment to benchmark the Colorer engine, I >
don't know whether this is result of the Colorer slowliness, or a
restriction of the Far editor API. However it shows that syntax parsing
in the viewer cannot be done on the whole file, not even for small
>files.



Thank you,

Martin.





-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >
_______________________________________________
colorer-talks mailing list
colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks


--
  Igor > >-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>
>

[Alex Yaroslavsky]

Colorer's syntax handling is too advanced for highlighting in the
Viewer. The viewer only reads the the part of the file that it
displays (and thats how it supposed to work), because of that you can
only do simple keyword highlighting and maybe simple syntax checks on
a per line basis. Colorer is not well suited for that kind of
highlighting if I am not mistaken.

On Nov 29, 2007 10:16 AM, <***@centrum.cz> wrote:
> Igor,
>
> what kind of events and methods in particular are missing in the Far viewer
> API?
> I haven't look at the Colorer source code, but according to the
> documentation it seems that once Colorer creates its internal line parsing
> structures, it never releases them, which could be a problem on huge files.
> Also, it seems that when you edit a file and you paste a piece of text at
> the file beginning, Colorer reparses everything, instead of just updating
> the internal parsing structures. This would have to be changed too, in my
> opinion. What do you think?
>
> I'm asking because I would like to initiate these changes in Far, but for
> this I need more information.
>
>
> > Second, partial parsing (which will be required in the viewer)
> > often will fail to correctly show syntax. many languages depends
> > strongly on a context (XML is an obvious example). For such
> > a cases you may get a "red mess" of syntax errors highlighing,
> > because colorer will loose context information.
>
> Yes, but do you consider this fatal? In my experience, incorrect coloring
> afects only a few first lines, in the rest of file it gets corrected. But
> maybe I don't have sufficient imagination, my experience is restricted to
> such languages like C++, VisualBasic or XML only.
>
> Thanks,
> Martin.
>
>
> ______________________________________________________________
> > Od: ***@gmail.com
> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> > Datum: 28.11.2007 21:06
> > Předmět: Re: Far viewer and editor
>
>
> >
> >
> Martin,
>
> Probably you are right, this could be possible. However there is a few
> practical problems with this.
>
> First, FAR doesn't have text coloring support in viewer (this could be
> solved, since FAR is opensource now) >
> Second, partial parsing (which will be required in the viewer) often will
> fail to correctly show syntax. many languages depends strongly on a context
> (XML is an obvious example). For such a cases you may get a "red mess" of
> syntax errors highlighing, because colorer will loose context information. >
>
> Beside these two problems I think there is no anything to prevent this
> proposal.
>
>
>
> 2007/11/28, ***@centrum.cz < >***@centrum.cz>:
> > Hello,
> >
> >
> >
> > I'm sorry if someone already asked this, but the mail archive search
> doesn't work. >
> >
> >
> >
> > Could be the Colorer plug-in integrated with the Far viewer? The Far
> > viewer can display huge files, so that the Colorer plugin cannot depend
> > on syntax analysis of the whole file. An incomplete information from >
> > the displayed part of the file and its small neighbourhood would have
> > to be suffient for the Colorer to do its job.
> >
> >
> >
> > More info:
> >
> >
> >
> > As an experiment, I measured how long it takes to color the whole text >
> > in Far editor. Up to about 6k lines/200kB file it takes about 1 sec per
> > 1k lines for Far to open the colored file. For bigger files, Far opens
> > the file immediately, not waiting for the Colorer to finish - which
> > >takes more than 10 secs. I experimented on .cpp and Far's .m4 files.
> > The colorer in Visual Studio colors these .cpp files immediately.
> >
> >
> >
> > I didn't perform this experiment to benchmark the Colorer engine, I >
> > don't know whether this is result of the Colorer slowliness, or a
> > restriction of the Far editor API. However it shows that syntax parsing
> > in the viewer cannot be done on the whole file, not even for small
> > >files.
> >
> >
> >
> > Thank you,
> >
> > Martin.
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > >from Novell. From the desktop to the data center, Linux is going
> > mainstream. Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >
> > _______________________________________________
> > colorer-talks mailing list
> > colorer-***@lists.sourceforge.net
> > >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >
>
>
>
> --
> Igor >
> >-------------------------------------------------------------------------
>
>
> >SF.Net email is sponsored by: The Future of Linux Business White Paper
> >from Novell. From the desktop to the data center, Linux is going
> >mainstream. Let it simplify your IT future.
> >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >_______________________________________________
> >colorer-talks mailing list
> >colorer-***@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >
> >
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> colorer-talks mailing list
> colorer-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

Alex,

 
>The viewer only reads the the part of the file that it
>displays (and thats how it supposed to work)



I guess so. However, my idea is to read a little more lines then it is
displayed, say one page size before the beginning of the displayed
screen. This could "fix" the colors. Would it be inacceptable?



>Colorer is not well suited for that kind of
>highlighting if I am not mistaken.


Well, I don't know. But if it is this case, I hope Igor will tell us. As far as I know, Colorer is the only syntax highlighting plugin available for Far, at least in the FarPluginRing. Is there another alternative, then?

Thanks,
Martin.






-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Alex Yaroslavsky]

Hello, Common!

m>  
>>The viewer only reads the the part of the file that it
>>displays (and thats how it supposed to work)
m> I guess so. However, my idea is to read a little more lines then it is
m> displayed, say one page size before the beginning of the displayed
m> screen. This could "fix" the colors. Would it be inacceptable?
It won't solve the problem. But anyway, why do you need full syntax
highlighting in the viewer? Full syntax highlighting is usually needed
for real life files which you can just open in the editor. Viewer
highlighting is a nice bonus, but viewer is usually needed for very
large files or binary ones which do not need syntax highlighting and a
simple keyword highlighting will suffice for them.


>>Colorer is not well suited for that kind of
>>highlighting if I am not mistaken.
m>
m> Well, I don't know. But if it is this case, I hope Igor will tell us.
m> As far as I know, Colorer is the only syntax highlighting plugin
m> available for Far, at least in the FarPluginRing. Is there another
m> alternative, then?
There is another plugin, AirBrush, which is amazingly fast in spite of
supporting full syntax highlighting (hint to Igor :), and it is much
better suited for simple keyword highlighting. But anyway writing a
plugin that highlights text based only on keywords is a very simple
task.

P.S. On another note, the AirBrush plugin has a very fast engine for
highlighting text in the editor (much better than colorers), I once even
thought on rewriting colorer as a plugin to airbrush but never came to
it. I believe that combining its engine with colorers vast library of
hrc's will make a very efficient highlighting plugin for Far.

--
Bye,
Alex.



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

Hi all,

> Just open in colorer any colorer's HRC (xml) file and try to
> remove the
root <hrc> tag. This'll show you how colorer
> will behave in a
viewer now ;)

This depends on how the .hrc files are generated from .xsd schemas. If you set the allow-common-attr, allow-any-attr and allow-unknown-elements to "yes" in the xsd2hrc, Colorer behaves well. I don't think these attributes need to be set to "no" in the viewer. Very few languages have the same problem as you described, I think.

>But anyway, why do you need full syntax
>highlighting in the viewer? Full syntax highlighting is usually needed
>for real life files which you can just open in the editor.

I don't need full syntax highlighting, I just need some syntax highlighting.

> Viewer
>highlighting is a nice bonus, but viewer is usually needed for very
>large files or binary ones which do not need syntax highlighting and a
>simple keyword highlighting will suffice for them.

I use the viewer on the same files I use the editor - just to make sure that I don't edit them by mistake, and also the viewer is better suited for viewing than the editor. But yes, I also use it for viewing large binary files that don't need syntax highlighting at all.
I agree that simple keyword highligting + some bonus would be sufficient for the viewer. However, in my opinion it would take less work to adapt an existing plugin/library for this purpose than to develop a new one.

>There is another plugin, AirBrush, which is amazingly fast in spite of
>supporting full syntax highlighting (hint to Igor :), and it is much
>better suited for simple keyword highlighting. But anyway writing a
>plugin that highlights text based only on keywords is a very simple
>task.

Writing "a plugin" would be simple, but writing "a good configurable plugin" would take much more work.

I didn't notice the AirBrush plugin before, sorry. It belongs rather to the cathegory "a plugin", but if it was improved and integrated with the viewer, I would be certainly satisfied. By improving I mean that the Colorer supports many more "basic" languages, supports color schemas etc.

But the first step is to extend the viewer's API to enable coloring.

    Martin.




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Andrey Repin]

Здравствуйте, Уважаемый(-ая, -ое) Common buzz on colorer!

>> The viewer only reads the the part of the file that it
>> displays (and thats how it supposed to work)

mcc> I guess so. However, my idea is to read a little more lines then it is
mcc> displayed, say one page size before the beginning of the displayed
mcc> screen. This could "fix" the colors. Would it be inacceptable?

You miss the point that there is no lines in viewer. Only bytes.
*It* is the problem.


--
С уважением

Andrey Repin (hell-for-***@umail.ru) суббота, 01.12.2007, <17:35>
* Winamp finally shut up...


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

>You miss the point that there is no lines in viewer. Only bytes.
>*It* is the problem.


I'd like to know whether there are any arguments why not to change this?



On the other hand, the viewer must have some notion of lines already,
otherwise it wouldn't work the way it does. What it surely misses, are
"numbered" lines. The Colorer depends on line numbering, a workaround
would have to be done for that.



I have very little time to linger on something that you don't want in
Far. Therefore I ask first, whether there are any resons why not to
modify the viewer's API to enable syntax highlighting and similar
plugins. I surely won't program anything before consulting you, you
know Far internals much better than me.



Martin.





-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Alex Yaroslavsky]

A "real" viewer cannot have numbered lines, for example I tell the
viewer to jump to offset 5GB, it just goes there ignoring all the
bytes up to that point, and it does it fast which is what you need
from a viewer - to work fast with large files.

On Dec 2, 2007 1:28 PM, <***@centrum.cz> wrote:
>
> >You miss the point that there is no lines in viewer. Only bytes.
> >*It* is the problem.
>
>
> I'd like to know whether there are any arguments why not to change this?
>
>
>
> On the other hand, the viewer must have some notion of lines already,
> otherwise it wouldn't work the way it does. What it surely misses, are
> "numbered" lines. The Colorer depends on line numbering, a workaround
> would have to be done for that.
>
>
>
> I have very little time to linger on something that you don't want in
> Far. Therefore I ask first, whether there are any resons why not to
> modify the viewer's API to enable syntax highlighting and similar
> plugins. I surely won't program anything before consulting you, you
> know Far internals much better than me.
>
>
>
> Martin.
>
>
>
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> colorer-talks mailing list
> colorer-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

>A "real" viewer cannot have numbered lines, for example I tell the
>viewer to jump to offset 5GB, it just goes there ignoring all the
>bytes up to that point, and it does it fast which is what you need
>from a viewer - to work fast with large files.

Of course, I know that :-). What I meant was that "relative" line numbers are available, and they would have to be sufficient. When you scroll up, these line numbers could easily go to negative numbers. When you skip to another place in the file, the Colorer's cache would have to be cleared and the line counter set to zero again.

I have an idea how to do it *technically*. What I still don't know is whether there are any arguments why should I stop thinking about it. E.g. because a little more data would have to be read when used with FTP, etc. Or simply because you do not want this change in Far :-).

Martin.




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Alex Yaroslavsky]

FTP?

On Dec 2, 2007 2:41 PM, <***@centrum.cz> wrote:
>
> >A "real" viewer cannot have numbered lines, for example I tell the
> >viewer to jump to offset 5GB, it just goes there ignoring all the
> >bytes up to that point, and it does it fast which is what you need
> >from a viewer - to work fast with large files.
>
> Of course, I know that :-). What I meant was that "relative" line numbers are available, and they would have to be sufficient. When you scroll up, these line numbers could easily go to negative numbers. When you skip to another place in the file, the Colorer's cache would have to be cleared and the line counter set to zero again.
>
> I have an idea how to do it *technically*. What I still don't know is whether there are any arguments why should I stop thinking about it. E.g. because a little more data would have to be read when used with FTP, etc. Or simply because you do not want this change in Far :-).
>
>
> Martin.
>
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> colorer-talks mailing list
> colorer-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

I don't know, I thought that the same viewer is used when viewing files over slow connections from network, e.g. by FTP. Maybe I'm mistaken. Or maybe the whole file must be downloaded first before it can be viewed, I don't know, I don't use FTP.

Simply said, for the scenarios I use the viewer, I don't see a reason why the viewer cannot be modified to allow syntax highlighting. But I don't know all common scenarios, and that's why I'm asking and discussing here. :-)

Hope you understand,
Martin.


______________________________________________________________
> Od: ***@gmail.com
> Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> Datum: 02.12.2007 13:59
> Pøedmìt: Re: Re[2]: Far viewer and editor
>
>FTP?
>
>On Dec 2, 2007 2:41 PM,  <***@centrum.cz> wrote:
>>
>> >A "real" viewer cannot have numbered lines, for example I tell the
>>  >viewer to jump to offset 5GB, it just goes there ignoring all the
>>  >bytes up to that point, and it does it fast which is what you need
>>  >from a viewer - to work fast with large files.
>>
>> Of course, I know that :-). What I meant was that "relative" line numbers are available, and they would have to be sufficient. When you scroll up, these line numbers could easily go to negative numbers. When you skip to another place in the file, the Colorer's cache would have to be cleared and the line counter set to zero again.
>>
>> I have an idea how to do it *technically*. What I still don't know is whether there are any arguments why should I stop thinking about it. E.g. because a little more data would have to be read when used with FTP, etc. Or simply because you do not want this change in Far :-).
>>
>>
>> Martin.
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> colorer-talks mailing list
>> colorer-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>>
>
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

[Alex Yaroslavsky]

Main question is, why don't you use the editor?

On Dec 2, 2007 4:12 PM, <***@centrum.cz> wrote:
> I don't know, I thought that the same viewer is used when viewing files
> over slow connections from network, e.g. by FTP. Maybe I'm mistaken. Or
> maybe the whole file must be downloaded first before it can be viewed, I
> don't know, I don't use FTP.
>
> Simply said, for the scenarios I use the viewer, I don't see a reason why
> the viewer cannot be modified to allow syntax highlighting. But I don't know
> all common scenarios, and that's why I'm asking and discussing here. :-)
>
> Hope you understand,
> Martin.
>
>
> ______________________________________________________________
> > Od: ***@gmail.com
> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> > Datum: 02.12.2007 13:59
> > Předmět: Re: Re[2]: Far viewer and editor
>
>
> >
> >FTP?
> >
> >On Dec 2, 2007 2:41 PM, <***@centrum.cz> wrote:
> >>
> >> >A "real" viewer cannot have numbered lines, for example I tell the
> >> >viewer to jump to offset 5GB, it just goes there ignoring all the
> >> >bytes up to that point, and it does it fast which is what you need
> >> >from a viewer - to work fast with large files.
> >>
> >> Of course, I know that :-). What I meant was that "relative" line
> numbers are available, and they would have to be sufficient. When you scroll
> up, these line numbers could easily go to negative numbers. When you skip to
> another place in the file, the Colorer's cache would have to be cleared and
> the line counter set to zero again.
> >>
> >> I have an idea how to do it *technically*. What I still don't know is
> whether there are any arguments why should I stop thinking about it. E.g.
> because a little more data would have to be read when used with FTP, etc. Or
> simply because you do not want this change in Far :-).
> >>
> >>
> >> Martin.
> >>
> >>
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> SF.Net email is sponsored by: The Future of Linux Business White Paper
> >> from Novell. From the desktop to the data center, Linux is going
> >> mainstream. Let it simplify your IT future.
> >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >> _______________________________________________
> >> colorer-talks mailing list
> >> colorer-***@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >>
> >
> >-------------------------------------------------------------------------
> >SF.Net email is sponsored by: The Future of Linux Business White Paper
> >from Novell. From the desktop to the data center, Linux is going
> >mainstream. Let it simplify your IT future.
> >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >_______________________________________________
> >colorer-talks mailing list
> >colorer-***@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> colorer-talks mailing list
> colorer-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

I answered that question already several e-mails back:

"I use the viewer on the same files I use the editor - just to make sure
that I don't edit them by mistake, and also the viewer is better suited
for viewing than the editor. But yes, I also use it for viewing large
binary files that don't need syntax highlighting at all."

Martin.

______________________________________________________________
> Od: ***@gmail.com
> Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> Datum: 02.12.2007 15:22
> Pøedmìt: Re: Re[2]: Far viewer and editor
>
>Main question is, why don't you use the editor?
>
>On Dec 2, 2007 4:12 PM,  <***@centrum.cz> wrote:
>>  I don't know, I thought that the same viewer is used when viewing files
>> over slow connections from network, e.g. by FTP. Maybe I'm mistaken. Or
>> maybe the whole file must be downloaded first before it can be viewed, I
>> don't know, I don't use FTP.
>>
>>  Simply said, for the scenarios I use the viewer, I don't see a reason why
>> the viewer cannot be modified to allow syntax highlighting. But I don't know
>> all common scenarios, and that's why I'm asking and discussing here. :-)
>>
>>  Hope you understand,
>>  Martin.
>>
>>
>>  ______________________________________________________________
>>  > Od: ***@gmail.com
>>  > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
>>  > Datum: 02.12.2007 13:59
>>  > Pøedmìt: Re: Re[2]: Far viewer and editor
>>
>>
>>  >
>>  >FTP?
>>  >
>>  >On Dec 2, 2007 2:41 PM,  <***@centrum.cz> wrote:
>>  >>
>>  >> >A "real" viewer cannot have numbered lines, for example I tell the
>>  >>  >viewer to jump to offset 5GB, it just goes there ignoring all the
>>  >>  >bytes up to that point, and it does it fast which is what you need
>>  >>  >from a viewer - to work fast with large files.
>>  >>
>>  >> Of course, I know that :-). What I meant was that "relative" line
>> numbers are available, and they would have to be sufficient. When you scroll
>> up, these line numbers could easily go to negative numbers. When you skip to
>> another place in the file, the Colorer's cache would have to be cleared and
>> the line counter set to zero again.
>>  >>
>>  >> I have an idea how to do it *technically*. What I still don't know is
>> whether there are any arguments why should I stop thinking about it. E.g.
>> because a little more data would have to be read when used with FTP, etc. Or
>> simply because you do not want this change in Far :-).
>>  >>
>>  >>
>>  >> Martin.
>>  >>
>>  >>
>>  >>
>>  >>
>>  >>
>> -------------------------------------------------------------------------
>>  >> SF.Net email is sponsored by: The Future of Linux Business White Paper
>>  >> from Novell.  From the desktop to the data center, Linux is going
>>  >> mainstream.  Let it simplify your IT future.
>>  >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>  >> _______________________________________________
>>  >> colorer-talks mailing list
>>  >> colorer-***@lists.sourceforge.net
>>  >> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>>  >>
>>  >
>>  >-------------------------------------------------------------------------
>>  >SF.Net email is sponsored by: The Future of Linux Business White Paper
>>  >from Novell.  From the desktop to the data center, Linux is going
>>  >mainstream.  Let it simplify your IT future.
>>  >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>  >_______________________________________________
>>  >colorer-talks mailing list
>>  >colorer-***@lists.sourceforge.net
>>  >https://lists.sourceforge.net/lists/listinfo/colorer-talks
>>  >
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> colorer-talks mailing list
>> colorer-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/colorer-talks
>>
>>
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

[Alex Yaroslavsky]

Hello, Common!

m> I answered that question already several e-mails back:

m> "I use the viewer on the same files I use the editor - just to make sure
m> that I don't edit them by mistake, and also the viewer is better suited
m> for viewing than the editor. But yes, I also use it for viewing large
m> binary files that don't need syntax highlighting at all."
You can open the editor in locked mode (СtrlL) so you won't edit it by
mistake.

--
Bye,
Alex.



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

Hello.

I think that the word "viewer" is from "view", and the word "editor" from "edit". :-) Viewer is better suited for viewing files than editor.

Alex, you are still trying to persuade me that I should use the editor for viewing files. But you still didn't put any arguments against extending the viewer's API. Have you any? Please, share them.

Martin.

______________________________________________________________
> Od: ***@gmail.com
> Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> Datum: 02.12.2007 22:22
> Pøedmìt: Re[4]: Far viewer and editor
>
>Hello, Common!
>
>m> I answered that question already several e-mails back:
>
>m> "I use the viewer on the same files I use the editor - just to make sure
>m> that I don't edit them by mistake, and also the viewer is better suited
>m> for viewing than the editor. But yes, I also use it for viewing large
>m> binary files that don't need syntax highlighting at all."
>You can open the editor in locked mode () so you won't edit it by
>mistake.
>
>--
>Bye,
>    Alex.
>
>
>
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

[Igor Russkih]

Alex, if a man wants to use the viewer, why not to allow him? ;)

I only can say that colorer is quite a suitable tool for such a task
(surely with a bit of tuning).

As for the FAR manager itself - believe this question is not for this
thread, Martin, you better visit
http://groups.google.com/group/fardeven and ask your question there...



2007/12/3, ***@centrum.cz <***@centrum.cz>:
> Hello.
>
> I think that the word "viewer" is from "view", and the word "editor" from
> "edit". :-) Viewer is better suited for viewing files than editor.
>
> Alex, you are still trying to persuade me that I should use the editor for
> viewing files. But you still didn't put any arguments against extending the
> viewer's API. Have you any? Please, share them.
>
> Martin.
>
> ______________________________________________________________
> > Od: ***@gmail.com
> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> > Datum: 02.12.2007 22:22
> > Předmět: Re[4]: Far viewer and editor
> >
> >Hello, Common!
> >
> >m> I answered that question already several e-mails back:
> >
> >m> "I use the viewer on the same files I use the editor - just to make
> sure
> >m> that I don't edit them by mistake, and also the viewer is better suited
> >m> for viewing than the editor. But yes, I also use it for viewing large
> >m> binary files that don't need syntax highlighting at all."
> >You can open the editor in locked mode () so you won't edit it by
> >mistake.
> >
> >--
> >Bye,
> > Alex.
> >
> >
> >
> >-------------------------------------------------------------------------
> >SF.Net email is sponsored by: The Future of Linux Business White Paper
> >from Novell. From the desktop to the data center, Linux is going
> >mainstream. Let it simplify your IT future.
> >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >_______________________________________________
> >colorer-talks mailing list
> >colorer-***@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >
>
>


--
Igor
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

Igor,

I am still in this conference because I was hoping we would be solving a different sort of issues -  more technical ones :-(.

Martin.

______________________________________________________________
> Od: ***@gmail.com
> Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> Datum: 03.12.2007 12:01
> Pøedmìt: Re: Re[4]: Far viewer and editor
>
>Alex, if a man wants to use the viewer, why not to allow him? ;)
>
>I only can say that colorer is quite a suitable tool for such a task
>(surely with a bit of tuning).
>
>As for the FAR manager itself - believe this question is not for this
>thread, Martin, you better visit
>http://groups.google.com/group/fardeven and ask your question there...
>
>
>
>2007/12/3, ***@centrum.cz <***@centrum.cz>:
>> Hello.
>>
>> I think that the word "viewer" is from "view", and the word "editor" from
>> "edit". :-) Viewer is better suited for viewing files than editor.
>>
>> Alex, you are still trying to persuade me that I should use the editor for
>> viewing files. But you still didn't put any arguments against extending the
>> viewer's API. Have you any? Please, share them.
>>
>> Martin.
>>
>> ______________________________________________________________
>> > Od: ***@gmail.com
>> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
>> > Datum: 02.12.2007 22:22
>> > Pøedmìt: Re[4]: Far viewer and editor
>> >
>> >Hello, Common!
>>  >
>>  >m> I answered that question already several e-mails back:
>>  >
>>  >m> "I use the viewer on the same files I use the editor - just to make
>> sure
>>  >m> that I don't edit them by mistake, and also the viewer is better suited
>>  >m> for viewing than the editor. But yes, I also use it for viewing large
>>  >m> binary files that don't need syntax highlighting at all."
>>  >You can open the editor in locked mode () so you won't edit it by
>>  >mistake.
>>  >
>>  >--
>>  >Bye,
>>  >    Alex.
>>  >
>>  >
>>  >
>>  >-------------------------------------------------------------------------
>>  >SF.Net email is sponsored by: The Future of Linux Business White Paper
>>  >from Novell.  From the desktop to the data center, Linux is going
>>  >mainstream.  Let it simplify your IT future.
>>  >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>  >_______________________________________________
>>  >colorer-talks mailing list
>>  >colorer-***@lists.sourceforge.net
>>  >https://lists.sourceforge.net/lists/listinfo/colorer-talks
>>  >
>>
>>
>
>
>--   Igor
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

[Igor Russkih]

Martin,

All you've just said about viewer architecture - for me looks good.
Including pseudo line numbering, partial highlighting etc. With this
you may setup colorer to work quickly over any-sized file.

In case you have any more detailed questions about colorer (not FAR
;-) - you are welcome.

2007/12/3, ***@centrum.cz <***@centrum.cz>:
> Igor,
>
> I am still in this conference because I was hoping we would be solving a
> different sort of issues - more technical ones :-(.
>
> Martin.
>
> ______________________________________________________________
> > Od: ***@gmail.com
> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> > Datum: 03.12.2007 12:01
> > Předmět: Re: Re[4]: Far viewer and editor
> >
> >Alex, if a man wants to use the viewer, why not to allow him? ;)
> >
> >I only can say that colorer is quite a suitable tool for such a task
> >(surely with a bit of tuning).
> >
> >As for the FAR manager itself - believe this question is not for this
> >thread, Martin, you better visit
> >http://groups.google.com/group/fardeven and ask your question there...
> >
> >
> >
> >2007/12/3, ***@centrum.cz <***@centrum.cz>:
> >> Hello.
> >>
> >> I think that the word "viewer" is from "view", and the word "editor"
> from
> >> "edit". :-) Viewer is better suited for viewing files than editor.
> >>
> >> Alex, you are still trying to persuade me that I should use the editor
> for
> >> viewing files. But you still didn't put any arguments against extending
> the
> >> viewer's API. Have you any? Please, share them.
> >>
> >> Martin.
> >>
> >> ______________________________________________________________
> >> > Od: ***@gmail.com
> >> > Komu: "Common buzz on colorer" <colorer-***@lists.sourceforge.net>
> >> > Datum: 02.12.2007 22:22
> >> > Předmět: Re[4]: Far viewer and editor
> >> >
> >> >Hello, Common!
> >> >
> >> >m> I answered that question already several e-mails back:
> >> >
> >> >m> "I use the viewer on the same files I use the editor - just to make
> >> sure
> >> >m> that I don't edit them by mistake, and also the viewer is better
> suited
> >> >m> for viewing than the editor. But yes, I also use it for viewing
> large
> >> >m> binary files that don't need syntax highlighting at all."
> >> >You can open the editor in locked mode () so you won't edit it by
> >> >mistake.
> >> >
> >> >--
> >> >Bye,
> >> > Alex.
> >> >
> >> >
> >> >
> >>
> >-------------------------------------------------------------------------
> >> >SF.Net email is sponsored by: The Future of Linux Business White Paper
> >> >from Novell. From the desktop to the data center, Linux is going
> >> >mainstream. Let it simplify your IT future.
> >> >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >> >_______________________________________________
> >> >colorer-talks mailing list
> >> >colorer-***@lists.sourceforge.net
> >> >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >> >
> >>
> >>
> >
> >
> >-- Igor
> >-------------------------------------------------------------------------
> >SF.Net email is sponsored by: The Future of Linux Business White Paper
> >from Novell. From the desktop to the data center, Linux is going
> >mainstream. Let it simplify your IT future.
> >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> >_______________________________________________
> >colorer-talks mailing list
> >colorer-***@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/colorer-talks
> >
>
>


--
Igor
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Andrey Repin]

Здравствуйте, Уважаемый(-ая, -ое) Common buzz on colorer!

mcc> I think that the word "viewer" is from "view", and the word "editor" from
mcc> "edit". :-) Viewer is better suited for viewing files than editor.

mcc> Alex, you are still trying to persuade me that I should use the editor
mcc> for viewing files. But you still didn't put any arguments against
mcc> extending the viewer's API. Have you any? Please, share them.

Speaking about Viewer API You every time ends in the "read a bit more bytes
from file". But never answer on question "how much more"? If You try to answer
it, in many situations that answer will be "whole file" actually.
What in fact rolling us back to the comparison with Editor and difference
becomes very small, mostly close to invisible.
So, if You want proper colouring - go to Editor, it already have all required
API and features.


--
С уважением

Andrey Repin (hell-for-***@umail.ru) понедельник, 03.12.2007, <14:21>
* Winamp finally shut up...


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[m***@centrum.cz]

Andrey,

in one of my first posts here I wrote:

"my idea is to read a little more lines then it is

displayed, say one page size before the beginning of the displayed

screen. This could "fix" the colors."

...and later I added some details.

But as Igor said, we'd better move this discussion to a Far forum. I'll prepare a proposal and let you know. Unfortunately, I don't think I'll make it before Christmass, my time is very limitted and I have other obligations.

Best regards,
Martin.


______________________________________________________________
> Od: hell-for-***@umail.ru
> Komu: Common buzz on colorer <colorer-***@lists.sourceforge.net>
> Datum: 03.12.2007 12:30
> Pøedmìt: Re[6]: Far viewer and editor
>
>, (--Common buzz on colorer!
>
>mcc> I think that the word "viewer" is from "view", and the word "editor" from
>mcc> "edit". :-) Viewer is better suited for viewing files than editor.
>
>mcc> Alex, you are still trying to persuade me that I should use the editor
>mcc> for viewing files. But you still didn't put any arguments against
>mcc> extending the viewer's API. Have you any? Please, share them.
>
>Speaking about Viewer API You every time ends in the "read a bit more bytes
>from file". But never answer on question "how much more"? If You try to answer
>it, in many situations that answer will be "whole file" actually.
>What in fact rolling us back to the comparison with Editor and difference
>becomes very small, mostly close to invisible.
>So, if You want proper colouring - go to Editor, it already have all required
>API and features.
>
>
>--
>r> >
>    Andrey Repin (hell-for-***@umail.ru) 03.12.2007, <14:21>
> * Winamp finally shut up...
>
>
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell.  From the desktop to the data center, Linux is going
>mainstream.  Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>colorer-talks mailing list
>colorer-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/colorer-talks
>

[Igor Russkih]

2007/11/29, ***@centrum.cz <***@centrum.cz>:
>
> Igor,
>
> what kind of events and methods in particular are missing in the Far
> viewer API?


As far as I know FARs viewer just doesn't support any 'coloring'. There were
attempts to do this, however I don't know the latest status.

I haven't look at the Colorer source code, but according to the
> documentation it seems that once Colorer creates its internal line parsing
> structures, it never releases them, which could be a problem on huge files.
> Also, it seems that when you edit a file and


Colorer is quite a flexible in this area. You may choose the desired
strategy based on your task. In the editor it is just inefficient to store
only visible part of source code - user may change and navigate the source
in random - and each time text reparsing is quite slow. Some of FAR colorer
old versions provided this model, but it was not good.
Actually thats a tradeoff - between the amount of memory colorer spend on
its internal structures and the amount of CPU time, colorer needs to reparse
text if it drops these structures.


> you paste a piece of text at the file beginning, Colorer reparses
> everything, instead of just updating the internal parsing structures. This
> would have to be changed too, in my opinion. What do you think?


This question is more complex. Yes, colorer reparses the text (not
everything, but from the point of modification).
This is limitation of the current parser and of how it is implemented.

I've heard of systems with true incremental parsing (some are in scientific
research domain) - thats quite a complex problem to implement such a model.

Note also that even if implemented, there always exist cases when full
reparse is required (just imagine /* comment start insertion at the start of
the source text - thats a most trivial example). Therefore such an "true"
incremental in reality may not give a great boost. It may be helpful only in
'internal' text updates, which do not modify the context structure of the
text.

I'm asking because I would like to initiate these changes in Far, but for
> this I need more information.
>
> > a cases you may get a "red mess" of syntax errors highlighing,
> > because colorer will loose context information.
>
> Yes, but do you consider this fatal? In my experience, incorrect coloring
> afects only a few first lines, in the rest of file it gets corrected. But
> maybe I don't have sufficient imagination, my experience is restricted to
> such languages like C++, VisualBasic or XML only.


Just open in colorer any colorer's HRC (xml) file and try to remove the root
<hrc> tag. This'll show you how colorer will behave in a viewer now ;)

As Alex correctly noticed:

> Colorer's syntax handling is too advanced for highlighting in the
> Viewer. The viewer only reads the the part of the file that it
> displays (and thats how it supposed to work), because of that you can
> only do simple keyword highlighting and maybe simple syntax checks on
> a per line basis. Colorer is not well suited for that kind of
> highlighting if I am not mistaken.
>

Thats simultaneously a benefit and a problem in colorer. Many syntaxes in
colorer are too complex. Some of them, like XML - are even full featured
parsers over original grammar. And they don't like to loose their context -
what is happening in the Viewer.

The solution here may be in implementing (or, even, describing) alternative
'lightweight' HRC grammars to be used in the Viewer. Another benefit from
this lies in possible usage of such a grammars in a 'quick' editor parsing -
when source text is huge and where currently colorer works very slowly.

Finally, I don't think colorer is not suitable to be used in viewer. The
point is that it should be tuned up for such a task.

--
Igor