Bug 73896 - problem reporter: '\t' is counted as 1 character instead of tabwidth in column count
Summary: problem reporter: '\t' is counted as 1 character instead of tabwidth in colum...
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdevelop
Classification: Applications
Component: Problem reporter (show other bugs)
Version: 3.0.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-31 17:31 UTC by Daniel Franke
Modified: 2006-12-29 11:00 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Franke 2004-01-31 17:31:10 UTC
Version:           3.0-RC1, CVS 2004/01/30 (using KDE KDE 3.1.4)
Installed from:    SuSE RPMs
Compiler:          gcc-3.3.1 
OS:          Linux

1.
/// @todo foo-bar -> problem reporter: line 1, column 10, foo-bar

2.
\t\t/// @todo foo-bar -> problem reporter: line 1, column 12, foo-bar
instead of column = 2*tabwidth + 10
Comment 1 Daniel Franke 2005-01-14 14:02:49 UTC
Still valid in kdevelop-3.1.91, KDE-3.3.91, CVS 050113
Comment 2 Amilcar do Carmo Lucas 2005-01-14 17:52:04 UTC
Daniel seams to be a very good user. I trush him.
Comment 3 Daniel Franke 2005-01-26 22:24:43 UTC
As far as I can tell, this should be fixed in lib/cppparser/lexer.h, in the nextChar()/nextChar(int) functions (about line 500):
Lexer::m_currentColumn is increased by 1 for each character read, but each skipped character should be compared to '\t' and if the comparison is true -that's the tricky part- the current editor's tabwidth should be added (instead of 1).

If I had the slightest idea how to make the tabwidth known to the beforementioned functions (query the editor?, hand it down while constructing the lexer?), I could try to provide a patch myself ...
Comment 4 Jens Dagerbo 2006-12-29 11:00:44 UTC
The parser works on a file that might not even be open, so it cannot possibly know the "tabwidth". The problem reporter could possibly "translate" the information from the parser in relatation to the settings of the active file, but this information is not available through the KTE interface. 

I think it's fair to say this is a WONTFIX in KDevelop-3.x and it might not be relevant at all for KDevelop4