I believe that this problem may be a side effect of the single line indentation behaviour.

If I type an 'if' statement and enter the brackets on the next line I find that the brackets are not un-indented, as follows:

if (/* condition*/)
    {} // <- bracket was auto closed but is indented

It would be good for the brackets to automatically un-indent in this case

Similarly if I enter an 'if' statement (even if I use the snippet to do so) and enter an 'else' below it, the 'else' statement is also automatically un-indented, as shown below:

while(true)
{
    if(/* condition */)
    {
        /* code */
    }
else // <- else statement automatically un-indented
    {
        /* code */
    }
}

This is affecting Atom version 0.110.0; Language C version 0.21.0

Thanks for your help.

Instead of adding \n auto complete adds n, same issue with scanf. I'm on Ubuntu 14.04, atom v0.199.0

for (size_t ${1:i} = 0; $1 < ${2:count}; $1${3:++}) {\n\t${4:/* code */}\n}

Most likely due to the ++.
Instead of ending up at the /* code */ part the snippet breaks at the tabstop before ++ and inserts a literal tab instead of moving to ++.

Atom 0.187.0, safe mode, Ubuntu 14.10.

(moved from atom/atom #7151)

Atom (and also github's markdown) only highlights the first line but not the second line for the following C code:

#define a >b()
int c;
int d;

And after the second line everything is fine again.

Here's a more realistic senario:

#define fmax(f, a, b) (f(a) > f(b) ? f(a) : f(b))
int c;
int d;

This bug only happens when there is one or more letter between > and (, including spaces but excluding tokens begining with numbers. For example these are going to trigger the bug:

#define a > a b c d ()
int e;
int f;
#define a > a b12 c34 d56 ()
int e;
int f;

This is not going to trigger the bug:

#define a > a b c 1d ()
int e;
int f;

Square brackets instead of parentheses would not trigger the bug:

#define a > a b c d []
int e;
int f;
#define a > a b12 c34 d56 []
int e;
int f;

Version of Atom editor: 0.204.0 on both Ubuntu 14 and Windows 7
This bug occurs even if all packages except core packages are disabled.

When I want to use cl snippet in my c++ project's header file(I prefer to use .h instead of .hpp, and I believe so do many people), I notice that it doesn't work.

The reason is that, although there are .h declarations in both grammars/c.cson and grammars/c++.cson, only .source.c class is added to a .h file in atom. However in snippets, cl is defined for only .source.cpp in snippets/language-c.cson.

It is very common to define Classes in header file, and header files are often used with .h suffix, so I think it makes sense to add support for it.

The easiest way is to just use the snippets for both c files and c++ files instead of dividing some for c++ only. I don't think people will use those snippets "accidentally" in a c file.

I'm creating a c++ class in a header file.
Adding public: or private: indented undos the indent. So

class Snowflake {
public:
};

instead of

class Snowflake {
   public:
};

One line while causes indentation issues.

Code inside #if block is not highlighted. There is simple test case to trigger issue

#if 1
int main(int argc, char *argv[])
{
  return 0;
}
#endif

As shown in Figure

The indentation is not being decreased properly when using Allman-style indents.

We want this:

if (true)
{
    break;
}

And get this:

if (true)
    {
        break;
    }

Auto-indent only works when line ends in open curly-brane, which is checked before the event mutates the text. At that time, the pesky close brace is in the way.

Qt Creator, for example, does not automatically add curly braces. Instead, it appears to check for a carrier return pressed right after an open curly brace and, in that case, it adds the matching close brace at the right place. That seems like a saner piece of behavior.

(I first filed this under general Atom feedback, but now I think this might be better off done here. Sorry for the noise.)

The use of EOL in snippets around curly brackets and spaces after statement keywords is inconsistent, for instance if transforms into

if(/* condition */)
{
  /* code */
}

while while into

while (/* condition */) {
  /* code */
}

Judging by 83b6f18, the latter is preferable (to me as well) and I can create a PR to fix that, however I'm currently unable to figure out how to properly not highlight the round bracket following a statement keyword if there is a space in between, e.g. for( (the bracket is white) vs. for ( (the bracket is blue). (Excuse the improper terminology, please.)

So maybe this is just a convention that I am not familiar with, but I've noticed something weird (at least to me) about Atom's C syntax highlighting.
Specifically, type names ending with "_t" are only highlighted if all letters are lowercase. For example:

lettercase_t foo1; // "lettercase_t" is highlighted by Atom.

letterCase_t foo2; // "letterCase_t" is not highlighted by Atom.

I've just noticed that it does the same thing here after posting the above example. Is this a bug or just expected behavior?

Thanks!

Got a false positive on a block comment, basically "/ *" (backslash space asterisk) was considered the start of a comment.

/*                                     <----- I can't seem to fold this comment block

class TreeNode
{
public:
    TreeNode() {};

/ *                                    <----- instead this block, from here.. 
    union {
        struct {
            int weightOnLeft;
            int weightOnRight;
        } weight;
        struct {
            vector < TreeNode* > balancesOnLeft;
            vector < TreeNode* > balancesOnRight;
        } balance;
    }
 * /                                   <----- ...to here, is foldable

    vector < mObject* > itemsOnLeft;
    vector < mObject* > itemsOnRight;
};
*/

Remove C extension from extensions list of c++ (source.c++) so linter-clang package (https://atom.io/packages/linter-clang) swap automatically and lint correctly.
I think that is a good idea link c files with grammar c and not c++.

Would it be possible to add .cu (cuda) files to the C++ file types? I can make a pull request, but its a very small change so it might be easier to make a regular commit.

Other than the one already there, .ipp, the file extensions .tcc and .tpp are also used for template implementations outside of header files.

Once #55 is released, send PRs to these packages. For now, they should probably handle both the old scopes (source.c++, source.objc++) and the new scopes (source.cpp, source.objcpp), for compatibility with older versions of Atom.

Update core packages:

• symbols-view atom/symbols-view#65
• language-ruby atom/language-ruby#77
• language-gfm atom/language-gfm#64

Release and upgrade bundled packages:

• language-c
• language-objective-c
• language-gfm
• language-ruby
• symbols-view

Send PRs to community packages:

• atom-ctags yongkangchen/atom-ctags#39
• atom-lint yujinakayama/atom-lint#115
• atom-xikij klorenz/atom-xikij#3
• autocomplete-clang yasuyuky/autocomplete-clang#23
• build-tools-cpp fstiewitz/build-tools-cpp#9
• atom-clang-format andrew-d-jackson/atom-clang-format#9
• coffee-navigator suda/coffee-navigator#16
• atom-file-types execjosh/atom-file-types#7
• language-arduino szechyjs/language-arduino#2
• language-crystal yegortimoschenko/language-crystal#2
• language-literate Kerrigan29a/language-literate#1
• language-swig saki007ster/language-swig#3
• language-x86 taylorlapeyre/language-x86#3
• linter-clang AtomLinter/linter-clang#18
• linter-cpplint AtomLinter/linter-cpplint#9
• symbols-tree-view xndcn/symbols-tree-view#4

Refs #54.

When I use "for" snippet, it will give me

It seems there is a missing 'i' after first ';'

The snippet shows:

for(size_t ${1:i} = 0; $2 < ${2:count}; ${3:i}++)\n{\n\t${4:/* code */}\n}

I think it is because the use of $2 after the first ';'.

When using strftime-style strings the highlighting for C is broken:

void test()
{
    t = time(NULL);
    tmp = localtime(&t);
    strftime(timestr, sizeof(timestr), "%Y-%m-%d %H:%M:%s", tmp);
}

see also: atom/atom#6432

The following C++ keywords are not being highlighted in Atom:

• nullptr
• this
• constexpr
• throw
• noexcept

Here are some screenshots of some of the keywords:

It happens just with empty lines:

A few things completely crash the Atom window. The only one I can think of right now is namespace

Open up a new C++ document/window and type namespace. Or try to.

Ditto.

I'm pretty sure a file of the form *.h.in should be considered a C header; other C-family header extensions (eg *.hpp.in) should probably be detected as the appropriate language.

The current snippet provides the following style for functions brackets:

type function_name(args) {
    // code
}

But most C (and C++) programmers makes use of K&R style for its readability:

type functions_name(args) 
{
    // code
}

I've already submitted a commit trying to change this.

I'm just getting ramped up with Atom and really liking it, however I'm having an issue with C++ syntax settings. I've added the following to my config:

'.c\\+\\+.source':
  'editor':
    'tabLength': 4

And it works just fine. However if I open the settings UI it modifies my config to this:

'.c ++ *.source':
  'editor':
    'tabLength': 4

This doesn't end up working; my C++ files now show up with my default 2 space tab size instead of my desired 4 spaces.

I've also noticed that if I use the system UI to modify the tab settings, it saves it as this:

'.c.source ++ *':
  'editor':
    'tabLength': 4

Which is not only a different format that other source selectors, but also still fails to be applied properly.

More odd is that after changing the setting in the UI to 4 and closing settings, when I reopen the settings, it still shows 2 for the tabLength.

I'm not sure how this is all wired up on the backend (haven't dug into code yet), but it definitely seems to be having issues. Perhaps if the issue is with the ++ it might be good to change the syntax scope to "cpp" instead, as it's a little simpler.

I'm using Atom 0.165.0 on OS X, installed just earlier today using the download button from https://atom.io. The Language C package is version 0.33.0. If you need any other details, please

I created a test.c file which content is "Hello world!" C program:

  #include <stdio.h>
  int main()
  {
    printf("Hello World!\n");
    return 0;
  }

But I don't know how to build it!

Need to install other package?

See: atom/language-coffee-script#39

Per the discussion on the CoffeeScript language package, it makes sense to keep the various default Atom language packages consistent. So rather than this being given a class of variable.language it should be given a class of variable.language.this.

In C++ code the qualifier noexcept is not highlighted correctly. I have tried various syntax themes

Here is an example code:

class a {
    void f() noexcept {
    }
};

Would it be possible to add .ino to the C++ file types as this is handy when editing Arduino files.

Please take a look at atom.io discussion.

Thanks.

Offending code taken from https://github.com/Cloudef/xcmenu:

     if (buffer[i] == '\1') fprintf(out, "%s", colors[0]);
else if (buffer[i] == '\2') fprintf(out, "%s", colors[1]);
else if (buffer[i] == '\3') fprintf(out, "%s", colors[2]);
else if (buffer[i] == '\4') fprintf(out, "%s", colors[3]);
else if (buffer[i] == '\5') fprintf(out, "%s", colors[4]);
else fprintf(out, "%c", buffer[i]);

\1, \2 and \3 are highlighted with red background (an error?), \4 and \5 are highlighted correctly.

One line else statement considers following brackets as "it's own".

This is with 0.15.0 which is the current version in atom.

I had to leave out a few details to make the summary short, but a double keyworded variable with 32 strings on one line causes the syntax highlighting to continue whatever color ended the array for the rest of the file.

It is important that the variable have two highlight regions before it; you can use a separate keyword, modifier or even a comment, so long as it has to switch highlighting contexts.

I managed to boil down a reproducible test case from the original mess into this:

cat >foo.c<<C1
int main() {
unsigned char *sigs[]={""$(for i in `seq 1 31`; do echo -n ',""'; done)};
int i;
};
C1
atom foo.c

On a vanilla install of Atom v0.69.0, it looks like function bodies in C or C++ get highlighted a bit oddly. Here's an example (using the Atom light theme):

I looked at the DOM tree, and it seems that the entire function body gets styled as meta function c, which AIUI should only have been applied to the function name.

I have a switch code example indented by Atom:

while ((select = getch()) != Exit) {
    switch ( select ) {
      case NewFile:
      selection1();
      break;
      case Deleteids:
      selection2();
      break;
      case Collisions:
      selection3();
      break;
      case LoadFactor:
      selection4();
      default:
      continue;
}
}

This is the same code Indented by Vim:

while ((select = getch()) != Exit) {
        switch ( select ) {
            case NewFile:
                selection1();
                break;
            case Deleteids:
                selection2();
                break;
            case Collisions:
                selection3();
                break;
            case LoadFactor:
                selection4();
                break;
            default:
                continue;
        }
}

As you see case doesn't trigger a indent.

When using curly brackets after a switch or case statement, the bracket line is set to having one indentation less, as there is no automatic indent after each of these keyword (as opposed to if or else).
Preferable, is that the switch and case keywords also trigger an automatic indentation.

EDIT: I use Allman-style indentation, and as such it may not affect other indentation styles.

Indentation should be:

if ( i == 1 )
    continue;

But is:

if ( i == 1 )
continue;

When statement without braces.

This is the original code:

struct rec {
    char id[26];
    struct year *ptr; };

struct year {
    int year;
    struct year *next;
    struct day *ptr; };

struct day {
    int day;
    double expenses;
    struct movie *ptr;
    struct day *next; };

struct movie {
    char id[5];
    struct movie *next; };

This is the indented by atom code:

struct rec {
  char id[26];
  struct year *ptr; };

  struct year {
    int year;
    struct year *next;
    struct day *ptr; };

    struct day {
      int day;
      double expenses;
      struct movie *ptr;
      struct day *next; };

      struct movie {
        char id[5];
        struct movie *next; };

If I put }; on the line below indenting works correctly.

struct rec {
  char id[26];
  struct year *ptr;
};

struct year {
  int year;
  struct year *next;
  struct day *ptr;
};

struct day {
  int day;
  double expenses;
  struct movie *ptr;
  struct day *next;
};

struct movie {
  char id[5];
  struct movie *next;
};

Atom 0.109.0, language-c 0.21.0, Linux

I have an array that looks like this:

unsigned short idx[] = {0, 1, 2,  2, 3, 0,  1, 4, 2,  5, 6, 7,  7, 8, 5,  6, 9, 7,  10, 11, 12, 12, 13, 10,  14, 15, 16,  16, 17, 14};

When I try to break it up into multiple lines, the developer tools for web pages opens, pictured below.

A project I'm working on has a block of the form

namespace foo {
    constexpr foo_t BAR = 0;
    constexpr foo_t BAZ = 1;
    ...
}

With C Language enabled, I get two related weird symptoms:

1. Trying to put a newline anywhere between the "namespace" keyword and the close brace causes the Atom window to hang.
2. Trying to insert any character inside the block itself also causes a hang. Deletions work fine as far as I can tell.

cout and cin are not highlighted by default please add them to be highlighted.
they appear as normal text in the editor.

cout << "Hello"; // I want cout highlighted
cin >> n; //and cin too

Breaking the line between a function name and the opening parenthesis of a function call in C is valid syntax, but fails to be correctly highlighted. Adding space is fine though.

This is using the Base 16 Tomorrow Dark theme.

The syntax highlighting of parenthesis in function calls does not work properly, as demonstrated in the image below.

http://imgur.com/KfDzDrj

The commented screenshot shows expected and observed behavior.
This occurred on OS X. I am running 10.11 Beta, but I'm confident I've experienced this behavior in 10.10 as well.