| Summary: | problem reporter: '\t' is counted as 1 character instead of tabwidth in column count | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Daniel Franke <franke.daniel> |
| Component: | Problem reporter | Assignee: | KDevelop Developers <kdevelop-devel> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | esigra |
| Priority: | NOR | ||
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Daniel Franke
2004-01-31 17:31:10 UTC
Still valid in kdevelop-3.1.91, KDE-3.3.91, CVS 050113 Daniel seams to be a very good user. I trush him. 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 ... 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 |