Future plans for margo & GoSublime

These are a few of the plans and ideas we have for margo & GoSublime in 2018 and beyond - in no particular order:

  • Make margo.sh support installing and updating GoSublime
  • Retire the old GoSublime and release the new implementation.
  • Improve documentation.
  • Improve Windows & Mac support.
    We are Linux users, so we can only do limited, to no, testing on Windows and Mac.
    Sometimes we get reports of things like auto-completion not working. We need your help finding and reporting these issues.
  • Improve editor performance in Sublime Text.
    Interacting with the Sublime Text API is a majour source of bottlenecks and although we've put a lot of time into improving things, there are still some cases where it can be a problem.
  • Improve GoSublime UI.
    Sublime added support for things like tooltips, popups and HTML a few years ago. It'd be nice to be able to use them instead of cluttering the status bar.
  • Embrace goimports.
    The automatic un/importing that goimports does is great, but we personally find it annoying that it changes the import grouping.
    We'd like to explore adding the automatic un/importing without the grouping and maybe even run it automatically while you type so tools like gocode don't need to add special support for working with imports you didn't explicitly add yourself.
  • Add support for environment-specific margo instances.
    Currently, GoSublime will automatically restart margo if GOPATH changes.
    This is to work around the use of global variables like os.Environ and build.Default, but it would be nice to extend this to other environment variables and even project.
  • Make margo work inside sandboxes, docker, etc.
  • Stop using stdout.
    Using stdin/stdout is great but from time to time we encounter some piece of code that decides to use fmt.Print and thus killing our IPC with very misleading and cryptic errors.
    It might also work-around an issue in Sublime Text where plugin_host crashes if the binary has a segfault.
  • Add support for more Go tools.
    There are a lot of cool tools out there to aid Go development and although we've tried to make things generic, it's still nice to officially recognise some of them.
  • Add support for more non-Go tools.
    No-one writes only Go code so it'd be nice to add more support for some of the other tools we use everyday.