 Okay, now we have a presentation about Promptulkit for people who don't know about Promptulkit. It's used in Python, in several famous products. Big ovation, please. Thank you. I don't have a screen yet. There we go. Good afternoon. This is a presentation about Promptulkit. Promptulkit is a library for building common line applications. For instance, I Python is using it, some other projects are using it, so during this presentation you will see a few examples of projects using that. Promptulkit, actually I presented it about two years ago, so maybe some of you have already seen it back then. In the last two years, I made a lot of progress in Promptulkit, and actually this presentation is a bit about showing the progress and the future where we are going to. The idea about Promptulkit is also to show that common line applications can actually be usable and user-friendly. So very often there is some common misconception maybe that using a common line does mean that something cannot be user-friendly or usable. Promptulkit focuses completely on making common line applications more usable. So this is me. I'm working for Cisco. You can find me on GitHub or Twitter. So Promptulkit. Actually, in the first place, Promptulkit is a GNU ReadLine replacement. So if you know GNU ReadLine, it's actually the library that's used for reading input from the user. For instance, if you're using the Bash shell or ZSH or any shell, every time when you have to type some input, it is the GNU ReadLine library that's actually handling all of your keystrokes. And that means that ReadLine processes your input but also gives feedback, which makes it possible for you to see what you're typing. And ReadLine, for instance, is also responsible for handling the key bindings and so on. So in Python, if we would execute input call, or in case you're using Python to store the raw input call, they are using ReadLine. So these are places where you ask for input and then there's the ReadLine library handling that part. So these are a few screenshots and any of these applications, ReadLine is used. Now, ReadLine, actually, it's implemented in C. It has a history of many years. It's good in a way that it's a very cross-platform, but it's hard to make changes to ReadLine because it's written in C and it's hard to add functionality because you cannot break something and people are relying on how it works. So PromTokets tries to do a bit of that. Basically, it comes down to we take some input on the left side and these are the escape sequences that you see over there. Then there's PromToket in the middle that processes all those key bindings and reacts to whatever handlers you have attached to the key bindings. And then it renders the output to the terminal, usually also using that kind of key strokes. We have both Windows and Linux support, or Mac support. So this is what PromToket would do in the case of a Linux system or a Mac system. In the case of a Windows system, we use the Windows API for interacting with the Windows console. So we have a bit of the ReadLine functionality, which includes auto-completion, incremental search, VI and e-max key bindings, and there's an input history. Now the interesting part, what can we do more than ReadLine? And in the first place, we can do syntax highlighting. And unfortunately, I cannot show a demo because it doesn't work well with the microphone and in this setup, but you should imagine that we have a prompt that asks for HTML as input. And then while typing, while the user is typing, we are actually able to provide syntax highlighting. And that's something which is extremely interesting when you want to build an interactive shell for, for instance, maybe a database client. If you are going to write an SQL client, you want to have SQL syntax highlighting. Syntax highlighting is something very nice to have and very user-friendly. Further, we have auto-completion. ReadLine also has auto-completion. And PromToket is able to display the auto-completion just like ReadLine does. But we also have a different way of showing that using this kind of auto-completion menu. So if you press the tap key, you get a drop-down like this just in your normal terminal. And here we have a screenshot of Windows. So even here you have the same kind of auto-completion in the console. We have several ways of rendering the auto-completion. So you can have multiple columns, one column. You can style the colors as you wish. A second thing is input validation. And input validation is something quite nice to have in an interactive shell like a Python shell. Let's say you're typing something and you forgot a quote or a closing parenthesis causing a syntax error. So rather than displaying a message, you have a syntax error and asking the user to input the same quote again. What we do is we just display the message syntax error and we move the cursor to the place where the user had a syntax error. So that saves quite a lot of time. This by the way is the PT Python shell, an alternative Python shell that I made. But I Python has now the same functionality. We also have multi-line editing and that's something that many people have been missing for a long time in Python. So in a normal Python shell you can answer multi-line statements, but it's impossible for the cursor to move back up through the lines. So let's say you have code like this and you want to insert a new line in the middle of this code. That's just impossible to do with a normal Python shell. And PromToolKit implements some multi-line editing which makes the Python shell more pleasant to use. Further, we have Moist support which means that you can use the Moist pointer and if you click, you can move the cursor wherever you want if that's enabled. So in code what does it take? Just do pip install PromToolKit and then you have that as a library available and you can use it in any application. The easiest example for using that is just importing the prompt from PromToolKit at Shortcuts. You call it and then you get the interactive prompt and the result is assigned to the answer variable. So this is basically a replacement for the input call. The syntax is the same. But the prompt function takes further a lot of additional arguments. For instance, if you pass multi-line equals true, you can ask the user for multi-line inputs. Or if you pass it password equals true, then the input is displayed in asterisks. Or you can make things in VI mode. You can pass a lexer if you want to have syntax highlighting. You can pass a validator if you want to have some custom input validation. You can pass a complete style as used for the colors. So if you want to change the colors, you can pass a different style. By the way, for lexers and for styles, we support pigments. So if you want to use a lexer, which is already implemented by the pigments syntax highlighting library, you can reuse that and the same for the style sheets. But you don't have to use pigments, of course. A more complex example is a custom CLI that does completion in this case on animal names. And in fact, it's quite simple. You can create a word-completer instance that tells the words that a prompt look at has to use for suggesting other completions. You can pass a style like this that's completely optional, but maybe you want to change the colors, and then you pass both the complete and the style object as an argument to the prompt function. So the community is growing a bit compared to two years ago. So maybe you cannot read it, but that's a list of all projects that are now using prompt toolkit. And among them, we have several database clients like a Postgres client, MySQL client. The one on the right, by the way, is PGCLI, which is very nice. Postgres client, which has all those features like syntax highlighting and code completion and so on. And I'm just going to show a few examples of projects using screenshots. So we have already discussed PT Python as an alternative Python replete that has most of the functionality. It also has a nice menu where you can change the settings and styles and all the options without leaving the replete. PT Python also has an history. So if you want to fetch lines back from history by composing several entries from the history together, you can go to this history window. You just scroll up and you select the entries that you want in your replete. So last summer, Python 5 was released and before that, I've worked together quite a lot with several of the Python code developers and we managed to get the prompt toolkit functionality as part of Python. It was quite a challenge because there was a lot of legacy code we had to rewrite, but the end result is that everything that you've seen so far is no part of the Python shell, which means code completion, multi-line editing and so on. There's also SAWS, which is an Amazon AWS client. It's a bit similar. It has also those completion menus. There's Conch, which is an alternative shell. So it's an alternative for Bash, but written in Python. In fact, it's quite usable. It's quite easy to use. And the nice thing is that in the shell, you can use the normal Bash commands like CD and so on. But actually, you can also type Python in this shell. And I believe it's quite scriptable. I'm not an expert in Conch, but there is a very nice presentation about it from Python last year. So maybe you want to look at that. There's HTTP prompt, which is a front-end for HTTP. So it combines those two libraries. So which is a nice way for debugging HTTP requests. Then we have a few full-screen applications. In the first place, we have PyVim, which is actually a VI cone in Python. And there's actually a little story behind it, because two years ago when I presented this talk about prompt, somebody in the audience asked me, what does it take, actually, to write a real editor using this? Because I had most of the functionality. I had those editing functionality, all of those read line key bindings, which in the end are not that different from what VI does. And so we have PyVim. You can play with it. I'm not saying I'm not using this all the time. It has some issues with big files, and there's, of course, still missing some functionality. But the basic features, what you're expecting from VI, are actually working. And even things like horizontal and vertical splits and completion, and some of the comments are working in PyVim. So actually, you can more think of it as a showcase of what's possible with prompt, rather than actually something you want to use. Further, we have PyMux, which is actually a T-Mux cone in Python. So maybe you know T-Mux. There's very nice terminal multiplexer. It allows you to split the terminal in several panes, where in each pane, you are actually emulating a terminal. And nice thing about T-Mux is that you can detach from the terminal and attach and attach at several clients at the same time. PyMux does actually most of that. And the performance actually is quite well. When it was released, like I think about a year ago, the performance was not that good, but right now, it's almost comparable with T-Mux, actually. So if you like terminal multiplexers, you may want to try this. It has some features, actually, that T-Mux does not have. Like there's a completion menu, if you go in a command line mode, there is highlighting of search, if you search through the scroll back buffer. So it has some additional features, but it's also missing some of the functionality that T-Mux has. Then I actually never announced this, so probably nobody is using it. But as a proof of concept, I made a pager in Python. So maybe you know what there's something like less and more, which are, and most, which are actually pagers for displaying man pages. And the interesting thing about the pager is that it can take a stream as input. So if you do a tail on a file, or if you have a very large file, and you pipe it in a pager, then the pager does not have to read the whole file into memory, but it streams. And actually, that's what I was trying to do in PyPager. And actually, it's working quite well. So maybe in the near future, I want to do some more development on this. I'm not sure yet. So actually, if you're interested, maybe have a look. So now we are going to watch PromToolkit 2.0, and it's actually a big refactoring that's more focused on full screen applications. So something like, we have Arwet right now in Python, which is used for building full screen applications. But so far, the architecture of PromToolkit, while it was user-friendly for having simple prompts like in read line, the API for building full screen applications was not that user-friendly. And I got a lot of questions in the last two years from people asking for help for building those things. And I realized that there were some things that I had to change. Right now, I don't have the time, I guess, to go more in detail. But the idea is that PromToolkit 2.0 will have more the concept of widgets. Like if you are designing a graphical user interface, you think about widgets like a button, like a menu, like a scroll bar. And those widgets, they can be focusable and they can have key bindings. And actually, that's what we try to do in PromToolkit. I'm almost there, but probably it will take a few more months to be sure that the API is stable, that we have the documentation, the examples, and that we are ready for releasing that. This is an example of what it can look like. This is actually a working example that I've like right now on the 2.0 branch. You see that there's a menu at the top where there are two input fields. There are two buttons at the bottom. And by using the tap key, you can actually switch between all those fields. And given that is PromToolkit underneath, that means that for, for instance, the input fields, you can have things like syntax highlighting and code completion and so on. But there's still some work to do to have a nice collection of widgets, but we are getting there. So that means that also given that the API is going to change, we will have to rewrite PyVim and PyMux, which I intend to do just for testing the API to make sure that we make the right API decisions before releasing it. Because I'm sure that while I'm rewriting these applications, against PromToolkit 2, I will discover some, maybe some inconsistencies in the API or some things that have to change. So because of that, we need a bit more of time. I guess I've said the most things at the bottom. At the top, I mean, there's some refactoring in the event loops. Not super important. We think about supporting input RC. Many people ask me for having input RC support because they have custom key bindings in Redline. They want them to have them in PromToolkit as well. And better Windows support. Windows 10 now supports ANSI escape sequences, which means that we can use VT100 escape sequences on a Windows system. And that should make the rendering much more fluent. So this is the state where I am right now. As you can see, there are quite a lot of changes. There's not much more functionality. It's mainly refactoring to the code base. But we are coming there. And that's all I have. So thank you. Questions? Yeah, we still have five more minutes. So in case there are any questions, feel free to ask them. Yes? For the key bindings, do you use the same syntax as a new Redline? So for the key bindings, we actually have a custom seed syntax, which is quite pytonic. But we intend to support parsing the Redline syntax because we are going to support input RC. And in input RC, you can have Redline key bindings. So actually, the intention is to be able to parse those key bindings and turn it into PromToolkit key bindings. And that's actually intention. We are not there yet, but that's not to do list. Yes? Yes, we had PromToolkit 1 for commonline interface. We had Ovid for a widget-like interface. Why to do a PromToolkit 2 Ovid-like? Yes. Which one is the best, changed from Ovid to PromToolkit 2? Why change from Ovid to PromToolkit? If you're using Ovid, you can keep using that. That's perfectly fine. But there's a lot of functionality in PromToolkit that Ovid does not have, things like syntax highlighting all those key bindings. The Redline key bindings are extremely complex. There are thousands of key bindings, especially if you go in VI, where key bindings are composed. Ovid does not have that. And rewriting that on Ovid would take a lot of time. And it turns out that people are extremely sensitive when key bindings that they're used to are suddenly not available anymore. So if that's important to you, then maybe you can use it. But Ovid is perfectly fine as well. OK, thank you. Thank you, Ovid. That was interesting. Is that what you're looking for? Yeah.