Recent Posts

Pages: 1 ... 8 9 [10]
91
SlickEdit 2017 v22 Beta Discussion / Re: v22rc4 tool button icons
« Last post by Dennis on October 10, 2017, 07:15:11 pm »
@jp:  That is correct.  The SVG icons are also much more compact and easier to create than ICO's with multiple bitmaps.  We managed to shrink the size of the installers (and installations) significantly by switching to .SVG.

@joecar:  The main change was that I switched from the generic empty rectangle to represent a symbol to a filled blue rectangle.  This was to be consistent with prior releases and the color icons where symbols are represented by a blue rectangle.  My opinion is that it looks better than before, but I do note your issue with it being harder to distinguish between the icons at the lowest resolution.  Have you tried 20x20 (Small)?
92
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.
93
OK, thanks for adding this as a feature request. Maybe this thread can be moved to the "Features and/or Improvements" area.
94
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.
95
SlickEdit® / Re: c++11/17 and beautify of Pro 2016/2017 Beta
« Last post by millerkp on October 10, 2017, 06:36:53 pm »
OK.  Sounds good as far as that goes.

More and more multi national projects are relying on formatters like clang-format and indent.  Some even have them built into the version control system or worse just checkers that fail the commit on invalid formatting.  It would be nice to be able to completely turn off formatting ie. no automatic indenting/spacing/code completion.  Even better would be allowing for a third party formatter plug-in on (should just be a simple system call).

Thank you,

K. Miller
96
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?
97
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;
98
SlickEdit 2017 v22 Beta Discussion / Re: v22rc4 tool button icons
« Last post by jporkkahtc on October 10, 2017, 05:59:24 pm »
Looks like what Slick is doing now for Icons, is they are all "*.svg" format and rendered to the desired size on the fly.
There is only a single SVG icon for each button, and it is rendered to match the setting - for size and colors.

So the challenge is in creating these drawings which render all these variations nicely.

Dennis, is that right?

99
SlickEdit® / Re: Nested struct type...
« Last post by joecar on October 10, 2017, 05:42:46 pm »
Also, not related to nested structs, how do you handle objects declared with typeof()...?

For example, see variable xyz in this pic, vs is highlighting it as unknown symbol:

100
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.
Pages: 1 ... 8 9 [10]