On 12/10/2012 12:27, Eduardo S nchez Mu oz wrote:

I don't see that (with my settings).
I guess that you have some odd settings for the indent and tab settings in the
cpp.properties file.
Stuff like indent.size, tab.size, use.tabs, etc.
SciTE is flexible enough to allow the mixed indentation style (use tabs up to one size,
finish the indentation with spaces if indentation is smaller than tab size).
I think it is called the GNU style. I dislike a lot this mix, but well, some people seem
to like it...

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

I wouldn't call the OP's settings odd without seeing them.  I'm
observing the same behavior, and I have no customization of my
cpp.properties file.  I don't even use SciTE for C, largely because
its indentation is too broken out of the box, too difficult for me to
figure out how to configure (if indeed there is even a way that would
suit me), and too complex for me to either fix it or write my own.

Clearly, SciTE is using the indentation of the line containing the '{'
to determine the indentation level of the block, regardless of the
indentation of other statements within the block.  Either it doesn't
realize that the indentation level of the *logical* line containing
the brace is the one with the function name, or it is ignoring the
concept of logical lines and only considering physical lines.

I am very curious to know how other people have set SciTE up for C.
Do people change the way they break lines up so that SciTE doesn't get
confused, or do they find the magic settings to make SciTE indent
sanely?  If the latter, then why aren't THOSE the default settings
which are included with SciTE?

To answer my own question a bit, I suppose historical inertia is a
powerful force, and I know Neil is especially loathe to change default
behavior, since it could break other people's existing setup.  But if
there are newer "preferred" settings, they could at least be
recommended in the documentation and/or in comments in the properties
files themselves (as I know sometimes does happen, and maybe I'm just
missing it for C).

I used to have similar questions for Python, but since Python is so
much simpler as far as indentation schemes go, and since its lexer is
not the lynchpin for multitudes of similar languages, I was eventually
able to patch SciTE myself (in what would become the
indent.python.colon setting).

John

Hmm... despite my earlier post, after noodling around a bit just now,
I have a possible suggestion for Eduardo:

Try adding the line

statement.lookback.$(file.patterns.c.like)=0

to your user properties file (put it in there instead of altering the
global or cpp properties, since it will make it easier when it comes
time to update to a newer version of SciTE).

Setting the lookback to 0 makes SciTE less "clever" but also less
intrusive and more predictable.  And it's still more clever than
merely *always* maintaining indentation.  Maybe if I'd found this
earlier, I wouldn't have switched to using something else for C.

John

Thanks John, adding that line worked for me.

On Fri, 12 Oct 2012 11:11:57 -0400

On 12/10/2012 16:54, John Yeung wrote:
 > On Fri, Oct 12, 2012 at 9:37 AM, Philippe Lhoste <Phi...@gmx.net> wrote:
 >> I don't see that (with my settings).
 >> I guess that you have some odd settings for the indent and tab settings in
 >> the cpp.properties file.
 >
 > I wouldn't call the OP's settings odd without seeing them.

Indeed, although I used the term 'odd' because the OP isn't expecting the result given by
these settings. Perhaps even these are the default settings.

 > I'm
 > observing the same behavior, and I have no customization of my
 > cpp.properties file.  I don't even use SciTE for C, largely because
 > its indentation is too broken out of the box, too difficult for me to
 > figure out how to configure (if indeed there is even a way that would
 > suit me), and too complex for me to either fix it or write my own.
 >
 > Clearly, SciTE is using the indentation of the line containing the '{'
 > to determine the indentation level of the block, regardless of the
 > indentation of other statements within the block.  Either it doesn't
 > realize that the indentation level of the *logical* line containing
 > the brace is the one with the function name, or it is ignoring the
 > concept of logical lines and only considering physical lines.
 >
 > I am very curious to know how other people have set SciTE up for C.
 > Do people change the way they break lines up so that SciTE doesn't get
 > confused, or do they find the magic settings to make SciTE indent
 > sanely?  If the latter, then why aren't THOSE the default settings
 > which are included with SciTE?
 >
 > To answer my own question a bit, I suppose historical inertia is a
 > powerful force, and I know Neil is especially loathe to change default
 > behavior, since it could break other people's existing setup.  But if
 > there are newer "preferred" settings, they could at least be
 > recommended in the documentation and/or in comments in the properties
 > files themselves (as I know sometimes does happen, and maybe I'm just
 > missing it for C).

