show current lines in viewer

[x905]

its usefull to show current viewing lines in viewer, for example like: (727-774)/1511

[andrew_b]

You propose to make viewer slower and slower... The lines counting requests a lot of CPU resources espeсially in large files.

[x905]

hmm, all additional functions will make mc slower and slower ... )

ok, if this function is hard to implement (or it dramatically slows down modern cpu), then make possibility to switch to editor directly from viewer in current view position and back (like in far viwer key f6 works) - this feature is also needed, and i can see my wanted current line

[zaytsev]

It can be made optional and disabled by default.

[andrew_b]

Replying to x905:

hmm, all additional functions will make mc slower and slower ... )

ok, if this function is hard to implement (or it dramatically slows down modern cpu),

To count/show line number, you must scan the entire file. What about large file especially with multi-byte encoding? Look at discussion in #1585.

then make possibility to switch to editor directly from viewer in current view position and back (like in far viwer key f6 works) - this feature is also needed, and i can see my wanted current line

#2156

[angel_il]

to x905:
not all features make the viewer slower but
*that* a feature make the viewer really slowly...

[x905]

ok, "optional and disabled by default" - sounds good

for experiment: i opened my 2.867.327 bytes /var/log/messages for edit - and it opened just like in viewer; (on my slightly outdated Core2 6600 CPU)

i created this ticked after greaping through my sourses with find dialog; sourse files usually so little in size (max file about 2mb), that no slow down in viewer can be noticed

also voted for #2156

[gotar]

Replying to x905:

ok, "optional and disabled by default" - sounds good

Sounds bad - again, #1585.

for experiment: i opened my 2.867.327 bytes /var/log/messages for edit - and it opened just like in viewer; (on my slightly outdated Core2 6600 CPU)

On my calendar it's 2010 year now and less than 3 MB is not considered as _big_ file. Try with something like 300 MB at least.

[x905]

ok, if this makes viewer so slow, then i will wait for #2156

[andrew_b]

OK. Closed.

[gotar]

Actually this function can be implemented in a way that doesn't include full file scan or eat any I/O or CPU resources. I've created a patch (movement_position) that counts lines we actually move within a file and prints it with mcedit-like syntax. When one jumps to EOF (mcview_moveto_bottom) but entire file is not yet counted, it starts counting from there (so we got negative counts - this way we know how much from the end we got). This piece of code is finished and working well I think, maybe except display.c part - please review.

However there are other ways to move inside viewer: goto and search.
In case of goto 'Line number' option should be trivial to implement, but the other 3 would put us in unknown line - I suggest adding LAST/UNKN/SRCH marker the same way as EOF is handled, so it will show line count relative to this position (still it's better than nothing).
With search code we can do more, as file is actually scanned. This requires search function to return lines of code it scanned instead of simple TRUE/FALSE. Thus the second patch (search_position) as a demonstration of the idea. It's not finished nor clear - currently handles only forward search and breaks searching in mcedit (and probably others), I just need to know if it is a right way to do this, so please take a look and share your opinion.

They apply on 4.8.0-pre2 as well.

So for now the first one patch (with display.c reviewed and maybe LAST/UNKN/SRCH marker introduced) could go into official repo, as it's still better to know we start in EOF-60 line and see 34 next than nothing. Column position is kept so we only need to print it.

[andrew_b]

Replying to gotar:

Actually this function can be implemented in a way that doesn't include full file scan or eat any I/O or CPU resources. I've created a patch (movement_position) that counts lines we actually move within a file and prints it with mcedit-like syntax. When one jumps to EOF (mcview_moveto_bottom) but entire file is not yet counted, it starts counting from there (so we got negative counts - this way we know how much from the end we got). This piece of code is finished and working well I think, maybe except display.c part - please review.

Ok, let's consider a some example.

Open some file in viewer. Move to the some place in a middle of file. Close viewer. File position has remembered.

Open file again. At first, we don't know start line. In status line we can see something like L:0+52=52 /52+. /52+ means that file contains more than 52 lines. Ok. But how treat the 0+52 numbers? Whether the 1st digit is an absolute number of current line? Definitely no. Up/down scroll changes the initial 0 value to positive or negative side. In this case, we get the line number relative to unknown start line. Do we really need such info? I think, it will confuse users.

[gotar]

Replying to andrew_b:

Open some file in viewer. Move to the some place in a middle of file. Close viewer. File position has remembered.

Open file again. At first, we don't know start line. In status line we can see something like L:0+52=52 /52+. /52+ means that file contains more than 52 lines. Ok. But how treat the 0+52 numbers? Whether the 1st digit is an absolute number of current line? Definitely no. Up/down scroll changes the initial 0 value to positive or negative side. In this case, we get the line number relative to unknown start line. Do we really need such info? I think, it will confuse users.

It can be easily handled the same way as goto offset or search (without flow accounting implementation) I've mentioned above. All of these are entry points we won't know current line number, so we must mark position as relative. I've attached slightly modified patch that introduces enum of possible states.

Line counter is much more accurate than percent indicator (especially for large files) and much more readable than offset counter. I for example don't save viewer position and don't jump to offset, so the only relative counting I'm gonna see is after search (which can be handled in the future). However let's separate two things:

1. counting and state machine itself (even relative lines have input to total line count),
2. data display.

Whether relative position is actually displayed depends solely on display.c and could be disabled or made optional if (view->dpy_lines_status == LINE_COUNT_UNKNOWN).