prompt_toolkit 2.0 - Will be released soon.

[jonathanslenders]

No description provided.

[biermeester]

Hi Jonathan, just I few things I noticed when playing with 2.0 on Windows (in cmd.exe):

• The default style displays black text on black background:
  

• Some examples (yes-no...py and confirm.py) raise an exception when I exit them using [Ctrl+Q], on both Linux and Windows (with Python 3.6)

Traceback (most recent call last): File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\application.py", line 487, in run self.loop.run_until_complete(f) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\eventloop\win32.py", line 62, in run_until_complete self._run_once() File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\eventloop\win32.py", line 93, in _run_once self._process_queued_calls_from_executor() File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\eventloop\win32.py", line 174, in _process_queued_calls_from_executor c() File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\application.py", line 312, in redraw self._redraw() File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\application.py", line 349, in _redraw self.renderer.render(self, self.layout) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\renderer.py", line 439, in render ), Token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 218, in write_to_screen WritePosition(xpos, ypos, width, s), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 470, in write_to_screen WritePosition(xpos, ypos, s, height), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 529, in write_to_screen self.content.write_to_screen(app, screen, mouse_handlers, write_position, token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 218, in write_to_screen WritePosition(xpos, ypos, width, s), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 470, in write_to_screen WritePosition(xpos, ypos, s, height), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 218, in write_to_screen WritePosition(xpos, ypos, width, s), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 218, in write_to_screen WritePosition(xpos, ypos, width, s), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 470, in write_to_screen WritePosition(xpos, ypos, s, height), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 470, in write_to_screen WritePosition(xpos, ypos, s, height), token) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 1300, in write_to_screen align=self.align) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 1537, in _copy_body self._highlight_digraph(app, new_screen) File "Z:\blurp\lib\prompt-toolkit\prompt_toolkit\layout\containers.py", line 1597, in _highlight_digraph cpos = new_screen.cursor_position AttributeError: 'Screen' object has no attribute 'cursor_position' 

Hope this is useful, somehow. Keep up the good work.

[jonathanslenders]

Thanks for pointing out!

[biermeester]

I tried out the new radio_dialog example on Windows 10 and I noticed it ran very slowly. Not sure what's going on, but cProfile shows a ridiculous amount of calls. (All I did was, launch the script and exit it by pushing [tab] and [enter])

 ncalls tottime percall cumtime percall filename:lineno(function) 5415876 0.793 0.000 1.035 0.000 from_dict.py:175(<genexpr>) 3302371/3302326 0.243 0.000 0.243 0.000 {built-in method builtins.len} 3293151 2.745 0.000 5.257 0.000 {built-in method builtins.sorted} 2579272 0.223 0.000 0.223 0.000 {method 'append' of 'list' objects} 2137871 0.763 0.000 1.799 0.000 {built-in method builtins.sum} 2123090 0.688 0.000 2.482 0.000 from_dict.py:174(flattened_len) 2123044/46 5.856 0.000 8.093 0.176 from_dict.py:157(get_combos) 437446 0.030 0.000 0.030 0.000 from_dict.py:194(<lambda>) 23356 0.008 0.000 0.008 0.000 {built-in method __new__ of type object at 0x5D2C9CA8} 21054/20264 0.006 0.000 0.043 0.000 {built-in method builtins.isinstance} 14501 0.003 0.000 0.023 0.000 {built-in method builtins.next} 14386 0.003 0.000 0.003 0.000 {built-in method builtins.min} 12180 0.019 0.000 0.020 0.000 utils.py:215(take_using_weights) 11753 0.002 0.000 0.002 0.000 {built-in method _ctypes.byref} . . . 

[jonathanslenders]

Hi @biermeester, the start-up time should be much faster now. There were some issues with the calculation of the style. Could you try again?

If it's still slow, for Windows 10, I still have to implement the vt100 rendering backend. The Windows console supports now vt sequences, but this needs to be enabled.

[biermeester]

Works fine now!

[kalafut]

Hi @jonathanslenders. I'm totally new to the library and was looking into using this branch, since it is the future. One very basic question that was not obvious from the docs and code: how does one modify container contents? Say I have an HSplit with 4 widgets and I want to insert another one in the middle programmatically, is there a standard way? Nothing short of rebuilding the tree or mucking with internal structures was really apparent from a quick look at the code.

Thanks, Jim

[jonathanslenders]

TODO list:

• synchronous autocompletion
• refactoring of the style definition (Tokens)

[asmeurer]

If I might make a suggestion here, I often find it quite confusing, particularly when writing key binding code, about the distinction between buffers and documents. I always have to search to find out which attributes are on which, and it's even more confusing that some are on both (but, apparently, you should never mutate a document; I only found this out from reading the code).

I don't know if it makes sense to merge them. I think I am starting to understand the difference between the two (although not enough to reliably guess if a given attribute will be on one or the other). A document is a container of text, and a buffer is a document + a cursor position + things like selection and completion popups (is that right?). Perhaps it makes sense to go all the way and make all attributes of Document also attributes of Buffer (or "smart" attributes like text that do the right thing when mutated).

I also want to add that I think buffer needs way more "edit level" commands, that make it easier to manipulate the text. Maybe these are already there and I just don't know about them. When implementing things like a "comment/uncomment block" key binding, or even just one space, I have to be very careful to tear apart the text, rearrange it, and put it back. What's annoying is the bookkeeping to keep the cursor in a reasonable position. But even if I am sloppy with it, I at least have to do buffer.cursor_position = min(buffer.cursor_position, len(new_text)), and I have to do it before setting buffer.text = new_text, or else prompt toolkit crashes with an AssertionError because the cursor position is too large. It would go a long way if the buffer.text setter just moved the cursor to the end instead of crashing.

[jonathanslenders]

Hi @asmeurer,
I do understand the confusion between Buffer and Document.
We can't merge them however. The reason is that Document was made immutable on purpose. This is what makes it possible to cache all the expensive fields from the Document class. If a new document with the same text and cursor position was created, we don't have to recalculate any of these fields. The Buffer class on the other hand, is mutable. You can store a new text or cursor position in there.

However, your comment regarding the assertion error when setting text, forcing you to do this: buffer.cursor_position = min(buffer.cursor_position, len(new_text)), that is something I could add, so that you don't have to do it every time.

[asmeurer]

What about copying more attributes from document to buffer, so that the end user never has to deal with the document (unless he needs to go low level). For example, it would be awesome if you could mutate Buffer.text_before_cursor and it did the right thing (changed the part of the text before the cursor and kept the cursor in the same logical position).

[ghost]

hi, I am following this PR with great interest since its beginning. At the moment it looks quite good. Is this going to be released soon?

[jonathanslenders]

Hi @markfink,

This is probably going to take at least a few more months for a final release, I hope to release it before the end of 2017.

There are still bugs to be fixed and more testing needs to be done. Today I fixed a few bugs regarding to Windows support. There's also a lot of documentation that needs to be written.

In any case, it's moving forward steadily, and I'm really happy with how things are going so far.

Jonathan

[jonathanslenders]

Hi everyone!
Prompt_toolkit 2.0.1 has been released.

Check out the changelog: https://github.com/jonathanslenders/python-prompt-toolkit/blob/2.0/CHANGELOG
and the documentation: https://python-prompt-toolkit.readthedocs.io/en/2.0/

It would be nice if at some point, we can have all prompt_toolkit applications running on 2.0. ;)
Please let me know if you have any questions or need help upgrading.

Cheers,
Jonathan