Prompt toolkit seem to be the default.
Could we add a flag to restore using classical readline-one ? Potentially simpler than calling the class directly with Python -m whatever.
I thought about doing it, but my plan is to get rid of the readline based interface soon - that was a big part of the rationale for adopting prompt toolkit. I don't want to support both interfaces in a release, so any flag would only be in the development version, and I'm not sure it's worth it. It's a one line change in ipapp to use the old TerminalInteractiveShell class for now.
Is this prompted by a problem in the new interface? The idea of landing it is to discover and fix any problems, so I don't want to make it too easy to switch back.
Is this prompted by a problem in the new interface? The idea of landing it is to discover and fix any problems, so I don't want to make it too easy to switch back.
No, just rebasing my current work on Pygments. I can likely do it without that, But I'll have to understand how prompt toolkit work. Also the Prompt toolkit interface does not seem to support LightBG and Linux Color (which map terminal theming by using short ansi sequence) which is super painful as current theme hurt my eyes. And without this feature I would likely not want to use the prompt toolkit interface.
You can select a pygments theme directly with the highlighting_style config option. Run list(pygments.styles.get_all_styles()) to see the options.
I tried to make the default theme visible on both light and dark terminals (there's no way to detect which we're on). I tested it on both backgrounds on my machines, but it's probably going to look a bit different in different terminal emulators. Obviously we can do further tweaking, but we need to test in both: we can't just optimise for one background and make it illegible in the other.
I also know that the compromises to make it work in both don't make it great in either, which is why I made sure it's easy to select other themes.
No I don't want Pygments Styles, they hardcode extended escape sequences to RGB values (\x01b[38;2;r;g;b;m.) explicitly.
While our theming emits \x01b[30 to \x01b[37 which can be mapped:
This is not (yet) possible with Prompt-toolkit, unless you use Pygments master and Prompt_toolkit master of next week.
Right now locally with all of dev version I can use a custom style like:
class LightBG(Style):
styles = {
Token.Prompt: '#ansiblue',
}
Which works, but that's painful.
And also the theme should not be unicode, we should allow a dotted object name.
These are exactly the reasons my my other Pygments PR took so long, to get around this limitation.
If we're going to be adopting pygments throughout, I don't want to define our own styling system, we should just use what's in pygments. If you're improving that, so much the better.
You can define extra named pygments styles using entry points, and you can also add your own mapping of overrides in the config file, so I don't think we need to deal with object names for styles as well. There's plenty of flexibility already.
Activity
takluyver commented on Feb 22, 2016
I thought about doing it, but my plan is to get rid of the readline based interface soon - that was a big part of the rationale for adopting prompt toolkit. I don't want to support both interfaces in a release, so any flag would only be in the development version, and I'm not sure it's worth it. It's a one line change in ipapp to use the old TerminalInteractiveShell class for now.
Is this prompted by a problem in the new interface? The idea of landing it is to discover and fix any problems, so I don't want to make it too easy to switch back.
Carreau commented on Feb 22, 2016
No, just rebasing my current work on Pygments. I can likely do it without that, But I'll have to understand how prompt toolkit work. Also the Prompt toolkit interface does not seem to support LightBG and Linux Color (which map terminal theming by using short ansi sequence) which is super painful as current theme hurt my eyes. And without this feature I would likely not want to use the prompt toolkit interface.
takluyver commented on Feb 22, 2016
You can select a pygments theme directly with the highlighting_style config option. Run list(pygments.styles.get_all_styles()) to see the options.
I tried to make the default theme visible on both light and dark terminals (there's no way to detect which we're on). I tested it on both backgrounds on my machines, but it's probably going to look a bit different in different terminal emulators. Obviously we can do further tweaking, but we need to test in both: we can't just optimise for one background and make it illegible in the other.
I also know that the compromises to make it work in both don't make it great in either, which is why I made sure it's easy to select other themes.
Carreau commented on Feb 22, 2016
No I don't want Pygments Styles, they hardcode extended escape sequences to RGB values (\x01b[38;2;r;g;b;m.) explicitly.
While our theming emits \x01b[30 to \x01b[37 which can be mapped:
This is not (yet) possible with Prompt-toolkit, unless you use Pygments master and Prompt_toolkit master of next week.
Right now locally with all of dev version I can use a custom style like:
class LightBG(Style): styles = { Token.Prompt: '#ansiblue', }Which works, but that's painful.
And also the theme should not be unicode, we should allow a dotted object name.
These are exactly the reasons my my other Pygments PR took so long, to get around this limitation.
takluyver commented on Feb 23, 2016
If we're going to be adopting pygments throughout, I don't want to define our own styling system, we should just use what's in pygments. If you're improving that, so much the better.
You can define extra named pygments styles using entry points, and you can also add your own mapping of overrides in the config file, so I don't think we need to deal with object names for styles as well. There's plenty of flexibility already.
Carreau commented on Feb 7, 2017
Closing as this has been about a year and we did not had push on this.