[issue694339] IDLE: Dedenting with Shift+Tab

[Tal Einat]

Change by Tal Einat :


--
nosy:  -taleinat

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Cheryl Sabella]

Changes by Cheryl Sabella :


--
nosy: +csabella

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Terry J. Reedy]

Terry J. Reedy added the comment:

<> is a predefined virtual event. 
https://www.tcl.tk/man/tcl8.6/TkCmd/event.htm
I can't find <> listed there. I don't remember if I actually saw it 
before mentioning it.  While I like mimicking smart_indent, I don't know if we 
can dismiss Roger Serwy's concern in msg150059.

Tk on Ubuntu may report key name ISO_Left_Tab msg150059, but it is not 
cross-platform.  On Win 10 with either tk 8.5.15 (2.7) or 8.6.6 (3.6):
  _tkinter.TclError: bad event type or keysym "ISO_Left_Tab"
I don't think we need to use the only sometimes valid synonym.

As Sean Wolfe reported msg212906, Shift-Tab already dedents a single line by 
treating it as a region.  This issue is about removing the extra behavior we 
don't want, and blocking Control-[ from doing simplefied non-region single line 
dedents.  Smart_indent does this by intercepting Tab (which I believe need not 
be bound to <>.

When there is a selection within a line, smart_indent does not call 
dedent_region but deletes the selection and insert \t or spaces, but in the 
latter case, the cursor may not be left on a multiple of indent spaces.  This 
does not seem very useful. It is even less so because if the selection is 
within a word, tab invokes autocomplete instead of smart_indent.  This needs 
discussion on another issue.
---

Text editing tests: how to we do them both thoroughly and efficiently (in terms 
of both human writing and machine execution time)?

White box approach: Set up a class test fixture that defines cls.text = 
; put text in known state (content, cursor position, 
selection); call edit function (smart_indent, proposed smart dedent, etc); 
check resulting state (content, cursor, selection.  Repeat for multiple input 
state - output state pairs.  These tests break if the function name is changed 
and only test the function, which is, however, the main thing to be tested. 

Gray-box approach: Replace function calls with pseudoevents generated on the 
text widget.  Such tests would survive function name changes, break on 
pseudoevent name changes, and add a test of pseudoevent -- function binding. A 
black-box approach replaces pseudoevents with concrete events -- simulated key 
presses, mouse clicks, and menu selections.  These tests survive pseudoevent 
name changes and add a test of concrete -- pseudo event linkage.  They should 
only break if we change the user visible interface, which we seldom do. 

I think we should use all approaches in two sets of tests.  The first set would 
test multiple before and after states in subtests with a function call.  This 
would define and test the intended behavior of the function.  The second set 
would test one before and after state successively with a function call, 
pseudoevent generation, and concrete event generations, in this order.  (If the 
function call fails, the event tests are bound to fail.)  This would test the 
user interface and the links to the underlying function.

There are over 30 editing functions to test, and writing the above for all 
would be tedious.  After writing tests for a couple, we should write helper 
functions that embody the repetitive boilerplate.

An additional factor: The text edit functions, properly bound with a 
pseudoevent to the text instance, are not methods of the text instance (though 
they should be), but of the EditorWindow that also contains a Toplevel; Menu 
hierarchy; and a Frame that contains Scrollbars and a StatusBar, along with, 
finally, the MultiCall(Text) instance.  So the fixture setup must also provide 
provide an attribute for the method container.  Let us call it cls.widget.

In order to put EditFrames (a new subclass of Frame) on tabs, the Text methods 
will have to at least be transferred to the EditFrame.  It would be even better 
to transfer them to an IdleText subclass of MultiCall(Text) or possibly of 
Text.  (See Mark Roseman's suggestion of a MultiCall alternative in msg272070.) 
 After the setup code is changed to assign the new method container to 
cls.widget, the test methods should still run as they are.

--
assignee:  -> terry.reedy
priority: low -> normal
stage: patch review -> test needed
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5, Python 3.7

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Louie Lu]

Louie Lu added the comment:

PR 2210 add the smart-dedent to shift-tab in Windows, macOS, Linux.

I can't saw <> nor <> in 3.7 (master) source code, so 
I'll take it as removed in IDLE somewhere else.

--
nosy: +louielu
versions: +Python 3.7

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +2254

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[irdb]

Changes by irdb :


--
nosy: +irdb

___
Python tracker 

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Tal Einat]

Tal Einat added the comment:

Regarding Roger Serwy's comment, we could either:

1) normalize the event descriptions using MultiCall's _parse_sequence() and 
_triplet_to_sequence() functions
2) remove any Shift-Tab bindings from PrevWindow

I suggest #2.


Regarding the patch itself:

1) Was the existing default binding of Ctrl-[ removed on purpose in 
Lib/idlelib/configHandler.py? According to the same patch, in the config files 
it is still there along-side the new Shift-Tab binding. At the least, these 
should be consistent.

2) In the code re-binding the Prev-Window event in EditorWindow.py, 
shouldn't there be a break at the end of the if clause inside the for 
loop?

--
nosy: +taleinat

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Terry J. Reedy]

Terry J. Reedy added the comment:

The fact that Tab indents regions as well as lines seems not be documented. 
This should be added to Automatic Indentation (which should just be 
Indentation) with BackTab doc addition if not sooner.

On Windows, 3.4.1, shift-tab is the same as tab. The same is true in Notepad 
(not a model to follow), but Notepad++ dedents. Doing the same in Idle, within 
the editor, seems like a reasonable request.

The unplanned and strange OSX behavior should be fixed.

From the patch, I would gather that the problem is that tk hard-codes 
shift-Tab to prev-window (and, I would expect, tab to next-window). 
(This works but is currently useless in the dialogs.) If that is so, why do 
they currently act the same (for me) in the editor? Does tk automatically 
rebind Tab to indent-region in a text widget?

Tal: option 2 seems like something to try. If Shift-Tab is user configurable 
(and I think baked-in like Tab would be ok), then it should be *added* in both 
places. You might be right about break, except this is a moot point if the code 
is wrong.

--
assignee: kbk - 
versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.2

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Sean Wolfe]

Sean Wolfe added the comment:

I did a couple tests and the shift-tab and tab work pretty much as expected. 
There's a small quirk for a single-line edit:

* place cursor on beginning of line
* tab forward
-- the text indents as expected
* shift-tab
-- the entire line is highlighted
-- the cursor now appears beneath the line
-- subsequent typing however affects the highlighted line

For the single-line case, it would be cleaner to have it stay on the same line 
without highlighting.

This is OSX 10.9, python 2.7.6+ and 3.4.rc1+

--
nosy: +Sean.Wolfe

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Terry J. Reedy]

Changes by Terry J. Reedy tjre...@udel.edu:


--
nosy: +terry.reedy

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

[issue694339] IDLE: Dedenting with Shift+Tab

[Todd Rovito]

Changes by Todd Rovito rovit...@gmail.com:


--
nosy: +Todd.Rovito

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue694339
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue694339] IDLE: Dedenting with Shift+Tab

[Roger Serwy]

Roger Serwy roger.se...@gmail.com added the comment:

I applied the patch and encountered a problem. MultiCall.py is replacing 
Shift-Key-Tab with Shift-KeyPress-Tab. When this happens, the logic for 
rebinding PrevWindow fails.

event_info('PrevWindow') returns ('Key-ISO_Left_Tab', 'Key-hpBackTab', 
'Shift-Key-Tab') 

event_info('dedent-region') returns ('Control-KeyPress-bracketleft', 
'Shift-KeyPress-Tab')

This is with 3.3a0 on Ubuntu 11.04.

--
nosy: +serwy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue694339
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue694339] IDLE: Dedenting with Shift+Tab

[Terry J. Reedy]

Changes by Terry J. Reedy tjre...@udel.edu:


--
stage:  - patch review
title: Dedenting with Shift+Tab - IDLE: Dedenting with Shift+Tab
versions: +Python 3.2 -Python 2.7, Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue694339
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com