You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I select a log line and remove my filter, I am brought to a completely different place (to the top or the bottom, depending on whether tailing is activated).
It would be nice to keep that selected line in the view port when the filter changes.
The text was updated successfully, but these errors were encountered:
The extra computation for live updates of the scroll as the filter is changed might be tricky to handle.
If the filter gets more restrictive, the selected line could disappear.
If the selected line does not disappear, its index is likely to change among the new filtered list. An indexOf() might be needed on the list to retrieve the new row index of the formerly selected element, and this will happen on each key stroke in the filter field, which might cause some unwanted freezes. Launching a cancellable background task to do this job might be a solution, but is it worth it now that we have the search feature?
A simpler solution matching the standard use case would be to just implement that auto-scroll to selected line when the "clear" button is used in the filter, but that little cross is encapsulated in the library and some dirty reflection might be required to achieve this.
If I select a log line and remove my filter, I am brought to a completely different place (to the top or the bottom, depending on whether tailing is activated).
It would be nice to keep that selected line in the view port when the filter changes.
The text was updated successfully, but these errors were encountered: