Hi everyone,

I'm opening this issue to discuss whether or not we should rename prompt_toolkit to prompt_toolkit2.

The problem that we are facing right now is that we want to release version 2.0, but it's backwards incompatible with 1.0. This would normally not be an issue, because the best practices tell you to install Python applications in a virtualenv. However, most prompt_toolkit applications are system tools, which are often installed with the system wide Python installation, and very often these are distributed through other channels like the repositories of Linux distributions. We don't want to break those.

As I understand it, setuptools can install multiple versions of a package alongside each other. There is a __requires__ variable that is inspected by pkg_resources to make sure the right version of the package is loaded. (See, e.g.: https://stackoverflow.com/questions/13720065/what-does-requires-mean-in-python ). However, I'm not sure how well this works in practice.

While I don't like it, if renaming this library to prompt_toolkit2 during a transition period is the only way to solve certain issues, then I'm in favor of doing it. The intend is to rename it back to prompt_toolkit when most applications are transitioned. (At that point, prompt_toolkit2 could remain an alias for prompt_toolkit.)

I don't have much personal experience with issues like this, so all feedback is welcome.

Hi! It seems like using prompt-toolkit with xonsh reserves 8 lines at the bottom minimum. See https://github.com/jonathanslenders/python-prompt-toolkit/blob/9e96e1bf815b07edb5c266bf2ba9ae1d6e350746/prompt_toolkit/shortcuts.py#L232-L238 This is far too large to be usable for me. Is there any way that this could be customizable in some way? I'd really appreciate it...

See the xonsh list for more discussion: https://groups.google.com/d/topic/xonsh/Y3L9GAcFwGM/discussion

Due to this line, ANSI escape codes are mangled and cannot be used by an application that also uses the patched stdout functionality. I was going to colorize messages from logging in my program with a formatter, but because of this it's not possible. I'm not even sure what the intent was here?

https://github.com/jonathanslenders/python-prompt-toolkit/blame/master/prompt_toolkit/terminal/vt100_output.py#L184

To not sound like a total downer, this module is super amazing and is really damn useful.

This is a proposal for an implementation of text selection using shift + cursor movement as is customary in many GUI. This refers to issue #979.

The implementation is based on defining a new boolean flag shift_mode in the SelectionState class. shift_mode is initialized to False by the class constructor and set to True by a call to SelectionState. enter_shift_mode() whenever a shift+movement binding is called to start selecting text in this fashion. There is an associated new shift_selection_mode filter. The advantage of proceeding this way are that

1. the shift_mode flag is automatically destroyed when selection is exited by any means through any other bindings (because the SelectionState instance is destroyed). In that way, we are sure that the shift_mode flag will not persist to True by accident.
2. it enables the shift-selection mode to co-exist for example with the Emacs marking mode (entered with ctrl-space). In principle, it could also co-exist with the vi-mode, but I haven't tested that as I am really not familiar with vi - so at the moment the corresponding binding definitions are only defined alongside the Emacs bindings, though they could in principle be defined with the basics bindings with some extra testing and tweaks.

Behavior:

• Shift + any cursor motion starts or extend the selection, accompanied by the corresponding cursor movement.
• A cursor movement without shift will exit the selection (and moves the cursor).
• The selection is replaced by any text that is typed (including enter, if multiline; backspace, which deletes the selection; and pasting/yanking - note: more tests might be needed here especially with regard to multiline paste).

Cursor movements above refers to left, right, up, down, home & end (beginning & end of line), ctrl-left/right (word-by-word), ctrl-home/end (beginning/end of buffer). All missing shift- combinations of these keys have been added to keys.py (and set by default to do nothing in bindings/basic.py). Ctrl-home/end have also been added, with the corresponding commands implemented as new readline-style commands in named_commands.py. For completeness, ctrl/shift-insert keys have also been added as these are sometimes used for copy/paste. All these new key combinations are correctly converted to key-presses in input/win32.py.

I have tested this implementation stand-alone as well as in IPython 7.6.1 (through applying the same changes to prompt_toolkit 2.0.9 - apart from removing the type hints). Everything seems to work well, without any changes required to the IPython source code itself.

Happy to get some feedback at this stage, of what could be improved or done differently. I will continue to do more testing with multiline pasting in the meantime.

Have a look at following escape sequences: before_prompt, after_prompt, before_output, after_output:

https://groups.google.com/forum/#!msg/iterm2-discuss/URKCBtS0228/rs5Ive4PCAAJ https://iterm2.com/shell_integration.html https://github.com/asmeurer/iterm2-tools/blob/master/iterm2_tools/shell_integration.py

See: https://github.com/ipython/ipython/issues/8724

This uses IPython input transformer to detect if the syntax is correct IPython.

Things that are invalid IPython do not go through : 1 ! 1 do not validate; a =! ls still does. ?,??do validate; not ???. And so on and so forth.

Successor to #1159, but with a nice, compact commit history. Here is the original description:

Fixes issue #1158, and seems to work in Xonsh as well.

Depends on ThreadedHistory and Application being able to rendezvous on same event loop. While this may not be possible for history in general, I think it is an acceptable restriction on ThreadedHistory.

Debugging applications on windows under a debugger/ide can be difficult because the IDE may use its own 'console' which Prompt Toolkit is unable to use productively. This PR makes it possible to set an environment variable which allows Prompt Toolkit to create a console window and attach the appropriate handles to allow the program to use the console productively.

Hey,

I know that currently you can use vt100 to get GREN/BLUE ... etc, though if you create your own style that should work with pygments, it wont be accepted as these string won't be detected as correct colors.

Pygments recently added the ability to do that, except the names are slightly different, so this (once finished) should allow to have themes that works correctly with both Pygments 2.2+ and Prompt Toolkit and get the correct ansi escape sequences.

I am having problems with prompt-toolkit 1 after getting the newest update to Windows (Insiders slow ring build 17692).

Both xonsh (#2703) and ptpython with ptk1 causes the terminal window to exit when I start the programs. No error messages or anything. The conhost terminal window just disappears.

I haven't tried to debug this yet, to see when it happens. But I will try it this weekend.

I would really love to see if this is a problem with PTK 2 as well. Is there any application I could try to test that?

Could we have an option so that prompt only accepts a single line, even when pasting some text ?

Currently, even when multiline is set to False, you can paste multi-line text in it.

Code: Here's the code i am using:

PROMPT_TOOLKIT_HISTORY = prompt_toolkit.history.FileHistory(conf.histfile)
# ScapyCompleter is a quite basic completer, returning all matching content as a shell would do
_completer = ScapyCompleter()
from prompt_toolkit.token import Token
prompts_style = prompt_toolkit.styles.style_from_dict({
    Token.Prompt: "#2E64FE",
})
def readLineScapy(prompt):
    result = ""
    end = False
    while not end :
        if not end and result != "":
            line = prompt_toolkit.prompt(u"... ", completer=_completer, history=PROMPT_TOOLKIT_HISTORY)
        else:
            line = prompt_toolkit.prompt(u">>> ", completer=_completer, style=prompts_style, history=PROMPT_TOOLKIT_HISTORY)
        if line.strip()[-1:] in [":", "(", ",", "\\"]:
            end = False
        elif result == "":
            end = True
        if line.strip() == "":
            end = True
        result = result + "\n" + line
    result = result.replace("\\\n", "")
    return str(result)
# Run console with python_toolkit
code.interact(banner="hello, this is a great shell", readfunc=readLineScapy)

The goal of this code is to emulate a shell. In that way, we need to print "..." or ">>>" on each line. readlinescapy is using prompt_toolkit.prompt to get the same input as in a shell...

When one copy multi-line, the prompt function takes all the lines, so ... is not printed.

Hi, I'm still having some problems with select.select raising an exception "ValueError: filedescriptor out of range in select()" in src/prompt_toolkit/input/posix_utils.py", line 72 if the file descriptor number is too large (>1023). This happens when passing in a pipe instead of stdin during testing. It seems to be similar to problems that were already discussed in #354.

What makes this especially problematic is that the exception occurs inside the prompt loop which results in the prompt (and pytest) hanging indefinitely. A simple test to reproduce the problem:

import os
from typing import NamedTuple

import pytest

from prompt_toolkit import PromptSession
from prompt_toolkit.input import create_pipe_input
from prompt_toolkit.input.base import PipeInput
from prompt_toolkit.output import DummyOutput


@pytest.fixture
def prompt():
    file_descriptors = []
    try:  # if an "OSError: Too many open files" is thrown, you may need to adjust the fp limit (`ulimit -n`)
        for _ in range(512):  # this should be enough to create a file descriptor > 1023
            read_fd, write_fd = os.pipe()
            file_descriptors.extend([read_fd, write_fd])
        with create_pipe_input() as input_:
            session = PromptSession(input=input_, output=DummyOutput())
            yield Prompt(session, input_)
    finally:
        for fd in file_descriptors:
            os.close(fd)


class Prompt(NamedTuple):
    session: PromptSession
    input: PipeInput


def test_too_many_open_files(prompt):
    prompt.input.send_text(f"foobar\n")
    # the prompt will hang if `select.select` is used because it causes an exception "filedescriptor out of range"
    prompt.session.prompt("foobar")

As discussed in #354, it is possible to easily fix this by replacing select.select with select.poll. I have added a patch which seemingly fixes this: select_poll_patch.txt

These changes mean that Windows will return NotImplemented when attempting to scroll beyond their scrollable limits.

This means mouse scroll events can bubble up to a scrollable parent container when a window has finished scrolling.

In the following screen recording, you can see that when the TextArea is moves under the mouse while scrolling the parent pane, it begins scrolling, and when the TextArea has scrolled all the way to the bottom, the parent pane resumes scrolling:

nested-scrolling.webm

I've also changed the reported line-count of the DummyControl to 1 rather than 100*100 for this to work. Without this, Windows without content believe their DummyControl is always scrollable and accept all scroll events. I can't find any issues with doing this - why was the DummyControl's content's line count set to 100*100?

Hey man, i found a typo in one of the library files

file has "is_windows", "is_windows_vt100_supported", "is_conemu_ansi" and "in_main_thread" i believe that this should be "is_main_thread".

version: 3.0.36 file: utils.py line: 214

I'd like to display the result of parsing a date to the user in real time as they type it. It would be nice to be able to do this using the bottom_toolbar parameter to prompt, but as far as I can tell the callable specified in bottom_toolbar is not passed the current value. Is it possible to pass the current value entered into the prompt to some sort of callback that can update the screen?

When running a prompt-toolkit Dialog it will flicker if there is terminal output from a different asyncio task.

I am using the context with patch_stdout() within a task as mentioned in the doc, at least as far as I understand it. I read somewhere that starting with prompt-toolkit 3.0 it uses the default asyncio event loop and does not create one itself.

And since asyncio.run always creates a new event loop and closes it at the end and the context manager is within that, I have no clue what could be the reason for the flickering. What am I missing?

(Python 3.9, prompt-toolkit 3.0.36)

This is a MCVE:

import asyncio
from prompt_toolkit.patch_stdout import patch_stdout
from prompt_toolkit.shortcuts.dialogs import _create_app, _return_none
from prompt_toolkit.widgets import Button, Dialog, Label

dialog_align = Dialog(
    title='Please align',
    body=Label(text="init", dont_extend_height=True),
    buttons=[Button(text='Start measurement', width=21, handler=_return_none)],
    with_background=True,
)

async def prompt_align():

    return await _create_app(dialog_align, style=None).run_async()


async def main_datasource():

    while True:
        await asyncio.sleep(0.5)
        print("test")


async def main():

    with patch_stdout():

        task1 = asyncio.create_task(prompt_align())
        task2 = asyncio.create_task(main_datasource())

        await asyncio.gather(task1, task2)


if __name__ == "__main__":

    try:
        from asyncio import run
    except ImportError:
        asyncio.run_until_complete(main())
    else:
        
        asyncio.run(main())

DeprecationWarning: currentThread() is deprecated, use current_thread() instead

No change in functionality, just noticed the warning while testing a third-party package.