\t (tab char) separators aligned incorrectly

[OlegFedko]

There is a log file with tab char used as separator:

2023-08-02 11:30:31.7529	12345	Info	Some text
2023-08-02 11:30:31.7529	1234	Info	Some text
2023-08-02 11:30:31.7529	123	Info	Some text
2023-08-02 11:30:31.7529	12	Info	Some text
2023-08-02 11:30:31.7529	1	Info	Some text

I'm expect that tab stop points are aligned across lines, like shown above.

In fact "Info" column is correctly aligned. But "Some text" column position is related to second column size.
It looks like this:

2023-08-02 11:30:31.7529   12345  Info Some text
2023-08-02 11:30:31.7529   1234   Info        Some text
2023-08-02 11:30:31.7529   123    Info       Some text
2023-08-02 11:30:31.7529   12     Info      Some text
2023-08-02 11:30:31.7529   1      Info     Some text

Screenshot:
https://snipboard.io/h3kXe4.jpg

---

Useful extra information

Klogg version 22.06.0.1289 (built on 2022-06-14 from commit 6340d94) [built for x86_64-little_endian-llp64]
running on Windows 11 Version 2009 (winnt/10.0.22621) [x86_64], concurrency 12
Qt 6.2.4, tbb 2021.7

[nowhszh]

It just so happens that I have read the code, and in fact klogg intentionally replaced tab with space in the original text. i think the possible reasons are as follows

• Different editors align tabs differently, which can be confusing. For example the same text with tabs is displayed differently by vim and vscode.
• I removed the part that replaced the space from the code and noticed that the mouse clicks were shifted. (Surely this must not be the main cause)

[OlegFedko]

It looks, that untabify() function is wrong:

klogg/src/logdata/include/linetypes.h

Lines 317 to 324 in 8a5eff0

	while ( position >= 0 ) {
	const auto spaces
	= TabStop - ( ( initialPosition.get() + position + totalSpaces ) % TabStop );
	line.replace( position, 1, QString( spaces, QChar::Space ) );
	totalSpaces += spaces - 1;
	position = type_safe::narrow_cast<LineLength::UnderlyingType>(
	line.indexOf( QChar::Tabulation, position ) );
	}

totalSpaces should be used if replace() is made in a copy of the string and indexOf() is called for original one.
But actually it is made on same string.

[nowhszh]

Your analysis is correct, I checked the modification history and it seems that the behavior changed during an optimization. I tried to revert the function to the pre-modification version and it ran just as expected.

Here is the modification at that time: perf: less copying on untabify

I removed totalSpaces from the current code, and it worked fine!

[variar]

That is indeed a bug. I wonder if result of getUntabifiedLength matches the version with the bug or without )

[nowhszh]

That is indeed a bug. I wonder if result of getUntabifiedLength matches the version with the bug or without )

Wait a minute. I'll check.

[nowhszh]

That is indeed a bug. I wonder if result of getUntabifiedLength matches the version with the bug or without )

After #664 getUntabifiedLength works correctly, before it had been an incorrect value