[issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r

[Tal Einat]

Tal Einat  added the comment:

Note that most of the issues with special characters described in Terry latest 
comment have been addressed by the fix for issue13153.

Can we continue discussing just properly rendering \r and \b, e.g. as done in 
PR GH-15211? Let's just decide whether we want this or not.

My main point in favor is that we already have special support for two similar 
control characters, \n and \t. IMO we should expand this to the other very 
standardized ones, \r and \b, and perhaps \a ("bell") as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r

[Tal Einat]

Tal Einat  added the comment:

Terry, thanks for the detailed writing of your thoughts on the matter and their 
context.

Serhiy's argument (in msg246602) is that different terminals interpret 
different control characters in different ways, and that we have no way of 
unifying their behavior.  This is true, and I will add that we should also not 
aim to fully emulate any single terminal nor multiple types of terminals.

On the other hand, there is a common ground where the vast majority of 
terminals do, in fact, behave very similarly WRT control characters.  For 
example, IDLE already does interpret '\n' in a special way (partially because 
the underlying Tk text widget does).  The same goes for '\t'.

I argue that we should instead *slightly* expand the set of control characters 
which IDLE interprets, to include a few more which are universally treated in a 
consistent manner.

Looking at the list of ASCII control characters on Wikipedia[1], I don't think 
any beyond \a, \b, \n, \r and \t are universal enough and in common enough use 
to merit inclusion.  (For reference, \a is for "bell".)

..[1]: https://en.wikipedia.org/wiki/C0_and_C1_control_codes


I find the suggestion to have more than a single "mode" for the IDLE shell 
contrary to the "simple and novice friendly" design principle that we are 
aiming for.  I also think that it would bring little added benefit to the great 
majority of our users.


As for other control characters and astral characters, I very much agree that 
we could do better than to have them often "garbled" as done by the Tk text 
widget.  I think this should be dealt with as a separate issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In this post, I slightly expand the terminal mode proposal and define the 
context in which I will accept it.  The context will be the subject of other 
issues.  In the next post (tomorrow) I will try to define a reviewable 
specification for the terminal mode.
---

The proposal that IDLE's should *always* respond to \b and \r "properly
, like terminals" is the combined proposal of #24572 and the original proposal 
of #23220.  The combined proposal was rejected in the latter,  for reasons best 
given by Serhiy in msg246602.  More is given below. #23220 was then redefined 
as a doc issue.

I noted in #23220 that one solution for people who wanted terminal-like 
behavior would be to add an option to execute code being edited to the system 
terminal.  However, this a) throws away the benefits of running in Shell and b) 
would not apply to interactive exploration.  While running in a terminal is 
needed for certain use cases, it is not needed  for handling control of line 
output.

What Shell should do with control characters in output depends on the users 
goal.  I propose that Shell should have 3 display modes that treat ascii 
control codes differently for different use cases.

1) Raw mode (the current mode). IDLE inserts all BMP chars into the tk Text.  
This is needed if one is using a font that has glyphs associated with control 
codes.  On Windows 10, the 8514oem font (the MSDOS font) has symbols for all 
control codes except NUL and newline.  This is a rare need; this mode should 
not be the default.

2) Development mode (my proposed new default).  To the extent possible, 
developers should be able to see the characters their program produces without 
adding repr() to all their print and write statements (and later deleting 
them).  Control chars would be replaced with unique glyphs, such as 'Control 
Pictures', \u2400-\u241f,
  ␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈␉␊␋␌␍␎␏␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␞ ␟.
or maybe circled letters, \u24d0-\u24df,\u24b6-\u24c5, ⓐ-ⓟ, Ⓐ-Ⓟ.  Replacements 
would be tagged as such and get distinct highlight colors. The purpose of a 
visible tag is to differentiate replacements from characters actually output by 
the users program.

To fulfill the goal of Development mode, more is needed. Astral chars, instead 
of causing an exception, should be replaced by a string consisting of their \U 
escape and tagged as a replacement.  This is needed anywhere astral chars can 
appear.  It would also be nice to get the codepoint and name of any displayed 
character. If implemented, this should be added to the base editor class.

3) Terminal mode. Tk interprets \n and \t.  Also interpret (to begin with) \a, 
\b, and \r.  The motivation for the latter two has already been given. As said 
above, the specification is deferred to another post.

--
title: IDLE: Have the shell mimic terminal handling of \r and \b control 
characters in outputs -> IDLE Shell: add a terminal mode that responds to \a, 
\b, and \r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com