Highlighting is a bit off when returning:

User is a basic struct and I'm using it in a map. Both as a pointer or value map, proper struct highlighting fails in a make statement.

This could be a duplicate of #32

According TextMate naming conventions:

• func should be storage.type.function
  See #63

Related issue is atom/atom#8430

When I start a switch stmt, the case keywords are not inserted at the correct indentation. Sublime text seems to correct the indentation for case stmt when the : is inserted.

My built-in functions (new, len, etc.) don't match properly IF there is only one argument. The function name matches fine, but the opening parenthesis doesn't seem to match any rule at all, when I inspect it there is no markup around the parenthesis at all, so my syntax theme doesn't color it, leaves it white. The parameter inside the parentheses is marked as class="storage type go", which I don't think is correct either. The last parenthesis seems to marked correctly as class="keyword operator bracket go".

Hi,

The a6a571c commit removed the item placeholder in the forr snippet.
It went from…

'for range statement':
  'prefix': 'forr'
  'body': "for ${1:index}, ${2:item} := range ${3:list} {\n\t$0\n}"

…to…

'for range statement':
  'prefix': 'forr'
  'body': "for ${1:var} := range ${2:var} {\n\t$0\n}"

It was faster to:

• replace index by _ when using only the item.
• remove , item when using only the index.

Isn't this a regression?
The Go's range loop is used a lot to the get items only, without indexes:

for _, item := range list {
    // Only need item.
}

From @ahmetalpbalkan on December 21, 2016 17:52

Copied from original issue: microsoft/vscode-go#694

This script will hang for hours:

var OnigRegExp = require('oniguruma').OnigRegExp;

var line = '        vVar.Type().Name() == "" && vVar.Kind() == reflect.Ptr && vVar.Type().Elem().Name() == "" && vVar.Type().Elem().Kind() == reflect.Slice';

var decreaseNextIndentPattern = '^\\s*[^\\s()}]+(?<m>[^()]*\\((?:\\g<m>|[^()]*)\\)[^()]*)*[^()]*\\)[,]?$';

var regex = new OnigRegExp(decreaseNextIndentPattern);

var nope = regex.testSync(line);

That's the decreaseNextIndentPattern from language-go.cson. OnigRegExp is the library used by atom.

If I go to https://regex101.com/ and try the same regex/string it says Catastrophic backtracking has been detected and the execution of your expression has been halted.. That doesn't sound good.

This is the cause of atom/atom#10272.

Hi,

In this example we can see that we have the same color the user-defined (Myfloat) type and the type itself (float64):

It should have the same solor for type and float64. I tried with different syntax themes.

Thanks!

Highlighting renders fine until I start adding var () for some declarations:

When I say remove the f from func and re-add it the highlighting fixes itself.

Using the Tomorrow theme.

var e [][]*aType       // ( bug in highligher?)

The double slash and everything after should be highlighted in green (comment), but is showing as white, but is working code.

Copied from original issue: microsoft/vscode-go#531

When starting out with Atom and go development the snippets in this package got in the way of regular every-day typing. I still trip over them unintentionally at times and I'd like to see them extracted to a separate, optional package.

Thoughts?

Small nitpick. Anytime creating package main I'm always hit with the main autocomplete

Usually it turns out like this:

package func main() { 
}

I have a snippet that I use constantly when starting a Go script/package and thought I'd get some opinions on whether or not it might be useful to add into the language-go package snippets.

'.source.go':
  'go template':
    'prefix': 'got'
    'body': """
      package ${1:main}

      import (
        "${2:fmt}"
      )

      func ${1:main}() {
          $3
      }
    """

If you guys think it's worthwhile, let me know and I'll add it to snippets.cson and submit a pull-request.

For example (compared to my sublime output, both using Solarized (Dark) ). It's natural for the two color scheme to be a bit different, but it seems the Atom parser is not identifying things the same:

Atom

Sublime

Currently, if I start a new block (if, for, etc), when I type the open brace, the closing brace is automatically created, but when I press enter, I go to the next line with no added indention and the closing brace is on the same line. I end up with:

if true {
|}

Ideally, after pressing enter, I'd end up with:

if true {
    |
}

I added the | so you could see where the cursor is/would be. The auto indention works in languages that don't use braces (ruby or python) but doesn't seem to work in any language that uses braces (go, php, javascript).

Suggested by @mattetti in #9. Add the option to run go build on save and display any errors in Atom.

Pretty self explanatory:

Printf("message %s\n", str)

In upper code, when typing \n and " , " doubled two times.
it agonize me.
fix this plz

See attached picture. This should be easily reproducible.

From @brandonblock on November 29, 2016 19:11

When I paste a multiline string as a variable value and surround the string with a backtick, only the first line is highlighted. If I do a new line after the = the highlighting works but gofmt moves the value back to the same line as the assignment.

Copied from original issue: microsoft/vscode-go#666

https://github.com/fatih/vim-go/blob/master/gosnippets/snippets/go.snippets <-- Seems like a good place to start...

