Fixed Hex mode width calculations in Viewer.

[MKadaner]

Summary

Fixed a few places where the line width in the Viewer Hex mode was assumed to be 80 even though the number of bytes per line can now be changed by the user.

Also, some renaming and refactoring.

References

0ecc671

Checklist

• I have followed the contributing guidelines.
• I have discussed this with project maintainers:
  
  If not checked, I accept that this work might be rejected in favor of a different great big ineffable plan.
  

[alabuzhev]

Could you please give an example of an issue fixed by this change?

[MKadaner]

Could you please give an example of an issue fixed by this change?

Here is a problematic scenario:

• In the Viewer, open a text file containing a relatively long line, say 350 characters.
• Press F4 to switch to Hex mode.
• Press Ctrl+Alt+Left to reduce the width of Hex view to 8 bytes per line.
• Press F4 again to switch to Text mode and F2 to disable line wrap.
• Resize Far window width to 30 columns.
• Press Ctrl+Shift+Right to position the screen to the end of the longest line.
• Press F4 to switch to Hex mode.

Observe that the Far window is empty, and the Hex dump completely disappears. In fact, the dump now is far beyond the left edge of the window.

One can argue that this issue is "by design," because the Viewer tries to preserve the horizontal position of the content while switching between view modes. However, the ostentatious intent of the existing code is to make sure the Hex dump is always visible. I think that the latter behavior is more important and should override "preserving horizontal position."

Another concern is Viewer::XYfilepos, case VMT_HEX. The code here translates the X mouse click coordinate to the byte offset. The code obviously assumes that Hex dump is always 16 bytes per line. With user-customizable number of bytes per line in Hex dump, it is simply not true. Unfortunately, I cannot describe the scenario when this issue becomes visible.

More importantly, I think that any particular visualization issue notwithstanding, it is plain wrong to have the width of Hex view hard coded to 80 columns in several places while the actual view width is variable.

Last but not the least. I stumbled upon this issue while I was about to introduce a far:config to reverse the horizontal scrolling direction. I absolutely could not understand what was going on in two or three places in Viewer implementation, so I could not easily generalize the code to handle the swap direction option. I spent substantial time to reverse engineer the code. This PR is the outcome of this effort.

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[MKadaner]

I looked through sonarcloud's warnings. All of them are preexisting issues except for:

• Move this #include directive to the top of the file. - Expected?
• Use "std::array" or "std::vector" instead of a C-style array. - It looks like std::array here requires either specifying the array size explicitly or putting test_data on each line. Neither seems to be a better alternative to C-style array.

Let me know, if you want me to fix any of these issues, even preexisting. I'll do your bid.

[alabuzhev]

Please ignore those warnings.

[alabuzhev]

I absolutely could not understand what was going on in two or three places in Viewer implementation

Ah yes, it's... tangled, to put it mildly.
Thanks.

[MKadaner]

Thank you.

[rohitab]

Another concern is Viewer::XYfilepos, case VMT_HEX. The code here translates the X mouse click coordinate to the byte offset. The code obviously assumes that Hex dump is always 16 bytes per line. With user-customizable number of bytes per line in Hex dump, it is simply not true. Unfortunately, I cannot describe the scenario when this issue becomes visible.

The issue becomes visible when you use the mouse to select bytes in the Hex dump view. If the bytes-per-line are anything other than 16, the selection starts and ends at the wrong position. For example:

1. Open a file in Hex view
2. Press Alt+Left to reduce the bytes-per-line to 7
3. Press Shift+Left_Click on the byte 1 in the second line. Note that the byte 2 gets selected instead.
4. Press Shift+Left_Click on the byte 8 in the second line.

You'll see that bytes 2-9 get selected, instead of bytes 1-8.

Unfortunately, this issue is still present in version 3.0.6304.0 x64

[MKadaner]

Ouch! Silly me. Fixed (hopefully) in #826.

Thank you for reporting, @rohitab.