Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What is the last letter in the word "SlickEdit":
How many LETTERS are in the following? "a1b2c3":
Which number is missing?  "12345689":

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: rowbearto
« on: October 10, 2017, 06:45:00 PM »

Another aspect for this request would be to set "Line Continuation Indent" to "preserve" - meaning SE should leave alone any continuation alignment that I have manually performed when beautifying.
Posted by: rowbearto
« on: October 10, 2017, 06:43:59 PM »

OK, thanks for adding this as a feature request. Maybe this thread can be moved to the "Features and/or Improvements" area.
Posted by: patrick
« on: October 10, 2017, 06:40:03 PM »

Sure, it's possible.  As I said, not in a hotfix, or a point release.  I'll add it as a feature request for v23.
Posted by: rowbearto
« on: October 10, 2017, 06:27:07 PM »

I'm asking for exactly what Dmitry Frank described. I want indent with tabs up to the indent level of the statement, and spaces after. If I came across otherwise, I did not mean to. Continuation lines should indent up to the level of the statement, then spaces afterwards. So I think that SE should handle this with "line continuation indent".

With the way SE is now, SE is putting a tab in the "alignment" part instead of spaces, in this example:

Code: [Select]
>--->---int var1.........= 0,
>--->---....another_var..= 1,
>--->---....third_var....= 2;
I would set "line continuation indent" to 4, and "tab indent" to 4. But SE will put 1 tab for the line continuation and will give me this instead:

Code: [Select]
>--->---int var1.........= 0,
>--->--->---another_var..= 1,
>--->--->---third_var....= 2;
My request is that SE put 4 spaces for the line continuation alignment instead of 1 tab here.

Now that I have articulated this more clearly, is it possible for SE to do this?
Posted by: patrick
« on: October 10, 2017, 06:09:27 PM »

Quote
I don't understand how it is lost. At least for C/C++/Java code the distinction is simple. If a newline occurs without a semicolon at the end of its line, then the next line is a continuation. If a newline occurs after a semicolon, then the next line is not a continuation. Even SE must know about this, otherwise how do you know when to apply the "line continuation indent" or not? How is "line continuation indent" even an option if SE doesn't already know about this? All I'm asking is that when you apply the "line continuation indent", you give an option such that you never use tab characters for this. How can you have "line continuation indent" in Tools->Options->Languages->Application Languages->C/C++->Formatting->Edit->Indent->General if SE doesn't already know the difference?

I stated the 3rd item badly if what you got out of it is we don't know when to do continuation indent.  We do. 

To restate: we have lots of editing features that can re-indent code, that currently need no knowledge of continuations. All of them would need to be updated to handle this for all the languages we support smart editing for.  The effort for that is not trivial, it would not be something we'd put in a hotfix or a point release.

Also, looking back, I think you're asking for something slightly different than what Dmitry Frank seems to be advocating.  If you look at his examples, his continuation lines do have tabs up to the indent level of the statement, and then spaces to do the continuation.  Where you seem to be asking for no tabs at all on continuation lines.

From the Dmitry Frank article, with >-- standing in for tabs, and '.' for spaces.
Code: [Select]
>--->---int var1.........= 0,
>--->---....another_var..= 1,
>--->---....third_var....= 2;
Posted by: rowbearto
« on: October 10, 2017, 05:26:13 PM »

Quote
Am I right in thinking that this is more of an issue when working with a bunch of different projects from different teams with different coding standards?

Generally folks who indent with tabs want to be able to change the indenting size without modifying the file, as different people like different indenting amounts. Ken Thompson likes 8 spaces, Rob Pike likes 4 spaces. By using a tab character, then any developer can set their tab size to whatever indenting size they like to view the code with. Even Ken Thompson inventor of Unix prefers this, you can hear it right out of his mouth: https://www.youtube.com/watch?v=sln-gJaURzk#t=1735

Quote
I suppose the idea being if they can at least adhere to this minimal principal, their code won't look like crap if your tab stops are different from theirs.

This is correct. And having SE help the developer adhere to this principle would be very helpful!

Quote
Usually, by the time the initial indent is rendered into spaces or tabs, the distinction between "this part is indent, and the rest is alignment" is lost.

I don't understand how it is lost. At least for C/C++/Java code the distinction is simple. If a newline occurs without a semicolon at the end of its line, then the next line is a continuation. If a newline occurs after a semicolon, then the next line is not a continuation. Even SE must know about this, otherwise how do you know when to apply the "line continuation indent" or not? How is "line continuation indent" even an option if SE doesn't already know about this? All I'm asking is that when you apply the "line continuation indent", you give an option such that you never use tab characters for this. How can you have "line continuation indent" in Tools->Options->Languages->Application Languages->C/C++->Formatting->Edit->Indent->General if SE doesn't already know the difference?

Even VIM has a plugin called "Smart Tabs" that handles this properly: https://github.com/vim-scripts/Smart-Tabs

At the same time, if I align my code to a different number of spaces after the initial tabs (to align with a parenthesis or something), it would be good if SE didn't use the "line continuation indent" and kept the number of spaces that I manually entered in after the initial indent when doing beautification.
Posted by: patrick
« on: October 10, 2017, 05:06:47 PM »

Interesting reading.   A few thoughts, in no order.
  • This couldn't be the default.  Too many people expect indent-with-tabs to mean tabs in leading indent, with no distinction between continuation and alignment.
  • Am I right in thinking that this is more of an issue when working with a bunch of different projects from different teams with different coding standards?  I suppose the idea being if they can at least adhere to this minimal principal, their code won't look like crap if your tab stops are different from theirs.
  • It's not a trivial change for the editing code.  Usually, by the time the initial indent is rendered into spaces or tabs, the distinction between "this part is indent, and the rest is alignment" is lost.  It requires a change for every feature that can move code around: Smart indent, smart paste, syntax expansions, dynamic surround, quick brace, emulation specific commands for increasing/decreasing indents, etc... There are a lot of commands and functions that can currently be oblivious to the syntax at or around the cursor that would need to be made dependent on syntax analysis.
Posted by: rowbearto
« on: October 10, 2017, 01:19:45 PM »

When one uses "indent with tabs" = ON, the "line continuation indent" should always use spaces. I have noticed that when I have indent with tabs on, tab setting at 2, and continuation indent to 4, that SE is performing the continuation using 2 tabs instead of 4 spaces.

The reason that spaces should always be used for continuation is because if the tab size is changed, the continuation will no longer be aligned.

See:
https://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces
http://vim.wikia.com/wiki/Indent_with_tabs,_align_with_spaces#Smart_tabs