StaSh updates - Unified I/O UI, external keyboard support and more

ywangd

I thought about using pyte as the text buffer backend for StaSh after unifying the I/O UI.

The greatest advantage of using pyte is that a proper terminal emulation will be in place for programs like ssh and telnet. But most other scripts do not benefit from pyte at all. In fact, it could complicate otherwise straightforward tasks. So it does not seem to justify the effort of integrating pyte for just a few scripts. In addition, at this stage, I am reluctant to introduce any external dependencies.

@briarfox coded the ssh script using pyte, which works well in stash. My guess is that one shall be able to write a telnet script in similar fashion.

I will give it some more thoughts in future development. For now, scripts like ssh or telnet has to explicitly call pyte to handle control sequences and StaSh only renders the final outcome (plain strings).

polymerchm

Got this error using git push from stash. Worked fine from shelista. Still get os.fork() not allowed from gitui

dgelessus

Either you mistyped the URL, the saved URL in your repo's config is incorrect, or you weren't connected to the internet. (This has nothing to do with os.fork AFAICT.)

polymerchm

I agree there not connected. Still trying to get the non-os.fork() version dulwich. Not sure how to.

ywangd

@polymerchm If you delete your existing dulwich and gittle folders, the first call to git in stash will automatically fetch the right versions of the two libraries into $STASH_ROOT/lib.

@JonB is the owner of the script and may be able to share more insights about how it works.

polymerchm

Erased every instance of dluwich and gittle in my directory tree. Gitui would not run because it could not find the desired modules so they were indeed gone. Ran git in StaSh and it uploaded and installed. Then ran gitui and tries a push. Here is the traceback

Traceback (most recent call last):
  File "./uidialog.py", line 119, in dispatch_ok_action
  File "/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/gitview/gitui.py", line 572, in push_callback_dict
    push_callback(d['username'],d['password'])
  File "/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/gitview/gitui.py", line 565, in push_callback
    porcelain.push(repo.path, remote, branch_name, opener=opener)
  File "/private/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/stash/lib/dulwich/porcelain.py", line 505, in push
    r.object_store.generate_pack_contents, progress=errstream.write)
  File "/private/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/stash/lib/dulwich/client.py", line 441, in send_pack
    proto, unused_can_read = self._connect('receive-pack', path)
  File "/private/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/stash/lib/dulwich/client.py", line 648, in _connect
    stderr=self._stderr))
  File "/private/var/mobile/Containers/Bundle/Application/8E9E015C-170F-4CBB-9AC7-65AE8AF9AE12/Pythonista.app/pylib/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/private/var/mobile/Containers/Bundle/Application/8E9E015C-170F-4CBB-9AC7-65AE8AF9AE12/Pythonista.app/pylib/subprocess.py", line 1205, in _execute_child
    self.pid = os.fork()
OSError: [Errno 1] Operation not permitted

git push from StaSh kill the program w/o a traceback. If I run shellistta, it imports another set of dulwich, gittle etc. git push from it is succcessful, but not from Stash or gitui.

ywangd

@polymerchm What exactly do you mean by "kill the program w/o traceback"? Did "git push" crash stash or itself just ended w/o error message or crash the whole Pythonista app?

If stash is still usable after "git push", you can try add py_traceback=1 to .stash_config file, or directly search and replace in the source code (stash.py) (change py_traceback=0 to py_traceback=1) to make stash print the full stack of traceback messages.

polymerchm

Nevermind. StaSh seems fine "now". Based on the traceback, gitui on my "stack" seems to call dulwich.porcelain which calls pylib/client.py in site-packages and calls subprocess (iOS no-no). Where is the dulwich library that you use located?

ywangd

@polymerchm
Is the server side repo that you are trying to push into a local one, i.e. the repo resides inside Pythonista, not on GitHub.

Based on my quick browse of dulwich/client.py, the code seems to always shell out for native git when the push path is a local path.

ywangd

dulwich is very sensitive to the url scheme you are trying to push. Not only local path, if you have a typo, e.g.: htp:// or htpp:// or http//, it will calls out for default/subprocess git client, which will throw the "operation not permitted" error.

wradcliffe

This new version is quite excellent. Great work. The UI makes so much more sense now and just works ask you would expect.

The support for external keyboards is mostly working for me. I can not seem to get the cmd-U/D to work. Can you give me a suggestion on how to debug this? Is there some easy way to log what it coming in from the external keyboard? I see that there are some --debug command line options.

As a stretch, I would like to see if I could hook the up down arrows on the keyboard to do history up down instead of allowing the cursor to move up or down in the view. There does not seem to be any utility to allowing the cursor to move off the command input line anyway.

Speaking of the cursor - in the default config it is a blinking blue line. Is this configurable? I would like to switch to white as the blue is difficult to see on a black background.

This shell is so good at this point that it should be part of the distribution IMHO. Pair that with a README on how to do some basic git stuff and you could make a lot of peoples nooby problems go away.

JonB

Poly, I suspect what is happening is that you are doing something like

git push origin

Dulwich treats this as a Local repo, and uses subprocess. I have a patch for the git command that checks the list of remotes for matching names, and replaces with he url, but haven't posted it yet, will do so tonight. The older git command requires you to use https://github.com/owner/repo.git

polymerchm

the only problem is only in gitview (gitui). I hit the "push" button and off we don't go. See the traceback above in this thread. What would be nice woudl be:

git branch  some_new_branch

ywangd

@wradcliffe

The cursor color can be configured via the TINT_COLOR option in the .stash_config file. For the white color, just set TINT_COLOR=(1.0, 1.0, 1.0) under the [display] header (check _DEFAULT_CONFIG in the source code for an example).
The support for cmd+up/dn really is just an approximation, because the UI system does not have any events to handle special key strokes. One important note is do NOT mix use of on-screen Up/Dn buttons and external keyboard.
The way it works is to detect whether the cursor is now at (0, 0), i.e. position 0 with 0 char selected. This is basically what the cmd+up key combo does in a TextView. At least that's how it works with my Bluetooth keyboard (Logitech keys-to-go). So if your keyboard also moves cursor to the very beginning of a document when cmd+up is pressed (you can test that in Pythonista builtin editor) and the cursor was previously at input position, it should work for navigating up through the history.
Navigating down (cmd+dn) through the history is a bit more involved. But in principle it detects whether the cursor is now at the end of a document (what cmd+dn does). So if your cmd+dn key does that and the cursor is at input position, it should be good.
By now you probably see why I didn't map just up/down to history navigation. Because there are too many variations of the results thus not reliable. Plus it is impossible to implement the history down with just the down key.
Currently there is no easy way for you to debug the external keyboard bit (not without modifying the source code). The debug options are mostly for the parser and runtime. I'll keep this noted and see if debug system can be improved.
Thanks for your nice words. I am glad to know you like it. It would be a great honour for StaSh to be distributed as part of Pythonista. But I won't get my hope high on that.

polymerchm

@ywangd

How do you capture a keyboard event? I'd like to enable external keyboard interaction with chordcalc, but really have no idea where to start. Looking at your code does not make it any clearer. Not your code, my ignorance.

JonB

Git branch -b creates a new branch.
Also, you can copy .git/refs/heads files to another name.

JonB

Also, in gitview, be sure to select remote before pressing push.

JonB

I think you can only capture keyboard events inside a textview, using the delegate methods. Specifically, you can look for specific types of cursor movement.

wradcliffe

@ywangd - thank you so much for the detailed explanation. I believe that the reason I am not seeing correct behavior for cmd-up/down is that my keyboard is a relatively old Logitech Ultrathin. It has fn, ctrl, option, cmd and the arrow keys but they do not seem to produce all the correct codes for ios. I have to use the fn keys for select, cut, copy, paste. Arrow keys work fine. Probably should upgrade to a newer model.

dgelessus

@polymerchm, this proof of concept I wrote demonstrates how external keyboard input can be detected. The only problem is that the cursor needs to stay inside a text field all the time, if something else is focused no more keyboard inputs are handled. You'd also need to somehow detect whether someone is using an external keyboard (which I don't think is possible) and disable the text field if they don't - otherwise the on-screen keyboard would display and cover half of your app.