Ok, I give up. I just want tabs->spaces, and 3 spaces.

[Cornelius]

Been screwing around with 2 dialog boxes for 45 minutes and can't get tabs to do what I want.

I hit tab in the body of the function below.  This is what I want:

hello()
{
(space)(space)(space)some typing
}

This is what I get:

hello()
{
(tab)(tab)(tab)(space)(space)some typing
}

It is a .c file.

In Document -> Tabs..., I set it to +3, which magically changes into "1 4".

In Tools->Options...->Languages->C/C++->Indent, I have:

Syntax indent of 3
Tabs: +3
Indent with tabs checked (unchecking it doesn't seem to change anything)
Insert real indent unchecked (checking it doesn't seem to change anything)


And those are the only options that should affect this directly, I think.

Again, the file is a .c file, and no, the previous function doesn't indent with 3 tabs and 2 spaces, so it isn't an adaptive formatting thing.

[Phil Barila]

Are you sure the mode you are changing in the Options dialog is the same mode that the file is actually in?  For example, you were modifying the C/C++ options, are you sure the file isn't in ANSI-C mode?
If you have the Syntax Indent value at 3 and the Tabs at +3 and "Indent with tabs" unchecked, you should get the behavior you want.  How did you instantiate the function body, through an expansion, or just by typing it all out?

[chrisant]

What version of SE are you using?  I had similar issues in SE 13 with tab indentation, but they were fixed years ago.

[Cornelius]

14.0.0.5

Ok, I created a new .c file (selected C/C++ from the template in the new dialog).  It operates as I want it to.

I closed and re-opened the problematic .c file but it's still giving that behavior.

I also notice this:  In the new file, I type in a bracket for a function body, and it automatically creates the closing bracket.  In other files that are .c, it is not doing this.  Is this maybe the same problem ultimately?  How do I make it behave like the new .c file?

Syntax Expansion is on for C/C++ files in Tools -> Options...->Languages->C/C++->Indent.

[Cornelius]

Ohmygod, it thinks these .c files are Intel Assembly, wth.

I'm guessing that because Document -> Select Mode has (Intel Assembly) in parens in the menu.  On the new .c file, it says (C/C++).


Lessee, the language manager General tab under C/C++ (Tools -> Options...->Languages->C/C++->General) shows that .c is still assigned to C/C++.



ZOMG, that new .c file, from the template, I just saved it, and now it's got a freakin' third method of doing tabs!

It inserts the closing brace when I type an opening one, but when I do tab, I get this:

hello()
{
(tab)some text
}

So I now have two different methods of tabbing, depending on whether a new c file's buffer has been saved or not (!!!)

And the after-save is, of course, the wrong one. 


ETA:  After saving the new buffer, the Document menu says Select Mode(C/C++), so at least it hasn't changed its interpretation to Intel Assembly.


Ok, this one problematic .c file does indeed have a tiny, 2-line asm() chunk in it (amongst a thousand C lines), but still, so what?  Isn't it the extension that determines how SlickEdit interprets things?

And what about already-existing or newly saved .c files without asm() in them?  They exhibit the wrong, 3rd type of behavior, still.


It seems like only a "new" file, created from the C/C++ template via File->New, exhibits the correct behavior, and that only before saving it!

[chrisant]

SE supports "embedded languages" -- for example a C/C++ file can contain embedded sections of Intel Assembly (e.g. inside an "asm" block).

The document mode (in the menu) should show the main mode for the file.  I'm not sure if/where the embedded mode shows up.

Settings like Tabs are configurable on a per-language basis.  So the C/C++ portion of the file uses the C/C++ settings, and various embedded language sections use the corresponding language settings for the embedded language(s).

If you can trim down the file to something your employer is willing for you to share and still reproduces the problem, please post it and I'd be willing to try seeing if I can reproduce the problem with the file, and maybe offer some suggestions.  Or someone else in the forum might beat me to it.

[Cornelius]

Ok, I think I've beaten it into submission after 2 days

If there's an asm() block, no matter how small, in a .c file, SlickEdit thinks it should treat it as an Intel assembly file rather than a C/C++ file.  If I go to Document -> Select mode and force it to C/C++, it behaves according to the C/C++ rules.



As for the funkiness from yesterday with the new C file buffer, pre- and post-save, I don't know.  Today I created a new for a test and it worked fine, behaving with 3 spaces for a "tab", both before and after saving.


The difference seems to be a reboot of my computer, or maybe a restart of SlickEdit.



So the only remaining issue is why a .c file with an asm() in it gets taken over by Intel assembly instead of remaining C/C++ w.r.t. automatic indent formatting.  It doesn't even make sense to do that for the asm() parts since they must be quoted strings.

[Lee]

I do recall an issue where the embedded mode would change the document mode in certain situations and the file would be saved in the embedded document mode state.  It was fixed in later point release and/or hotfix. I would update to latest point-release version available to you and make sure you are up-to-date on hotfixes.

[chrisant]

It doesn't even make sense to do that for the asm() parts since they must be quoted strings.

FWIW, some C/C++ compilers allow asm syntax using braces instead of quotes:

Code: [Select]

    __asm {
        nop
        mov ax,dx
        nop
        ret
    };


I do recall an issue where the embedded mode would change the document mode in certain situations and the file would be saved in the embedded document mode state.  It was fixed in later point release and/or hotfix.

Now that Lee mentions it, I do remember that bug, but I don't remember when it was fixed.  I tried to find when, but couldn't (I searched the "readme.html" files for every minor or major version since 13.0.0; I keep them all under source control ).  I couldn't find a release note about when the embedded mode bug was fixed.  Hopefully installing 14.0.2.2 would fix that for you (it's a free upgrade for any user with v14.*).