Goto line function in the viewer in TC

[Orion]

I find the viewer very useful as I often work with very big files (from half to several Gb). In contrast to even good editors the viewer handles these files very quick.
There is, however, one function that I often miss, which the editors have. You can go to a specific line and there is a line number indicator at the bottom of the text window.

Now, many times you only need an excerpt from a big file to check something. Often you have line number references in error or log files.
It would be really great if there was a line indicator in the viewer (e.g. that one line was in inverted colours) and a number telling what line it was. You could then move the line marker with arrows, page up/down home/end like now. And if there was even a Goto Line function it would great.
Even a simple line number indicator for the bottom line presently in the window would be a help.

I have looked through the viewer, but I don't seem to find any line number indication. I don't seem to fine one. Perhaps it could be considered for development.


Best regards,

Orion

[Clo]

2Orion
Hello, welcome on board !

¤ You can get a certain percentage (%) of the file using the menu % at the right-end of the menu-bar.
- displays a small dialog-box when clicking on the nn% displayed.
- shows the percentage of the file at the bottom of the screen.
- doesn't work for *.RTF (only) currently.
* Indeed, a "Go to line #…" should be nice too.

Kind regards,
Claude
Clo

[Sheepdog]

Maybe this plugin will help. I do not use that large files so I cannot say anything about the speed. But according to the remarks of other users you should give it a try.

sheepdog

[woefdram]

SynPlus has line number indicator as well as "go to line"

[icfu]

@Orion:
There's no way and it sounds very logically:
http://www.ghisler.ch/board/viewtopic.php?t=1271#9737

But, when you know the offset of the data you are interested in you can use the great little 8kb helper dsFO from http://members.ozemail.com.au/~nulifetv/freezip/freeware/ to extract the data you are interested in.

SynPlus/hpg_ed and other text editors are good choices for all "small" files only, they break down when facing 500MB files.

Icfu

[Orion]

@icfu

Okay, I hope that this feature could be considered for the viewer in future. It would be quite neat. I think that it could be added without too much performance penalty on the viewer.

When the viewer starts, it loads a part of the file. When loading that, it could just count the number of line breaks (or perhaps even any character that is specified in setup as a line break character). It could then place the line marker (a line of inverted text) at the first or last row in in the window. When the line marker is moved, the the line number indicator in the status bar of the window could change accordingly.

When using arrow, page up/dn or slider in the side to go to another location in the file (i.e. the window contents needs to change to the scroll), the number of line breaks would have to be counted, but I am certain it could be done without having to load the whole file into memory as the editors do.

[norfie]

[icfu]

@Orion:
You are right!

To make it work with text files ghisler would have to build a file index WHILE reading the file, that's all:

1st line break: offset a
2nd line break: offset b
3rd line break: offset c
etc...

So, when you want to go to line 345 in a text file the file would have to be read at least till CR/LF 345-1 and there is absolutely no need to load it in RAM completely.
After the file has been read till CR/LF 344 all line numbers from 2 to 345 could be directly accessed through the given offset in the index file.

In binary mode no index file is necessary because all ghisler has to know to be able to calculate the line number is the number of columns and the offset.

int (O/C+1)=L

O= offset
C= number of columns
L= line number

No unknown variables.

To make the index feature complete the index file could be optionally saved to harddisk to make it accessible in the future without reading the file again.

The only disadvantage is that the file index can grow very rapidly of course. The more CR/LFs the bigger the index file. And in the end the index file could probably even be bigger than the original file, we might have a problem then I think.

Anyway, I would love such a feature!

Icfu

[ghisler(Author)]

Line numbers will not be supported in native lister, you need to use one of the plugins. Why? I will explain it with an example: You have a 2 GB log file. You open it and jump to the end. Currently lister reads the last 32k of the file, finds the line starts, and displays the last lines. With line numbers, lister would have to read the entrie 2 GB and count the line breaks just to find out the correct line numbers.

You can get an idea of how long this would take by loading a bit larger file with e.g. hpg_ed or SynUS plugins.

[norfie]

[icfu]

@ghisler:
I have explained how you can realize it above.

@Orion and anyone interested::
I have just found a file viewer that does exactly what we want and more! It even has implemented the feature proposal of the index file being saved to disk, the feature list is impressive:
http://www.listxp.com/listxp_features.html

Simply GREAT!

Icfu

[Hacker]

icfu,

@ghisler:
I have explained how you can realize it above.

Hmm, I did not see an explanation concerning what should happen, when a user opens a 2GB file and presses End, like Christian said...(?)

TIA
Roman

[icfu]

Hmm, I did not see an explanation concerning what should happen, when a user opens a 2GB file and presses End, like Christian said...(?)

I think that

So, when you want to go to line 345 in a text file the file would have to be read at least till CR/LF 345-1 and there is absolutely no need to load it in RAM completely.

already explains that the file has to be read so when you want to go to the end of the file the whole file has to be read, that's pretty obvious, right?

I have also explained that line numbers in binary files are no problem at all because there are no unknown variables.

So, all we need is two checkboxes:
-show line numbers in binary mode
-show line numbers in text mode (Attention! File has to be read and will slow down viewing!)

Furthermore TC lister has to read the whole file anyway when using the search, so why not count the CR/LFs at the same time?

ListXP shows that it works even in 500MB files. The file can be viewed and searched already WHILE building the index and summing up the CR/LFs so there is NOT ONE negative aspect for the user.

Ghisler isn't interested to make the lister better. It's ok, I'm used to it.

Icfu

[norfie]

[icfu]

"Better" is an objective impression, sorry.
The simple solution is to use ListXP. I have dumped the lister into the bin.

Icfu