internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: xonsh/xonsh

Issue:
Tuple unpacking broken with star operator at RHS
For example:
```
xolotl:~$ a, *b, c = 1, 2, 3
xolotl:~$ a, b, *c = 1, 2, 3
xonsh: subprocess mode: command not found: a,

```
```
xolotl:~$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a, b, *c = 1, 2, 3
>>> 
xolotl:~$ $XONSH_VERSION
'0.5.12'
xolotl:~$ a, b, *c = 1, 2, 3
xonsh: subprocess mode: command not found: a,
xolotl:~$ 

```


Discussion:
Thanks for reporting this @nizig!
Oddly, this works with parens `(a, b, *c) = 1, 2, 3`

Resolving patch:
diff --git a/xonsh/parsers/base.py b/xonsh/parsers/base.py
--- a/xonsh/parsers/base.py
+++ b/xonsh/parsers/base.py
@@ -2707,6 +2707,14 @@ def p_subproc_arg_part(self, p):
     # Helpers
     #
 
+    def p_test_comma_combine(self, p):
+        """test_comma_list : test comma_test_list
+                           | test comma_test_list COMMA
+        """
+        p2 = p[2]
+        p2.insert(0, p[1])
+        p[0] = p2
+
     def p_empty(self, p):
         'empty : '
         p[0] = None


Test patch:
diff --git a/tests/test_parser.py b/tests/test_parser.py
--- a/tests/test_parser.py
+++ b/tests/test_parser.py
@@ -22,23 +22,23 @@ def xonsh_builtins_autouse(xonsh_builtins):
 PARSER = Parser(lexer_optimize=False, yacc_optimize=False, yacc_debug=True)
 
 
-def check_ast(inp, run=True, mode='eval'):
+def check_ast(inp, run=True, mode='eval', debug_level=0):
     __tracebackhide__ = True
     # expect a Python AST
     exp = ast.parse(inp, mode=mode)
     # observe something from xonsh
-    obs = PARSER.parse(inp, debug_level=0)
+    obs = PARSER.parse(inp, debug_level=debug_level)
     # Check that they are equal
     assert nodes_equal(exp, obs)
     # round trip by running xonsh AST via Python
     if run:
         exec(compile(obs, '<test-ast>', mode))
 
-def check_stmts(inp, run=True, mode='exec'):
+def check_stmts(inp, run=True, mode='exec', debug_level=0):
     __tracebackhide__ = True
     if not inp.endswith('\n'):
         inp += '\n'
-    check_ast(inp, run=run, mode=mode)
+    check_ast(inp, run=run, mode=mode, debug_level=debug_level)
 
 def check_xonsh_ast(xenv, inp, run=True, mode='eval', debug_level=0,
                     return_obs=False):
@@ -990,6 +990,9 @@ def test_bare_x_stary():
 def test_bare_x_stary_z():
     check_stmts('x, *y, z = [1, 2, 2, 3]')
 
+def test_bare_x_y_starz():
+    check_stmts('x, y, *z = [1, 2, 2, 3]', debug_level=1)
+
 def test_equals_list():
     check_stmts('x = [42]; x[0] = 65')
Repository: xonsh/xonsh

Issue:
xonsh autocomplete suggests files that don't exists
```
touch a
ls a
rm a
```

After that, xonsh (with prompt_toolkit backend) will suggest a completion that doesn't make sense:

If I press `ls <TAB>`, it will suggest `a` in the completion menu even though that file doesn't exist.

Why is that, and how can I turn it off?

Thanks!


Discussion:
This is because the 'autocomplete' entries (that you would normally complete by hitting right-arrow or Ctrl-e are also included as the first item in the completions menu. 

I would be in favor of having this behavior be optional, since it routinely confuses me.
Thanks for reporting @nh2! I could have sworn this was optional, but I can't find an envvar for it @gforsyth!

Resolving patch:
diff --git a/xonsh/environ.py b/xonsh/environ.py
--- a/xonsh/environ.py
+++ b/xonsh/environ.py
@@ -120,6 +120,7 @@ def DEFAULT_ENSURERS():
     'AUTO_CD': (is_bool, to_bool, bool_to_str),
     'AUTO_PUSHD': (is_bool, to_bool, bool_to_str),
     'AUTO_SUGGEST': (is_bool, to_bool, bool_to_str),
+    'AUTO_SUGGEST_IN_COMPLETIONS': (is_bool, to_bool, bool_to_str),
     'BASH_COMPLETIONS': (is_env_path, str_to_env_path, env_path_to_str),
     'CASE_SENSITIVE_COMPLETIONS': (is_bool, to_bool, bool_to_str),
     re.compile('\w*DIRS$'): (is_env_path, str_to_env_path, env_path_to_str),
@@ -265,6 +266,7 @@ def DEFAULT_VALUES():
         'AUTO_CD': False,
         'AUTO_PUSHD': False,
         'AUTO_SUGGEST': True,
+        'AUTO_SUGGEST_IN_COMPLETIONS': True,
         'BASH_COMPLETIONS': BASH_COMPLETIONS_DEFAULT,
         'CASE_SENSITIVE_COMPLETIONS': ON_LINUX,
         'CDPATH': (),
@@ -394,6 +396,10 @@ def DEFAULT_DOCS():
         'Enable automatic command suggestions based on history, like in the fish '
         'shell.\n\nPressing the right arrow key inserts the currently '
         'displayed suggestion. Only usable with ``$SHELL_TYPE=prompt_toolkit.``'),
+    'AUTO_SUGGEST_IN_COMPLETIONS': VarDocs(
+        'Places the auto-suggest result as the first option in the completions. '
+        'This enables you to tab complete the auto-suggestion.'
+        ),
     'BASH_COMPLETIONS': VarDocs(
         'This is a list (or tuple) of strings that specifies where the '
         '``bash_completion`` script may be found. '
diff --git a/xonsh/ptk/completer.py b/xonsh/ptk/completer.py
--- a/xonsh/ptk/completer.py
+++ b/xonsh/ptk/completer.py
@@ -49,7 +49,7 @@ def get_completions(self, document, complete_event):
                                                  self.ctx)
         # completions from auto suggest
         sug_comp = None
-        if env.get('AUTO_SUGGEST'):
+        if env.get('AUTO_SUGGEST') and env.get('AUTO_SUGGEST_IN_COMPLETIONS'):
             sug_comp = self.suggestion_completion(document, line)
             if sug_comp is None:
                 pass


Test patch:
Repository: xonsh/xonsh

Issue:
XDG Directory Specification
Xonsh already supports XDG Directory Specification. So why doesn't xonsh implement it also for per-user run control file `(~/.xonshrc)`?


Discussion:
Hi @dosimple, I am a little confused. We do support a `~/.xonshrc` file, see http://xon.sh/xonshrc.html. Or are you suggesting that we support something in the `$XDG_CONFIG_HOME` dir, like `~/.config/xonsh/rc.xsh`?
Hi @scopatz, I meant the second one, like `~/.config/xonsh/rc.xsh`.
This is something that would be relatively easy to add, I think.
Not a blocker necessarily, but we should think about what happens if you set your `$XDG_DATA_HOME` in your `xonshrc`
Yeah, good point @gforsyth - I am not sure that is a valid action according to the spec (but would have to double check).  It might be interesting to have interactive-read-only  environment variables...

Resolving patch:
diff --git a/xonsh/environ.py b/xonsh/environ.py
--- a/xonsh/environ.py
+++ b/xonsh/environ.py
@@ -247,13 +247,15 @@ def xonshconfig(env):
 @default_value
 def default_xonshrc(env):
     """Creates a new instance of the default xonshrc tuple."""
+    xcdrc = os.path.join(xonsh_config_dir(env), 'rc.xsh')
     if ON_WINDOWS:
         dxrc = (xonshconfig(env),
                 os.path.join(os_environ['ALLUSERSPROFILE'],
                              'xonsh', 'xonshrc'),
+                xcdrc,
                 os.path.expanduser('~/.xonshrc'))
     else:
-        dxrc = (xonshconfig(env), '/etc/xonshrc', os.path.expanduser('~/.xonshrc'))
+        dxrc = (xonshconfig(env), '/etc/xonshrc', xcdrc, os.path.expanduser('~/.xonshrc'))
     return dxrc
 
 
@@ -656,9 +658,9 @@ def DEFAULT_DOCS():
         'A list of the locations of run control files, if they exist.  User '
         'defined run control file will supersede values set in system-wide '
         'control file if there is a naming collision.', default=(
-            "On Linux & Mac OSX: ``['/etc/xonshrc', '~/.xonshrc']``\n"
+            "On Linux & Mac OSX: ``['/etc/xonshrc', '~/.config/xonsh/rc.xsh', '~/.xonshrc']``\n"
             "\nOn Windows: "
-            "``['%ALLUSERSPROFILE%\\\\xonsh\\\\xonshrc', '~/.xonshrc']``")),
+            "``['%ALLUSERSPROFILE%\\\\xonsh\\\\xonshrc', '~/.config/xonsh/rc.xsh', '~/.xonshrc']``")),
     'XONSH_APPEND_NEWLINE': VarDocs(
         'Append new line when a partial line is preserved in output.'
     ),


Test patch:
Repository: xonsh/xonsh

Issue:
AttributeError: module 'token' has no attribute 'ASYNC'
After upgrading from Python 3.7.0b3 to 3.7.0b4, an attempt to start the shell fails with the following traceback:

```
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/xonsh", line 2, in <module>
    from xonsh.main import main
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/xonsh/main.py", line 17, in <module>
    from xonsh.execer import Execer
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/xonsh/execer.py", line 13, in <module>
    from xonsh.built_ins import load_builtins, unload_builtins
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/xonsh/built_ins.py", line 25, in <module>
    from xonsh.inspectors import Inspector
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/xonsh/inspectors.py", line 21, in <module>
    from xonsh.tokenize import detect_encoding
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/xonsh/tokenize.py", line 57, in <module>
    ASYNC = token.ASYNC
AttributeError: module 'token' has no attribute 'ASYNC'
```


Discussion:
Looks like the change was made in python/cpython@4dc3c8ff14572032e63d9938a12813392bcbe982 as part of [bpo-33260](https://bugs.python.org/issue33260).

Resolving patch:
diff --git a/xonsh/lexer.py b/xonsh/lexer.py
--- a/xonsh/lexer.py
+++ b/xonsh/lexer.py
@@ -59,7 +59,7 @@ def token_map():
     tm[NEWLINE] = 'NEWLINE'
     tm[INDENT] = 'INDENT'
     tm[DEDENT] = 'DEDENT'
-    if PYTHON_VERSION_INFO >= (3, 5, 0):
+    if (3, 5, 0) <= PYTHON_VERSION_INFO < (3, 7, 0):
         from xonsh.tokenize import ASYNC, AWAIT
         tm[ASYNC] = 'ASYNC'
         tm[AWAIT] = 'AWAIT'
diff --git a/xonsh/tokenize.py b/xonsh/tokenize.py
--- a/xonsh/tokenize.py
+++ b/xonsh/tokenize.py
@@ -52,7 +52,7 @@
                            "NL", "untokenize", "ENCODING", "TokenInfo",
                            "TokenError", 'SEARCHPATH', 'ATDOLLAR', 'ATEQUAL',
                            'DOLLARNAME', 'IOREDIRECT']
-PY35 = PYTHON_VERSION_INFO >= (3, 5, 0)
+PY35 = (3, 5, 0) <= PYTHON_VERSION_INFO < (3, 7, 0)
 if PY35:
     ASYNC = token.ASYNC
     AWAIT = token.AWAIT


Test patch:
Repository: xonsh/xonsh

Issue:
hg commit -i fails
`hg commit -i` opens a curses interface and it allows you to select sections of code to include in the commit.

When I run this from `xonsh` and press `f` which is supposed expand a file (it is a tree view), instead an `f` character is displayed on top of the interface.



Discussion:
Thanks for reporting @Siecje! I think I know the fix.
Awesome!

So you are able to reproduce it?

I was going to look into it, so the issue is not very detailed. One thing to mention is that I have set Mercurial to use the curses interface[0].

0: https://bitbucket.org/Siecje/hg_setup/src/fa26c13ca84b1b1e9661f4bcb160f822156c7b35/.hgrc#lines-5


Resolving patch:
diff --git a/xonsh/commands_cache.py b/xonsh/commands_cache.py
--- a/xonsh/commands_cache.py
+++ b/xonsh/commands_cache.py
@@ -332,6 +332,23 @@ def predict_help_ver(args):
     return pred
 
 
+@lazyobject
+def HG_PREDICTOR_PARSER():
+    p = argparse.ArgumentParser('hg', add_help=False)
+    p.add_argument('command')
+    p.add_argument('-i', '--interactive', action='store_true', default=False,
+                   dest='interactive')
+    return p
+
+
+def predict_hg(args):
+    """Predict if mercurial is about to be run in interactive mode.
+    If it is interactive, predict False. If it isn't, predict True.
+    """
+    ns, _ = HG_PREDICTOR_PARSER.parse_known_args(args)
+    return not ns.interactive
+
+
 def default_threadable_predictors():
     """Generates a new defaultdict for known threadable predictors.
     The default is to predict true.
@@ -348,6 +365,7 @@ def default_threadable_predictors():
         'emacsclient': predict_false,
         'fish': predict_shell,
         'gvim': predict_help_ver,
+        'hg': predict_hg,
         'htop': predict_help_ver,
         'ipython': predict_shell,
         'ksh': predict_shell,


Test patch:
Repository: xonsh/xonsh

Issue:
xonsh should not mutate the standard library tok_name
```py
>>> import xonsh
>>> import tokenize
>>> tokenize.tok_name
{0: 'ENDMARKER', 1: 'NAME', 2: 'NUMBER', 3: 'STRING', 4: 'NEWLINE', 5: 'INDENT', 6: 'DEDENT', 7: 'LPAR', 8: 'RPAR', 9: 'LSQB', 10: 'RSQB', 11: 'COLON', 12: 'COMMA', 13: 'SEMI', 256: 'NT_OFFSET', 15: 'MINUS', 16: 'STAR', 17: 'SLASH', 18: 'VBAR', 19: 'AMPER', 20: 'LESS', 21: 'GREATER', 22: 'EQUAL', 23: 'DOT', 24: 'PERCENT', 25: 'LBRACE', 26: 'RBRACE', 27: 'EQEQUAL', 28: 'NOTEQUAL', 29: 'LESSEQUAL', 30: 'GREATEREQUAL', 31: 'TILDE', 32: 'CIRCUMFLEX', 33: 'LEFTSHIFT', 34: 'RIGHTSHIFT', 35: 'DOUBLESTAR', 36: 'PLUSEQUAL', 37: 'MINEQUAL', 38: 'STAREQUAL', 39: 'SLASHEQUAL', 40: 'PERCENTEQUAL', 41: 'AMPEREQUAL', 42: 'VBAREQUAL', 43: 'CIRCUMFLEXEQUAL', 44: 'LEFTSHIFTEQUAL', 45: 'RIGHTSHIFTEQUAL', 46: 'DOUBLESTAREQUAL', 47: 'DOUBLESLASH', 48: 'DOUBLESLASHEQUAL', 49: 'AT', 50: 'ATEQUAL', 51: 'RARROW', 52: 'ELLIPSIS', 53: 'OP', 54: 'AWAIT', 55: 'ASYNC', 56: 'ERRORTOKEN', 57: 'COMMENT', 58: 'NL', 59: 'ENCODING', 60: 'SEARCHPATH', 61: 'IOREDIRECT', 62: 'DOLLARNAME', 63: 'ATDOLLAR', 64: 'ATEQUAL', 65: 'BANGLBRACKET', 66: 'DOUBLEAMPER', 67: 'BANGLPAREN', 68: 'DOLLARLBRACE', 69: 'ATDOLLARLPAREN', 70: 'QUESTION', 71: 'ATEQUAL', 72: 'ATDOLLAR', 73: 'DOUBLEPIPE', 74: 'ATLPAREN', 75: 'DOLLARLBRACKET', 76: 'DOLLARLPAREN', 77: 'DOUBLEQUESTION', 14: 'PLUS'}
```

xonsh should make a copy before mutating it. 


Discussion:
I forgot GitHub doesn't soft-warp stuff in code blocks. Notice this part:

60: 'SEARCHPATH', 61: 'IOREDIRECT', 62: 'DOLLARNAME', 63: 'ATDOLLAR', 64: 'ATEQUAL', 65: 'BANGLBRACKET', 66: 'DOUBLEAMPER', 67: 'BANGLPAREN', 68: 'DOLLARLBRACE', 69: 'ATDOLLARLPAREN', 70: 'QUESTION', 71: 'ATEQUAL', 72: 'ATDOLLAR', 73: 'DOUBLEPIPE', 74: 'ATLPAREN', 75: 'DOLLARLBRACKET', 76: 'DOLLARLPAREN', 77: 'DOUBLEQUESTION', 

These are all xonsh tokens. The should not be in the standard library `token` module. 
Thanks for reporting @asmeurer. I agree this should be fixed!

Resolving patch:
diff --git a/xonsh/tokenize.py b/xonsh/tokenize.py
--- a/xonsh/tokenize.py
+++ b/xonsh/tokenize.py
@@ -24,6 +24,7 @@
 import builtins
 import itertools
 import collections
+import token
 from token import (AMPER, AMPEREQUAL, AT, CIRCUMFLEX,
                    CIRCUMFLEXEQUAL, COLON, COMMA, DEDENT, DOT, DOUBLESLASH,
                    DOUBLESLASHEQUAL, DOUBLESTAR, DOUBLESTAREQUAL, ENDMARKER, EQEQUAL,
@@ -46,8 +47,7 @@
 #
 # token modifications
 #
-import token
-
+tok_name = tok_name.copy()
 __all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
                            "NL", "untokenize", "ENCODING", "TokenInfo",
                            "TokenError", 'SEARCHPATH', 'ATDOLLAR', 'ATEQUAL',


Test patch:
Repository: xonsh/xonsh

Issue:
_which.py uses python 2.x style next statement
_which.py uses python 2.x style syntax next() statement which causes an error when _which.which() is called on python 3.x
https://github.com/xonsh/xonsh/blob/17450e8a465cb3e0c69071ae5bc44ce51fd09008/xonsh/xoreutils/_which.py#L264 

This currently does not cause any exceptions for a xonsh user. The main which.py only uses _which.whichgen(). However, as a developer trying to make a call into the method, it caused an issue.


Discussion:

Resolving patch:
diff --git a/xonsh/xoreutils/_which.py b/xonsh/xoreutils/_which.py
--- a/xonsh/xoreutils/_which.py
+++ b/xonsh/xoreutils/_which.py
@@ -261,7 +261,7 @@ def which(command, path=None, verbose=0, exts=None):
     If no match is found for the command, a WhichError is raised.
     """
     try:
-        absName, fromWhere = whichgen(command, path, verbose, exts).next()
+        absName, fromWhere = next(whichgen(command, path, verbose, exts))
     except StopIteration:
         raise WhichError("Could not find '%s' on the path." % command)
     if verbose:


Test patch:
Repository: xonsh/xonsh

Issue:
Tab Completion broken for directories with spaces
## xonfig

~ $ xonfig

```
+------------------+----------------------+
| xonsh            | 0.7.3                |
| Git SHA          | 55d69ee6             |
| Commit Date      | Aug 11 10:22:24 2018 |
| Python           | 3.7.0                |
| PLY              | 3.9                  |
| have readline    | True                 |
| prompt toolkit   | None                 |
| shell type       | readline             |
| pygments         | None                 |
| on posix         | True                 |
| on linux         | False                |
| on darwin        | True                 |
| on windows       | False                |
| on cygwin        | False                |
| on msys2         | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
+------------------+----------------------+
```

## Expected Behavior
Tab completion should work even for files with spaces.

## Current Behavior
When using xonsh, frequently tab completion creates broken syntax, especially when spaces are involved in cwd or item being expanded. Sometime between 0.6.7 and 0.7.3, the situation improved, but issues still remain. For example:

```
~ $ cd draft
draft $ mkdir 'Virtualbox VMs'
draft $ mkdir 'VMWare VMs'
draft $ os.listdir()
['Virtualbox VMs', 'VMWare VMs']
```

Then, typing `cd VM^t` yields:

```
draft $ cd VMs/'
```

Which obviously doesn't work.


Discussion:
The issue goes away with `prompt_toolkit` installed and enabled.
Is using prompt_toolkit the preferred usage? If so, are there instructions on enabling it by default?
Hi @jaraco - yes, prompt-toolkit is the preffered frontend.  It is enabled by default if it is installed (since this is what `best` resolves to). There are docs for `$SHELL_TYPE` [here](https://xon.sh/envvars.html#shell-type) or you can see the help in `xonsh --help`
It is weird that this breaks on readline, though.
> It is enabled by default if it is installed.

I suspected this would be the case, so I tried it, but it didn't take effect the first time I tried (although I may have launched xonsh from a readline xonsh, which may have affected it, or I may have not launched a new xonsh correctly at all). To confirm, though, I am seeing prompt-toolkit used by default now.

Resolving patch:
diff --git a/xonsh/readline_shell.py b/xonsh/readline_shell.py
--- a/xonsh/readline_shell.py
+++ b/xonsh/readline_shell.py
@@ -325,7 +325,7 @@ def __init__(self, completekey="tab", stdin=None, stdout=None, **kwargs):
             (False, True, False, True, False): False,
             (False, True, False, False, True): False,
             (False, True, False, False, False): False,
-            (False, False, True, True, True): True,
+            (False, False, True, True, True): False,
             (False, False, True, True, False): False,
             (False, False, True, False, True): False,
             (False, False, True, False, False): True,


Test patch:
Repository: xonsh/xonsh

Issue:
Xonsh wizard crashed
I installed xonsh onto macos using homebrew, started it, and ran the wizard. I told it I wanted to import fish as a foreign shell and accepted all the defaults for every other question.

My wizard experience ended like this:

```
Would you like to enable xontribs now, yes or no [default: no]?

'`-.,_,.-*'`-.,_,.-*'`-.,_,.-*'`-.,_,.-*'`-.,_,.-*'`-.,_,.-*'`-.,_,.-*'


xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
TypeError: sequence item 0: expected str instance, NoneType found
```




Discussion:
Thanks for reporting @mikehearn!

I think that this is because we don't yet support fish as a foreign shell (see #485).  Still it shouldn't crash. 

Resolving patch:
diff --git a/xonsh/xonfig.py b/xonsh/xonfig.py
--- a/xonsh/xonfig.py
+++ b/xonsh/xonfig.py
@@ -147,7 +147,7 @@
 def _dump_xonfig_foreign_shell(path, value):
     shell = value["shell"]
     shell = CANON_SHELL_NAMES.get(shell, shell)
-    cmd = [_XONFIG_SOURCE_FOREIGN_SHELL_COMMAND.get(shell)]
+    cmd = [_XONFIG_SOURCE_FOREIGN_SHELL_COMMAND[shell]]
     interactive = value.get("interactive", None)
     if interactive is not None:
         cmd.extend(["--interactive", str(interactive)])


Test patch:
Repository: xonsh/xonsh

Issue:
hg split keys not being propogated
`hg split` from Mercurial brings up a curses based ui. When I type j/k up/down it just prints the code characters. *If I type j and then hit Enter, it will propagate the keypress.*

Mercurial is written in python, if that makes any difference
https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/ui.py

## xonfig
+------------------+----------------------+
| xonsh            | 0.7.9.dev6.dev6      |
| Git SHA          | ad06426e             |
| Commit Date      | Sep 21 11:55:18 2018 |
| Python           | 3.5.3                |
| PLY              | 3.11                 |
| have readline    | True                 |
| prompt toolkit   | 2.0.4                |
| shell type       | prompt_toolkit2      |
| pygments         | 2.2.0                |
| on posix         | True                 |
| on linux         | True                 |
| distro           | Debian               |
| on darwin        | False                |
| on windows       | False                |
| on cygwin        | False                |
| on msys2         | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
+------------------+----------------------+

## Expected Behavior
Should be able to use arrow keys to move up and down.

## Current Behavior
Just prints characters to the screen ^[OB^[OA

## Steps to Reproduce
If you have mercurial installed, try using hg split

Let me know if you need any more info.

Thanks!


Discussion:

Resolving patch:
diff --git a/xonsh/commands_cache.py b/xonsh/commands_cache.py
--- a/xonsh/commands_cache.py
+++ b/xonsh/commands_cache.py
@@ -371,9 +371,13 @@ def HG_PREDICTOR_PARSER():
 def predict_hg(args):
     """Predict if mercurial is about to be run in interactive mode.
     If it is interactive, predict False. If it isn't, predict True.
+    Also predict False for certain commands, such as split.
     """
     ns, _ = HG_PREDICTOR_PARSER.parse_known_args(args)
-    return not ns.interactive
+    if ns.command == "split":
+        return False
+    else:
+        return not ns.interactive
 
 
 def default_threadable_predictors():


Test patch:
Repository: xonsh/xonsh

Issue:
Ncurses based python app does not run correctly on Xonsh, runs fine on Bash
```
pip install cryptop

...

$ cryptop
```
The app's UI is shown, but pressing any key (A to add a coin or Q to quit) does not work, instead the letter is written to the screen.

Runs fine from Bash.


Discussion:
Hi @amitkot -- thanks for reporting.  We can't always detect ncurses based applications automatically. 

Can you try adding the following to your `xonshrc` and see if the issue persists?  Thanks!

```
__xonsh_commands_cache__.threadable_predictors['cryptop'] = lambda args: False
```
The easier and less-general fix here is to add `cryptop` to the threadable predictor list [here](https://github.com/xonsh/xonsh/blob/master/xonsh/commands_cache.py#L388-L437) with a `predict_false`.

Better would be to figure out a general way to detect if an application is using `ncurses` and set them as non-threadable.

Resolving patch:
diff --git a/xonsh/commands_cache.py b/xonsh/commands_cache.py
--- a/xonsh/commands_cache.py
+++ b/xonsh/commands_cache.py
@@ -392,6 +392,7 @@ def default_threadable_predictors():
         "clear": predict_false,
         "cls": predict_false,
         "cmd": predict_shell,
+        "cryptop": predict_false,
         "curl": predict_true,
         "ex": predict_false,
         "emacsclient": predict_false,


Test patch: