-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tabs in logfile messes up search highlighting #244
Labels
Comments
@zigurana Thank you for reporting and analysing this issue. I've found the mistake and should have a bugfix ready soon. |
Kittyfisto
added a commit
that referenced
this issue
Dec 9, 2020
…re involved #244 The central text viewer would misalign the search-term highlights incorrectly for every line containing tabs. This was caused by the search itself operating on the lines as is and reference sections of the line with respect to the number of characters from the start, e.g. a result would be index 12, 5 characters long. However the text display itself would modify the message prior to display and effectively expand tab characters by the number of spaces the user has specified. However when applying the search result, it would not take this expansion into account and re-use the indices reported by the search *on* the expanded message. This means that as soon as the user specified a tab width > 1, the search results were misaligned by the number of tabs *left* of the search term, multiplied by the number spaces per tab. The fix involved simply subdividing the message into its search result constituents first and only then expanding the individual substrings, replacing tabs with spaces.
Kittyfisto
added a commit
that referenced
this issue
Dec 9, 2020
…re involved #244 (#246) The central text viewer would misalign the search-term highlights incorrectly for every line containing tabs. This was caused by the search itself operating on the lines as is and reference sections of the line with respect to the number of characters from the start, e.g. a result would be index 12, 5 characters long. However the text display itself would modify the message prior to display and effectively expand tab characters by the number of spaces the user has specified. However when applying the search result, it would not take this expansion into account and re-use the indices reported by the search *on* the expanded message. This means that as soon as the user specified a tab width > 1, the search results were misaligned by the number of tabs *left* of the search term, multiplied by the number spaces per tab. The fix involved simply subdividing the message into its search result constituents first and only then expanding the individual substrings, replacing tabs with spaces.
@zigurana This bug has been fixed with Tailviewer v0.9.3.892 and will be part of the next Tailviewer release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behaviour
When searching in a file, the found entries cause highlighting of the text, but at an offset of the matches, see screenshot.
This effect depends on the amount of tabs found in the line.
Expected behaviour
Highlights overlaps with found match, independent of tabs being present or not.
Steps to reproduce the problem
Open minimal example file (attached), search for 'tab', observe highlighting
minimal_example.txt
PS: likely related to: #44, but a different symptom
The text was updated successfully, but these errors were encountered: