Ticket #3532 (closed defect: duplicate)
Find File's line numbers are meaningless for parsed files
Reported by: | egmont | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | mc-core | Version: | master |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description
Have an uncompressed manual page in its raw *roff format, e.g. bash.1 residing in a directory.
Perform a Find File for some content that occurs in the manual, e.g. "tilde expansion". You'll see a couple of results appearing, along with line numbers.
Press F3 to view the file at one of these matching numbers. The expected string won't be there.
This is because line numbers are according to the raw file, whereas before displaying they are formatted by the *roff pipeline.
For similar reasons, there can be false positives (e.g. on manpage formatting keywords) or missed matches (e.g. gzipped files) as well.
Change History
Note: See
TracTickets for help on using
tickets.
What could be done?
Open the file in Raw mode rather than Parsed?
Parse the file before searching? Way too expensive.
Add a UI checkbox for this?
Open the file in Parsed mode, but always at the first line? Or try to see if it matches and then go to the first match?
Detect if a file would be parsed if opened, and report a single match only on the raw content, without a line number?
I'm really not sure.