Add several functions:

• go-goto-arguments
• go-goto-docstring
• go-goto-function
• go-goto-function-name
• go-goto-return-value
• go-goto-type-signature

They are all about going to different parts of function signatures, with their names being self descriptive. They all operate on the current function, the definition of which is "the closest func statement above point". If no func is found above point, the functions will jump to the first func in the file. Lastly, if the point is in the docstring of a function, the goto functions will operate on that function and not the function above.go-goto-type-signature

Additionally, some of the functions will create their targets if they are missing:

• go-goto-docstring will create a docstring if it does not exist as well as update the docstring name for a function that has been renamed.
• go-goto-return-value will add space for adding return values.
• go-goto-type-signature will add spaces and a pair of parenthesis for adding a signature.

It should also be noted that the functions have been tested with anonymous functions as well.

Add keymap at C-c g for goto functions. Add mapping for the already existing go-goto-imports at C-c g i. Add helper function go--get-function-name, which grabs the string of the function above point.

Update README to reflect the addition of these functions.

I have been using these functions for about a month now. They feel stable enough that they can be shared with the upstream go-mode.

It should be noted and is probably apparent that this is my first real contribution to a project written in elisp (or any lisp at all, actually :dancer:). As such, I am probably missing out on conventions, useful functions and other such things. I'd be very happy to change the code so that it fits well into the project! Comments on coding style and such things are extremely welcome!

TODO

• [x] go-goto-docstring should not update the docstring
• [x] Keybinds should not be on the user bindable keyspace.
• [x] Move all define-key to one single place.
• [x] go-goto-arguments has a copy-pasted docstring
• [x] ~~Handle going to docstrings with prepending words (A foo etc)~~
• [x] Fix corner cases for go-goto-function
• [x] Don't skip past the pointer in go-goto-return-value
• [x] Use forward-list instead of searching for ).
• [x] go-goto-type-signature has the wrong name.
• [x] Docstring and comments for go--in-function-p are wrong
• [x] go-goto-docstring has a bug with empty comments above a function
• [x] Add prefix arguments and handling of special cases for anonymous functions
• [x] Fix bug in go-goto-docstring in the empty comments case
• [x] Remove get- from go--get-function-name
• [x] Handle prefix arguments as booleans
• [x] Fix logical errors in go--in-function
• [x] Handle prefixed non-interactive calls to go-goto-docstring and go-goto-method-receiver.
• [x] Make go--function-name return nil for anonymous functions.

I have no idea why this is the case, but I've found that kill-line and kill-region work as expected when I first start emacs. After running gofmt in a buffer, however, text that is killed is no longer added to the kill-ring.

Emacs version: 24.3.1

I already use flycheck+helm to show and navigate errors, so popping up a new buffer after running gofmt-command is unnecessary and disruptive. This makes the behavior optional.

Variable names should be highlighted with font-lock-variable-name-face where the variable is declared. For example, u, v, x, y, and z should be highlighted in the following:

var x, y = 1, 2
x, y := 1, 2
for x, y := range aSlice {
func f(x, y int) (u, v bool)
func(x int, y char) (z bool)
func (x T) MyMethod(y int) (z int)

Highlighting variable declarations is performed in Emacs Lisp mode (for "defvar") and c-mode (for function parameters and variable declarations). I miss it in go-mode.

BTW, Thank you very much for the improved go-mode!

Is it possible to add support for outline-minor-mode? outline style code folding makes it much easier to work with large source code files. This is esp. useful for go-lang as one can keep the whole package source in a single file which makes code searching and navigation much easier.

python.el https://github.com/fgallina/python.el works with outline-minor-mode for Python and can be used as a reference. It defines two regexps: outline-regexp and outline-heading-end-regexp, and one function outline-level.

Reference for outline minor mode can be found here: http://emacswiki.org/emacs/OutlineMinorMode

Currently, Go types such as int32, float64 etc. are not recognized as part of Go's syntax:

package main

import "fmt"

func main() { var testvar int32 }

In the above piece of code, 'int32' is not highlighted, even trough it is a valid Go type.

If I edit an existing Go file, and add package to the import list that isn't referenced anywhere, then invoke go-remove-unused-imports, no imports are removed, even though the compiling the file results in an unused import error.

Using the code with go-flymake, gocode, and auto-complete enabled. I haven't tried turning them off yet.

Could you extract the gofmt foundation as a seprate package?

There are a lot of formatting elisp packages based on gofmt of go-mode.el. I think it is reasonable to extract gofmt foundation as a separate package and make it usable for them as a library.

Using this package, the following code defines gofmt function, gofmt-before-save function and gofmt-show-errors customizable variable.

(define-langfmt gofmt
  "Format the current buffer according to the gofmt tool."
  :group 'go
  :modes '(go-mode)
  :format-command gofmt-command
  :format-args '("--w")
  :format-handler (lambda (exit-status)
                    (unless (zerop exit-status)
                      (message "Could not apply gofmt")))
  :diff-handler (lambda (_ no-diff-p)
                  (message (if no-diff-p
                               "Buffer is already gofmted"
                             "Applied gofmt")))
  :error-filter (lambda (filename tmpfile)
                  (while (search-forward-regexp
                          (concat "^\\(" (regexp-quote tmpfile) "\\):") nil t)
                    (replace-match (file-name-nondirectory filename)
                                   t t nil 1))))

This is a part of my attempt for JSCS (JavaScript Code Style) fixer in jscs.el (papaeye/emacs-jscs#1).

Please feel free to rewrite the code and/or rename the package as you like!

I am using spacemacs (develop branch). The go integration that comes with it mostly delegates to go-mode.el.

I am also using godep, so my $GOPATH looks like this:

Now, if I try to gorename from emacs, I get

It can not find negroni package because is installed in godeps workspace.

But if I do the same from the command line, it works:

In emacs, evaluating (getenv "GOPATH") produces the correct path:

So what it is wrong? Is it me? Or is it a bug? I tried to look at your code, but I am a complete emacs/lisp n00b, so didn't get far :)

Thanks!

hi a vimer new come to emacs , vim-go provide lots of highlight group, so i want know does go-mode support it? like this pic,vim-go support the operators highlight and some others group.

When I use TRAMP 'godef-jump' and 'godef-describe' do not work with message "Could not run godef binary". When I use them from locally started Emacs they work just fine.

Using emacs 29 on windows from https://github.com/kiennq/emacs-build/releases/tag/v29.169.20221201.4a23421

When using go-mode eglot failes to properly connect with gopls

The actual error message I get is

Error in menu-bar-update-hook (imenu-update-menubar): (jsonrpc-error "request id=2 failed:" (jsonrpc-error-message . "Timed out")

I already commented out imenu-integration of go-mode, that's not the problem.

• If I uninstall go-mode and open the file, eglot correctly starts gopls
• If I literally open a go file and start eglot afterwards, gopls correctly loads.

The problem is rather hard to debug. In my particular project, out of 20? times gopls and eglot start to interact properly If I open a very small project (so that gopls has probably not much to analyse) go-mode, eglot and gopls always work.

Maybe it is a problem with windows pre-maturely reporting back successful process spawning, maybe it is gopls pre-maturely returning control to the os while rpc thread is still blocked? It seems a rather interacted timing issue of which go-mode may actually not be the culprit but rather a promoter.

Reporting here nonetheless as without go-mode eglot and gopls work.

As I hack on go-mode's fontification to support generics, I also am looking at other options.

To summarize how go-mode currently fontifies, it uses a combination of regexes and structural understanding of paren/bracket pairs. We make use of more advanced font-lock facilities such as function matchers and anchored matchers. These are relatively slow, but jit font lock mode does a really good job of only fontifying parts of the file that change, so performance is fine.

Tree-sitter is hot, but unfortunately also only has syntactic information, so does not help in ambiguous cases such as foo[bar](). It also may be more sensitive to syntax errors than go-mode's approach, but on the other hand is almost certainly faster. I think we should consider adopting tree sitter if/when it is part of core emacs, but before that the benefits don't seem that great. (It may have other benefits beyond syntax highlighting, though.)

The other option is LSP's semantic tokens. gopls does support semantic tokens and I was able to get it working with lsp-mode after fixing some things in gopls. In general it works, and of course it has full type information so all our ambiguity problems are solved. The fortification via lsp-mode is asynchronous, so it doesn't cause any lag, although that means it doesn't pop in immediately as you type. You can configure the idle delay before it fontifies. Setting it to 100ms gives a pretty good experience (although if you are working in a package that takes longer than 100ms to type check, the semantic tokens will be slower as well). One of the main problems is syntax errors. Without proper AST and type info, semantic tokens fall apart. To address this, I think we would need better support for partial fontification where gopls and/or lsp-mode know to keep fontification around for parts of the file that can't currently be type checked. This may be easier said than done.

My general idea is to continue to maintain basic fontification in go-mode, but support optionally augmenting it with gopls semantic tokens to fill in the holes. Once that is working well, we can consider completely offloading syntax highlighting to gopls. Thoughts?

It would be nice if fill-paragraph (ALT-Q on standard bindings) worked in multi-line back-quoted strings .

I use multi-line quotes like this to provide help

var help = `
Lots of nice long help text.

Spread out over lots of lines
`

And in editing that help for a terminal fill-paragraph would be super useful!

My current workaround is to drop into text-mode to do the fill-paragraph then return to go-mode.

I'll note that python-mode allows fill-paragraph in its equivalent triple quoted strings.

PS Thanks for writing go-mode - it is a great timesaver :-)