| Summary: | Inserting tabs instead of spaces if "Tab key adjusts indentation of the current line" set | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Tom Hanson <tom> |
| Component: | cdt-editor | Assignee: | Project Inbox <cdt-editor-inbox> |
| Status: | ASSIGNED --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, jamesblackburn+eclipse, yevshif |
| Version: | 8.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Tom Hanson
A tab is only inserted if the file already contains tabs.
"Adjust indentation" intentionally copies the indentation of a reference line in order to keep indentation style of a file as much as possible even if it does not match the current code style settings, e.g.
void f() {
<tab>int i;
int j;
}
Typing tab before "int j;" will replace the spaces with a <tab> even though the code style is set to "Spaces Only".
(In reply to comment #1) > A tab is only inserted if the file already contains tabs. > "Adjust indentation" intentionally copies the indentation of a reference line > in order to keep indentation style of a file as much as possible even if it > does not match the current code style settings, e.g. > > void f() { > <tab>int i; > int j; > } > > Typing tab before "int j;" will replace the spaces with a <tab> even though the > code style is set to "Spaces Only". This in not an acceptable solution in a production environment. Our coding standards REQUIRE spaces. The coding style is set to spaces. The editor should be using spaces. Even if, somewhere else in the file, a tab has been used it is not acceptable to insert additional tabs. WHY would you attempt to "keep indentation style of a file as much as possible even if it does not match the current code style settings". The current user specifically selected a coding style. Please don't try to second guess what their intent was. You have no way of knowing, other than the selections they've made. (In reply to comment #2) > This in not an acceptable solution in a production environment. Our coding > standards REQUIRE spaces. The coding style is set to spaces. The editor > should be using spaces. You can fix indentation style for the whole file first by Select All > Ctrl+I. *** This bug has been marked as a duplicate of bug 252989 *** (In reply to comment #3) > (In reply to comment #2) > > This in not an acceptable solution in a production environment. Our coding > > standards REQUIRE spaces. The coding style is set to spaces. The editor > > should be using spaces. > > You can fix indentation style for the whole file first by Select All > Ctrl+I. > > *** This bug has been marked as a duplicate of bug 252989 *** AND then every line that was reformatted will show up as a difference when you review / commit the code. Sometimes that's OK (i.e. early stage development) and sometimes it's absolutely not (i.e. critical bug fix just prior to release. There are times when the editor needs to do EXACTLY what I tell it to. No more, no less, no surprises. (In reply to comment #3) > (In reply to comment #2) > > This in not an acceptable solution in a production environment. Our coding > > standards REQUIRE spaces. The coding style is set to spaces. The editor > > should be using spaces. > > You can fix indentation style for the whole file first by Select All > Ctrl+I. > > *** This bug has been marked as a duplicate of bug 252989 *** Bug 252989 merely says that the behavior was intended. That doesn't mean it's correct. If this behavior is not changed, I may be forced to switch to a different IDE. I've been using Eclipse for 4+ years and I like it. BUT this behavior is completely unacceptable in a production environment. I agree that it's annoying and counterintuitive. IMO code-style tabs vs. spaces should be applied to new lines (and there could be a default-option to stick to the convention in the file). The formatter might need to use the indentation of the previous line to work out the current line's indent, so might have to translate \t to 2/4/8 chars depending on the expansion preference. (In reply to comment #5) > Bug 252989 merely says that the behavior was intended. That doesn't mean it's > correct. For what it's worth, this bug is a duplicate of bug 252989. (In reply to comment #5) > If this behavior is not changed, I may be forced to switch to a different IDE. > I've been using Eclipse for 4+ years and I like it. BUT this behavior is > completely unacceptable in a production environment. By all means patches are gladly accepted. See also bug 306305. Marking as enhancement with "helpwanted" keyword. A quality patch which adds yet another option to the preferences will be accepted. |