Skip to content
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

Closed
zigurana opened this issue Dec 7, 2020 · 2 comments · Fixed by #246
Closed

Tabs in logfile messes up search highlighting #244

zigurana opened this issue Dec 7, 2020 · 2 comments · Fixed by #246
Assignees
Labels

Comments

@zigurana
Copy link

zigurana commented Dec 7, 2020

Current behaviour

When searching in a file, the found entries cause highlighting of the text, but at an offset of the matches, see screenshot.
image

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

@Kittyfisto Kittyfisto self-assigned this Dec 7, 2020
@Kittyfisto
Copy link
Owner

@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.
@Kittyfisto
Copy link
Owner

@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
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants