New Editor with All Found lines improvement: add line numbers from the original file

[MKadaner]

This is follow-up on #955. Copying here relevant discussion from the PR

By @johnd0e in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3025387385

[I]deas for improvement:

1. Output Line/Column

By @MKadaner in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3025454574

No, or at least based on a config. Column number does not make sense at all because only one line is copied to the new editor, even if it has multiple occurrences. Line number, maybe... In my scenarios line numbers are generally not needed and even undesirable, but I can see how they may be useful. A new config value is easy to add. The only consideration is that so far you (maintainers) were generally reluctant about adding new configs. Or maybe a different pair of hotkeys, like Ctrl+F4 and CtrlAlt+F4? Just let me know please.

By @johnd0e in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3025619532

Or adding Shift to original hotkeys. Just to clarify my intentions: the resulting file could be used for mass-editing of lines with found occurrences. (there is a macro for that https://forum.ru-board.com/topic.cgi?forum=5&topic=49572&start=2600#19)

And for this purpose "line:" prefix would be enough, just like grep -n. (BTW there is another related grep options, such as -C for adding context lines)

By @MKadaner in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3030047172

[S]peaking about line numbers. what do you think of adding or not adding them depending on whether they are currently visible in the menu? Kinda WYSIWYG.

Also, what do you prefer, this:

6: Perfect: ⒍
28: Perfect: Twenty-eight
496: Perfect: CDXCVI

or this:

  6│ Perfect: ⒍
 28│ Perfect: Twenty-eight
496│ Perfect: CDXCVI

By @HamRusTal in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3030699533

adding or not adding them depending on whether they are currently visible in the menu?

This is smart IMHO

what do you prefer

What about a plain TAB character as a separator here? It is usually “long enough” to preserve alignment, is not visualized by default (so does not add noise), and is easy to remove/replace automatically.

By @MKadaner in https://github.com/FarGroup/FarManager/issues/955#issuecomment-3032441146

Thanks. I'll go with visibility then. Great!

What about a plain TAB character as a separator here? It is usually “long enough” to preserve alignment, is not visualized by default (so does not add noise), and is easy to remove/replace automatically.

I do not agree with the “long enough” part. With Tab size set to 4 (very common setting) and 1000+ lines in the original file (not uncommon), the alignment will be off:

1   Blah
10  Blah
100 Blah!
1000    Blah... Ouch!

Furthermore, I would highly prefer to right-align line numbers with spaces (just like it is done in the menu itself). It's much easier to parse visually. If the width of the line numbers column depends on the max number (the widest number fits exactly, again like in the menu), the TAB character will be adding different number of spaces (visually) depending on the size of the original file. I think this would be strange.

With line numbers right aligned, we could use space character for separator. It would still be reasonably easy to manipulate line numbers with a regex (^\s*\d+\s), but I strongly prefer a visible character, so that line numbers and the actual content can be told apart at a glance.

Now, the │ character (BOX DRAWINGS LIGHT VERTICAL, U+2502) as a separator is out of question because it cannot be represented in some encodings. So, we are left with :

      1: Blah
     10: Blah
    100: Blah!
   1000: Blah... Ouch!
1000000: Blah, blah, blah, blah!

If there are no strong objections, I'll proceed with right-aligned, width-fit, colon separated line numbers.

---

P.S. @alabuzhev, could you please assign this issue to me?

[MKadaner]

Before I start implementing, does anybody want this feature? What is the consensus?