-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-37692: Improve highlight config sample #14983
Conversation
I intend to merge this tomorrow (Sunday). Any comments before that? I am pretty happy with the simulated shell session. I tried putting the cursor blob where the blank line above the prompt is, but that blank is. I will try putting it up under code context, as it has no particular assoication with Shell. As for the label changes. My special concern is with beginners. 'Normal Text' is mainly used for code unless one is editing a text file, so 'Normal Code of Text'. 'Shell Normal Text', is technically correct (and confusing), since it is used for normal output from Shell itself (but not, now, for Restart lines). But what is that? The prompt. And '[DEBUG ONOFF]', which beginners will likely not have seen. So 'Shell Prompt' seems better. 'Shell Error Text' is wrong in that it is mainly (exclusively?) used to mark syntax error locations in both shell and editor. So just 'Error Text' is better. 'Shell Stdout Text' is not the stdout of Shell. It is used for text the users send to stdout, usually by print, usually by default, usually in a separate process which gets displayed in Shell. Beginners might not even be familiar with 'stdout' (and 'stderr') 'Shell User Output' seems better even if not the best possible. In any case, the output that clearly results from user input should make its meaning clear. The case with 'Shell Stderr Text' is similar. |
@terryjreedy, I trust your judgement, and this looks alright. My only minor note is that typing |
Thanks @terryjreedy for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7, 3.8. |
@terryjreedy: Please replace |
I'm having trouble backporting to |
GH-14990 is a backport of this pull request to the 3.7 branch. |
Use an example shell interaction in the sample and better labels for shell elements. (cherry picked from commit b222955) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Thanks @terryjreedy for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8. |
GH-14991 is a backport of this pull request to the 3.8 branch. |
Use an example shell interaction in the sample and better labels for shell elements. (cherry picked from commit b222955) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
@Mariatta I routinely backport to 3.8 and 3.7 and the 3.8 backport routinely fails on the first try, and succeeds on the second. There clearly is some problem with doing two backports in the same invocation. Sometimes the failure is almost immediate (the last two times before this), sometime delayed after the timeout. |
Tal, obviously real code with a simulated accidental space syntax error looks better. |
Use an example shell interaction in the sample and better labels for shell elements.
Use an example shell interaction in the sample and better labels for shell elements.
Use an example shell interaction in the sample and better labels for shell elements.
Use an example shell interaction in the sample and better labels for shell elements.
https://bugs.python.org/issue37692