I admit I gave up long ago to use the "smart" indentation of SciTE, and I am more than
happy to use the simple setting:
indent.maintain.$(file.patterns.c_like)=1

It only means I have to hit Tab after I typed an opening brace, and de-indent by hand
before typing the closing one. That's fine for me...

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Probably they are the default settings, because I didn't have any custom setting related to indenting.

On Fri, 12 Oct 2012 18:32:30 +0200

Interesting.  This is what I suspect a lot of people do (not just for
C but also Python, and probably for everything).  It would certainly
explain why several other programmer's editors enjoyed popularity
despite not even offering smart indent (only maintain indent).

I think I have rediscovered why a nonzero lookback might be good for
some people (and I vaguely remember Neil discussing this with me way
back in my early attempts to fix both Python and C indentation in
SciTE at the same time).

If your function signatures tend to fit on one line, then those won't
be a problem regardless of your lookback value.  But if you use a lot
of single-line, braceless "blocks" then you may be helped by having
some lookback.  With lookback, after you type

if (foo)
    bar();

the next Enter returns you to the 'if' level rather than maintaining
the 'bar' level.  So maybe the sweet spot for some programmers is a
lookback of 1, which smartly indents the above construct (blocks more
than one line need braces anyway), and limits the pain of difficult
function signatures (like Eduardo's) to a maximum of two lines of
manual indentation correction.

The most intelligent C indenter I've seen is Emacs's c-mode.  Back
when I was writing a lot of C for school, Emacs was never wrong.  If
it indented in a way that I didn't expect, it was always because I had
made a mistake.  (So it alerted me to syntax errors even before
compiling.)  That kind of cleverness is not easy to replicate, and
unless you can get it exactly right, it's probably better to be much
more gentle in the amount of "aid" that is provided.

John

John Yeung:

   The term 'statement' would be better since logical lines would be found by joining physical lines ending with the continuation '\' to the following physical line.

   It may be possible to add something to find the start of statements but that may be complex and could cause regressions in some cases.

   Are there any particular settings being proposed?

   Indentation has almost nothing to do with the lexer. All lexers and folders do is set the style value for each byte of the document and the fold level of each line.

   There's an assumption made by some that, because lexers define some of the behaviour of each language, all the behaviour of languages is in the lexer.

   Automatic indentation is handled by SciTE, not Scintilla.

   Neil

No, I'm actually asking the SciTE community what settings they use.
For all I know, most C programmers use the default settings and my
ideas of how automatic indentation should behave are very weird and
not representative.

John

On 10/14/2012 12:37 AM, John Yeung wrote:

I've encountered indentation misses while coding C, but then I
primarily use an older build, so I can't say anything definitive.
I think I am on default indentation settings but I use
bleeding-edge hg builds infrequently.

I think if someone can rustle up some test cases, that will bring
clarity to the issue. It's a lot easier to chase down glitches
with the help of a bunch of test cases.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

On 12/10/2012 19:21, John Yeung wrote:

I chose, a long time ago, to try and systematically use braces, even in one-statement
blocks after if, while and such. One exception being statements like return, break or
continue.
I see it at more consistent and it might avoid some subtle bugs, particularly when
indentation is wrongly showing some dependency... :-)
Of course, I don't expect everybody to follow this style (even if lot of people do the
same). That's why finding a good setting for everybody is usually difficult.

Oh, and I made a Lua macro, so when I hit Ctrl+= (parallel bars are suggestive when using
the style of aligning the braces) it adds braces at the level of indentation I am on, and
in the empty line between them, indent one level. Very handy, I miss it a lot when I code
in Eclipse... which has no scripting capability, strangely... perhaps it is too smart, so
the need is tiny. There was a scripting engine plugin in the past, but it died.

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --