Rebuild on top of newterm

[wbond]

I just wrote a PC dependency for launching terminals, with the added functionality of allowing environmental variables to be set. https://github.com/codexns/newterm

It works around all sorts of issues with the current version, including:

1. Does not invoke scripts so the package can be placed in a .sublime-package file
2. Uses OS APIs instead of command line scripts, so there is less indirection
3. Allows control over the width of powershell and cmd.exe processes
4. Adds use_tabs param for both Terminal.app and iTerm.app on OS X
5. Handles invoking cmder.exe properly on Windows so that is ends up in the correct folder
6. Since it uses ctypes to call CreateProcess() on Windows, the various options needed to properly launch powershell are available, thus there is no need for the .bat script anymore and the cmd.exe will not flash momentarily.

The next step is to port this package to use it.

In the process is probably makes sense to break the key binding - perhaps just include a command palette entry and then in the readme include snippets for users to set up their own key bindings.

And finally, we may need to tweak the options in this package and/or add %CWD% support to newterm.

[caesarsol]

That's cool, I'm willing to help if you need a hand on OS X or Linux.

[twolfson]

@wbond On #99, you mentioned that the main task remaining for this is moving users from an older config to the new one. Here are a few questions I have

• What are your thoughts on the config? Pretty sure it will be the kwarg parameters from newterm.launch_terminal (i.e. env, terminal, args, width, use_tabs).
• Will %CWD% replacement occur in Sublime Terminal still?
• What is our plan for the transition? Here are some quick ideas:
  • Hard switch (e.g. break installations immediately)
    • Provide user a message
    • Move immediately to new settings keys
    • Ignore older keys (e.g. parameters)
  • Soft switch (e.g. allow old installations to last but consider them deprecated, remove in 3 months)
    • Provide user a message
    • Probably write duplicate code that sniffs for parameters and runs appropriately
      • Alternatively request users to set a custom setting to use newterm (doubt this will get used)
    • Possible problem: people might ignore it
  • Create new package
    • Provide users an installation and upgrade message about Terminal being deprecated in favor of NewTerminal
    • Let Terminal live forever
    • Write new package NewTerminal

[wbond]

I hadn't thought too much about exact what the config would look like. I do believe exposing the ability to use tabs on OS X should be a requirement.

I have not currently implemented the ability to pass the working directory as an argument. Instead, my plan is to support all of the major shells for a given OS out-of-the-box, and then if users want something custom, they can deal with the params themselves. The list of supported terminals is currently:

• OS X
  • Terminal.app
  • iTerm2.app
• Windows
  • Powershell
  • cmd
  • ConEmu
  • cmder
• Linux
  • gnome-terminal
  • xfce4-terminal
  • konsole
  • lx-terminal
  • mate-terminal
  • xterm

The way that custom terminal programs will work is that any batch/shell script will be executed within the working directory, and the script can translate that into whatever params the given terminal program needs.

In terms of a launch, I have been considering a hard launch of 2.0 that breaks backwards compatibility in terms of settings and key bindings. However, I'd like to also create a new package named Terminal 1 for users who want the old functionality. It would be the current codebase.

[twolfson]

With respect to config, I think exposing the keys 1:1 via JSON which maps directly to kwargs will be the sanest for us to manage. That includes use_tabs so :+1:

With respect to invocation, I am a bit fuzzy on how a custom terminal will work. Here's an example of what I think you are explaining. If that's not right, please correct me =)

• Launching the default terminal for an OS
  • newterm.launch_terminal('/path/to/cwd')
• Launching a known terminal, non-default terminal
  • newterm.launch_terminal('/path/to/cwd', terminal='xterm')
• Launching an unknown terminal
  • newterm.launch_terminal('/path/to/cwd', terminal='/usr/bin/new-term')
• Launching a terminal with custom environment variables as arguments
  • newterm.launch_terminal('/path/to/cwd', args=['$HELLO'])
  • This likely won't work because environment variable syntax could change from shell to shell so it's best to avoid it altogether

With respect to launching, I like that plan a lot =) :100: