Keep line numbers in Find All dialog always visible

[MKadaner]

Following up the side discussion in #789:

@HamRusTal said:

@MKadaner Do you have any idea how feasible it is to make the line numbers and their vertical separator line stay put on the left when scrolling the menu items? As they were scrolling all in accord, that looked OK but now when the lines are aligned by the found text, these prefix fragments are scattered all around and look quite confusing IMHO.
At least some menus have non-scrollable portions of their items already: e.g. check marks in history menus, A (ANSI) marks in plugin configuration menu, etc. Maybe this can be generalized and reused in the menu at hand?

@MKadaner said:

@HamRusTal, this behavior is a damn nuisance I have been thinking about for years. Actually, even before my change, one could align all items to the right (Alt+End) and line numbers would become scattered all over the place. I was enjoying this sight pretty often when I used Alt+End as a poor man's substitute for aligned annotations. As such, I hold that I did not break anything. However, I admit that I did not realize it could become more of an issue for somebody else.

For me personally, aligning annotations has much higher priority than scattered line numbers, so it went first. Now aligning is done, I am warming up for line numbers. I can see at least two solutions:

1. Let each list item have more than one content string and draw these strings within their own vertical boundaries set up for the entire list.
2. Create a new dialog called Grid which would be similar to VMenu2 but would have more than one list. Vertical scrolling should affect all lists synchronously, while horizontal scrolling should be applied to the focused list only. Maybe just extend VMenu2 to contain more than one VMenu.

The resulting UX will be more or less the same. As it usually happens, each option has its own pros and cons. So, stay tuned.

Now I am considering the third option. Stay tuned.

[MKadaner]

Question to everyone who is interested in this feature. @HamRusTal.

If line numbers stay put at the left side of the Find All menu, (while the text still can be scrolled horizontally), it will be very natural to collapse (and restore) the column with line numbers. It is even imaginable to resize this column, because why not.

1. Which accelerator key should be used to collapse / restore?
2. If resize is supported, how to resize from the keyboard? I considered an accelerator which puts the menu in the special mode (similar to turning on filtering with RAlt), then use arrow key to resize. What should this accelerator be?

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

[HamRusTal]

I suggest that we approach this from the UI perspective of a multi-column menu. We already have one menu in Far where there are multiple togglable columns (UI-wise, regardless of the actual under-the-hood implementation) — Drives menu. It uses Ctrl+digit to toggle columns. Unfortunately, these are occupied already in the Find All menu, as are Ctrl+Shift+digit. And Alt+character is often used for hotkey navigation… Therefore, I suggest Alt+Shift+digit (as these modifiers should fit into the intuition around Alt+Shift+Home/Left/Right/End).

Moreover, we could use e.g. LAlt+Shift+digit to toggle columns' visibility, and RAlt+Shift+digit to enter the resizing mode for the given column. (And in that mode, we could use Tab/Shift+Tab to go to the next/previous column.)

[MKadaner]

Thank you for the ideas. I think that semantically, and visually, Find All menu with line numbers fixed in the left column is very different than Drive menu. In the latter, we have so many columns, each of which can be toggled on and off independently of others, and there is no resize. In Find All, we have exactly two columns, the left one can be collapsed, the right one cannot.

As for the resizing, when there are exactly two panes (or columns) there is no point in resizing either of them. The user-perceived action is shifting the separator between the panes. I see it similar to Windows Explorer window with directory tree in the left pane and file list in the right one. The widths of the panes cannot be adjusted, but the separator bar can be moved left and right (within limits).

Thus, I think that we need only one accelerator to enter resize mode, then we can use Home and End to collapse / restore and Left / Right to move separator. Home and End may immediately exit the resize mode, as well as Esc and the initial key. Given the Windows analogy, I considered F6 to enter (exit) resize mode. Once upon a time, it used to move focus between the panes in a window; one stop was the separator. In Far, F6 is all about "moving" (files), which makes this key somewhat mnemonical. This approach also makes resizing very accessible, unlike three-key combinations. Moreover, I feel that assigning different semantics to LAlt+Shift vs. RAlt+Shift will be really confusing. I suspect that people will use these keys a lot, so we should make them as convenient as possible.

Let me prototype the functionality with some accelerator key, so that we can get the feeling of the actual behavior and better understanding of how it will be more natural to control.

[HamRusTal]

If you want an ad-hoc UX solution for the Find All menu rather than a more general one for multi-column menus, then I see no point in character-wise resizing at all. All a user might need in this regard is to hide line numbers (to get more content width) and show them again. One hotkey is enough to toggle this state, and IMHO that should be F5 with some modifier (likely Shift) as bare F5 changes the window (hence content) size already. All that complexity with resize mode and step-by-step width change will serve no purpose here.

In any case I'd like to hear opinions of other people involved in FAR development (I hope they'll notice this discussion).

P.S.
I seem to have understood why you might wish to change the width of the line numbers column — because it wastes available width. If so, then we should just shrink the column to the actual minimal required width (for the longest present row/col numbers). BTW, we might make the above suggested toggle tri-state: row and col, only row, neither.

[MKadaner]

I seem to have understood why you might wish to change the width of the line numbers column — because it wastes available width. If so, then we should just shrink the column to the actual minimal required width (for the longest present row/col numbers). BTW, we might make the above suggested toggle tri-state: row and col, only row, neither.

You nailed it before I've had a chance to explain. :) That was exactly what I had in mind while talking about resizing.

Shrinking line numbers and column numbers to the actual minimal required width is rather expensive in the current implementation, because we accumulate menu lines as we find the pattern, and we format everything into a single string every time we found the pattern. To allot exact number of characters would require two passes. Given that even now Find All in a large file takes perceptible time, I am not sure I want to go into this direction. What I was going to do though was to limit the number of characters reserved for line number based on the actual number of lines in the file. This is an O(1) operation and it will be an improvement compared to the current implementation.

The tri-state toggle sound interesting and will cover all scenarios I need personally. I'll prototype it. Are you strong on Shift+F5? I would slightly prefer Ctrl+F5.

[HamRusTal]

limit the number of characters reserved for line number based on the actual number of lines in the file

It's a fair tradeoff.

Are you strong on Shift+F5? I would slightly prefer Ctrl+F5.

I don't have any really strong feelings on this, but let me explain why I suggested Shift. First of all, any actions to make more space for the menu content are relevant only to files with many/long matches. Bare F5 changes mostly/exclusively the menu height, so we can consider it a vertical expansion. The new action you're adding is strictly horizontal expansion. Taking the analogy with scrolling, while the vertical scrolling is caused by bare scroll wheel, the horizontal scrolling comes with Shift-modified scroll wheel. That's why I suggest to add Shift to the shortcut of the vertical expansion to get a shortcut for the (new) horizontal expansion.