Ticket #2371 (accepted enhancement)

Opened 6 years ago

Last modified 5 years ago

show current lines in viewer

Reported by: x905 Owned by: slavazanko
Priority: minor Milestone: Future Releases
Component: mcview Version: master
Keywords: Cc: zaytsev, gotar@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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

Attachments

mc-movement_position.patch (8.9 KB) - added by gotar 5 years ago.
mc-search_position.patch (10.2 KB) - added by gotar 5 years ago.
mc-movement_position_v2.patch (12.8 KB) - added by gotar 5 years ago.

Change History

comment:1 Changed 6 years ago by andrew_b

  • Priority changed from major to minor

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

comment:2 follow-up: ↓ 4 Changed 6 years ago by 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

comment:3 Changed 6 years ago by zaytsev

  • Cc zaytsev added

It can be made optional and disabled by default.

comment:4 in reply to: ↑ 2 Changed 6 years ago by 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

comment:5 Changed 6 years ago by angel_il

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

comment:6 follow-up: ↓ 7 Changed 6 years ago by 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

comment:7 in reply to: ↑ 6 Changed 6 years ago by gotar

  • Cc gotar@… added

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.

comment:8 Changed 6 years ago by x905

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

comment:9 Changed 6 years ago by andrew_b

  • Status changed from new to closed
  • Version 4.7.4 deleted
  • Resolution set to wontfix
  • Milestone 4.7 deleted

OK. Closed.

Changed 5 years ago by gotar

Changed 5 years ago by gotar

comment:10 follow-up: ↓ 11 Changed 5 years ago by gotar

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Branch state set to no branch

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.

comment:11 in reply to: ↑ 10 ; follow-up: ↓ 12 Changed 5 years ago by 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.

comment:12 in reply to: ↑ 11 Changed 5 years ago by 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).

Changed 5 years ago by gotar

comment:13 Changed 5 years ago by slavazanko

  • Owner set to slavazanko
  • Status changed from reopened to accepted

comment:14 Changed 5 years ago by andrew_b

  • Version set to master
  • Milestone set to Future Releases
Note: See TracTickets for help on using tickets.