Far viewer and editor

[mrsteel-2]

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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[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, mrsteel@... <mrsteel@...>:

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-talks@...
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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

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: irusskih@...
> Komu: "Common buzz on colorer" <colorer-talks@...>
> 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, mrsteel@... <mrsteel@...>:

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-talks@...
>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-talks@...
>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-talks@...
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,  <mrsteel@...> 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: irusskih@...
>  > Komu: "Common buzz on colorer" <colorer-talks@...>
>  > 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, mrsteel@... < >mrsteel@...>:
> > 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-talks@...
> > >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-talks@...
>  >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-talks@...
> 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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

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
_______________________________________________
colorer-talks mailing list
colorer-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[Igor Russkih]

2007/11/29, mrsteel@... <mrsteel@...>:

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
-------------------------------------------------------------------------
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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[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
_______________________________________________
colorer-talks mailing list
colorer-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

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
_______________________________________________
colorer-talks mailing list
colorer-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[Andrey Repin-2]

Здравствуйте, Уважаемый(-ая, -ое) 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-yahoo@...) суббота, 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
_______________________________________________
colorer-talks mailing list
colorer-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

>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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[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,  <mrsteel@...> 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-talks@...
> 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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

>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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[Alex Yaroslavsky]

FTP?

On Dec 2, 2007 2:41 PM,  <mrsteel@...> 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-talks@...
> 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-talks@...
https://lists.sourceforge.net/lists/listinfo/colorer-talks

[mrsteel-2]

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: trexinc@...
> Komu: "Common buzz on colorer" <colorer-talks@...>
> Datum: 02.12.2007 13:59
> Předmět: Re: Re[2]: Far viewer and editor
>
>FTP?
>
>On Dec 2, 2007 2:41 PM,  <mrsteel@...> 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-talks@...
>> 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-talks@...
>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