The Go toolchain contains gocode, a daemon that does everything for you (not sure about snippets), you just have to interface it. That way the extension doesn't have to be changed for different go syntax versions and always works with the installed version of go. The current parser should be kept as fallback though, so it still works if the official go toolchain is not installed/properly configured.

A labeled statement is treated as a Level 1 block (because gofmt will de-indent labels). As a result, folding a function that contains a labeled statement will not be fully folded - only the code preceding the label folds.

I'd expect the function to fold completely, disregarding labeled statements.

For an example, copy this code chunk into Atom and fold line 10 (the gitDir() function):

package main

import (
    "fmt"
    "os"
    "path/filepath"
)

// gitRoot finds the nearest directory containing `.git` above the current working directory.
func gitRoot() (dir string, err error) {
    if dir, err = os.Getwd(); err != nil {
        return
    }

DirectoryCheck:
    for {
        dir = filepath.Dir(dir)
        if len(dir) < 2 {
            err = fmt.Errorf("Error: unable to find root of git directory. %q", dir)
            return
        }

        var tempDir *os.File
        if tempDir, err = os.Open(dir); err != nil {
            return
        }
        var filenames []string
        if filenames, err = tempDir.Readdirnames(0); err != nil {
            return
        }
        for _, file := range filenames {
            if file == ".git" {
                break DirectoryCheck
            }
        }
    }

    return
}

func main() {
    dir, _ := gitRoot()
    fmt.Println(dir)
}

If the first character (only) of a variable name is not ascii, it is not highlighted correctly. E.g. gödel is highlighted correctly, über is not.

Atom v1.7.2, language-go v0.42.0

Is there a way to make the variables to the left of = different from those left of := ? Since one is assignment and one is declaration/assignment it would be nice to highlight the declarations.

I saw in #18 there was some discussion of how it would be hard to cover every case of variable declaration/assignment, but I think being able to highlight a newly-declared variable is really useful. From personal experience, when I do something like try to assign to an outer variable in a for loop, it pops out to me when I type := and the variable has a distinct color vs. =.

Atom solarized:

Sublime solarized:

I am seeing very inconsistent highlighting of constants and variables depending on context. I updated the language-go package from version 0.39.0 to 0.41.0 and Atom from version 1.2.4 to 1.3.2, just to ensure that I was up-to-date but I still get the same inconsistencies.

I am using the One Dark theme for both UI and Syntax Themes. Linux Mint 17.1 KDE desktop. I have tested for these errors, with essentially the same results, using various themes.

Here is a summary of what I am seeing:

• When I declare a const the name is red. const fourtyTwo = 42 // "fourtyTwo" is red (that's usual)
• In something like meaning := fourtyTwo fourtyTwo is now gray.
• When I define a struct the field names are gray. type user struct{ name string } // "name" is gray (seems like they should also be red)
• When I make a custom type and I use a built-in type, the built-in type's name is highlighted purple. type color uint8 // "uint8" is purple (the usual color)
• When I make a custom type from a user defined type it is gray. type hue color //"color" is gray (maybe that's intentional... not a reserved word, so purple doesn't make sense and gold would look odd... I don't have a great suggestion here.)
• When I use the var key word the name of the variable is red. var name string //"name" is red (usual)
• When I do something with the same variable later it is gray. len(name) // now "name" is gray (shouldn't it be red?)
• When I assign using := the left side var name is red; the right side gray. So in bar := foo // "bar" red, "foo" gray

Really real examples:

const (
    dbUser     = "user"
    dbPassword = "password"
    dbName     = "maintenance"
    dbHost     = "database.host"
)

In this context "dbUser", "dbPassword", "dbName" and "dbHost" are all highlighted red.

Later in the code:

    dbinfo := fmt.Sprintf("postgres://%s:%s@%s/%s?sslmode=require",
        dbUser,
        dbPassword,
        dbName,
        dbHost,
    )

In this context "dbUser", "dbPassword", "dbName" and "dbHost" are each gray.

The example var db *sql.DB and db, err = sql.Open("postgres", dbinfo) highlights the variables "db" and "err" in red, then later defer db.Close() has "db" in gray and "err" when checked, as in if err != nil {...} is gray.

In item := r.PostFormValue("item") "item" (left side) is red and "r" is gray. A few lines later "item", when used in the args for db.Query(), is gray.

Also in item := r.PostFormValue("item") "PostFormValue" is blue but in if r.Method == "POST" {...} "Method" is in gray.

And another: var i int "i" is a red and a couple of lines later in i++ the "i" is gray.

A couple of other odd ones:

"string" as a type highlights green var name string // "string" is green (the same color as string literals). All other built-in types seem to highlight purple.

Package names used to highlight, as in "http" from http.ListenAndServe and now are gray.

func/method parameters used to be red (as were the arguments passed in if I recall correctly) , now they are gray. They are at least consistent to each other, but they felt more comfortable to me when they matched the red pattern of variables.

support of function-parameters/method-parameters

The format is really simple and roughly given here: https://godoc.org/golang.org/x/tools/present

Using the var () block to define global variables seems to trip up the syntax highlighter when the code is formatted with gofmt. Specifically when a map[string]string is used, strings are not highlighted correctly, and in a larger file it throws off the string highlighting so that all strings are normal, and everything else is the string color.

Reproduction Steps:

1. Add a map[string]string to a global var block
2. Give it some key-value pairs

Expected Behavior:
The strings inside of the map will have the string syntax color

Observed Behavior:
The strings inside of the map do not have the string syntax color

Screenshots:
Shown first is the issue when code is formatted

Then remove the space between var and ( to make the highlighting correct

Atom version: 1.2.0
OS and version: OSX 10.11.1

Installed packages:

/Users/trentonsmith/.atom/packages (29)
├── .bin
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

Additional information:
The issue is the same in safe mode

As the title says, code segments with multi-line raw strings can't be folded.
These such strings can make code hard to read as they mess with the indentation, so being able to hide areas where they occur would be helpful.

package main

func main() {
  fmt.Println(`This
is
a
multiline
string`)
}

Expected behavior when folding:

Actual behavior:

Seems related to #65 and atom/atom#3442

After the update to Atom v1.1.0, comments and other lexical elements within var blocks don't highlight properly. This is independent of syntax-theme.

Const blocks still highlight correctly, so I've included such a screenshot as a comparison:

Would be awesome to highlight the public methods, i.e. those starting with upper-case. When I look to a source-code file, I want to see its interface quickly

Comments inside of var blocks are highlighted as code, not as comments.

var (
    // returns map[integrationID]campaignRankings and map[integrationID]rankings.ActivityLog
    CampaignAddWithTx = campaignAddWithTx

    // CampaignDeleteWithTx puts a timestamp in the 'Deleted' field to soft delete the data for the given integrationIDs
    CampaignDeleteWithTx = campaignDeleteWithTx

    // CampaignRollupJSON returns *json.RawMessage
    CampaignRollupJSON = campaignRollupJSON
)

Syntax highlighting for the data type for Vartype breaks because it ends in a with a lower cased word type in the name. The issue only occurs if the entry ends with type, if it is in the beginning or middle everything works as expected.

Moved over here from: atom/bracket-matcher#209

Try this golang code in the editor:

expected:

func someFunc() {
    aSlice := []string{}{

    }
}

actual:

func someFunc() {
    aSlice := []string{}{

}
}

The bracket matching seems to get confused by the appearance of a second set of brackets (i.e. the slice initializer), and it always places it on the first character of the next newline when enter is committed.

vars := mapEnv(env, splitEnv()) highlights incorrectly because the regexp does not require at least one space following var.

I've started testing atom on my machine to write Ruby, Go and more. The issue I'm facing with Go is that I rely heavily on the compiler to check the syntax and on gofmt/goimports to reformat my code and add the right import statements for me.

I'd love to add support for these tools in the language-go package but I don't see any docs explaining how to extend the package beyond grammars and snippets.

Hello,

I was trying to find a way to get non primitive types (either structs from the core libs, or structs from imported libraries / the current codebase) to get highlighted like primitives do, but can't really find where you define primitives in the grammars of language-go.

Am I barking up the wrong tree, and need to look at something deeper in Atom itself? or is this just currently not really a thing I should expect to be able to do?

Thanks

I'm finding that slices are not highlighted correctly depending on the declaration

fairly terse bug report, but not much else to say!

Always nice to know when new shiny things are merged to master. Perhaps cut releases/tag along the way so we can get emails via the releases .atom feed (atom feeds for atom packages!)

It seems more common for Go programs/libraries (esp samples shown at gophercon this week) use single line // comments rather than multiline /* ... */ comments. Can we change?

A nice addition would be to prompt for suggestions to autocomplete + tab to autocomplete top option.

When declaring a function as an argument, the trailing curly brace is not properly placed. Is this a problem with this package, or the core text buffer and how it handles indents? Reason I ask is because
I experience the same problem with other languages.

Before gofmt

After gofmt

guys are discussing the change: https://news.ycombinator.com/item?id=10993470

And found out this:

someFunction( anotherFunction( "cool :)" ) )

Brackets matching becomes incorrect here.. same applies to PHP and other languages..

You should consider rewriting regexes to something more smart.

It'd be great if Atom supported html templates like SublimeText does, and could differentiate between the Go template instructions and the html (and tell me when I've messed up either).

Two wrinkles:

• extension: there's no defined extension for html templates. I use "gohtml" because I wanted to differentiate between html and text templates, but I've seen others use ".tmp" and ".tmpl" too.
• delimiters: the default is {{...}}, but if you're using a client-side library that also uses them (like Angular.js) then you can change the delimiter in the template (I use [[...]] for this reason).
  It'd be great if there was a way of specifying extension and delimiter in the settings somehow.

Not an issue, just a feature request. And reposted from the go-plus repo.

Commenting text in template results in /*<text>*/ it should be {{/*<text>*/}}.

Somehow the grammar is broken for multiline raw strings if they come after an old-style type declaration. Open up this gist in atom.io to see the bug. The string declared fooStr := with a multiline raw string highlights correctly, but a string declared like var foo string = with a multiline raw string ends up highlighting the rest of the buffer (until another ` is encountered).