| msg77921 - (view) |
Author: (Somelauw) |
Date: 2008-12-16 19:43 |
| I'm using python 3.0 final which was released on December the 3th. I also have python 2.5 installed. 2 bugs in python3 IDLE which might be related (but don't have to) 1. The Python3 IDLE sometimes suddenly closes. It always happens when I'm using it for a while, then press the shift + home or end key and then it just disappears and my unsaved work is lost. It really completely exits without an error and I also don't see it on the background. I'm unable to reproduce the error. But it usually happens when I have hold down shift and press the home key. 2. When I have some code then scroll down the code, then hold down shift and press up a few times, then press home the selected code completely switches. Instead some code above the cursor suddenly gets selected. The reason I think both are related is because both involve shift + home key. Both of the bugs have never happened in the IDLE 1.2.1 which was part of python 2.5.2 I think |
|
|
| msg79078 - (view) |
Author: (Somelauw) |
Date: 2009-01-04 19:17 |
| I have found a way to reproduce this error: \\\\ Open the idle Hold down shift: Press up 3 times Hold [fn] (on laptop) Press the home key Idle closes for no reason //// Any help? |
|
|
| msg79085 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-01-04 21:10 |
| I can't reproduce this with py3k on linux, but I do get a traceback in the terminal used to launch idle: Exception in Tkinter callback Traceback (most recent call last): File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 1399, in __call__ return self.func(*args) File "/home/ajaksu/py3k/Lib/idlelib/MultiCall.py", line 165, in handler r = l[i](event) File "/home/ajaksu/py3k/Lib/idlelib/EditorWindow.py", line 315, in home_callback if self.text.compare(first,">",last): File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 2844, in compare self._w, 'compare', index1, op, index2)) _tkinter.TclError: expected boolean value but got "" That only happens sometimes happens, pressing home while holding shift down does nothing but print the traceback. Else, pressing 'home' holding shift alternates: start of line, start of indented block. |
|
|
| msg79145 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2009-01-05 13:50 |
| Somelauw: Are you running Windows, Linux, other? The bug may be related to a special key with no binding: no mapping in the kernel, in your Windows/Xorg configuration or in python Tk module. The key is maybe not shift+home but strange combinaison related to your laptop special keys. |
|
|
| msg79153 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-05 14:58 |
| It would be nice if the OP could confirm that the bug described by Daniel is the same one as he gets. I can reproduce it on linux on all the versions I marked, but didn't have time to fix it yet. To the OP: If you are running Windows, try starting IDLE on the prompt, reproduce the error, and check if anything is printed back to you. |
|
|
| msg79157 - (view) |
Author: (Somelauw) |
Date: 2009-01-05 15:31 |
| I'm using windows XP home edition SP2 Yes, my error message is similair to the one of ajaksu2 when I run the IDLE on the commandline. (when opened from windows explorer, it justs closes) Also problem 2 is similair. |
|
|
| msg79195 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-05 20:02 |
| Patch against trunk attached. It fixes only the first problem reported, and I can't reproduce the second one. |
|
|
| msg80473 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-24 19:17 |
| I have experienced similar problems in Python 2.6.1 on Windows, and found them to be due to Tk 8.5. I posted my findings here: http://mail.python.org/pipermail/idle-dev/2009-January/002738.html In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to each Text widget. The code to make the home key toggle between column 0 and the start of the text tries to make use of the "anchor" mark and gets confused. In the email I proposed a simple fix which I'm testing out right now. Should I attach it as a patch? |
|
|
| msg80478 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-24 20:49 |
| Another complication. On Windows, this line doesn't do what it claims: if (event.state & 12) != 0 and event.keysym == "Home": # state&1==shift, state&4==control, state&8==alt return # ; fall back to class binding The comment says state&8==alt, but this is wrong. state&8==mod1, and on Windows Tk defines mod1 to be num-lock. So if you have num-lock on, home_callback will always fall back to the standard binding. See the Tk source: xlib/X11/X.h defines Mod1Mask win/tkWinX.c maps VK_NUMLOCK to Mod1Mask |
|
|
| msg80568 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-26 11:29 |
| Just got a chance to test this on a Windows desktop with a proper keyboard. (My laptop does weird things with num-lock and scroll-lock.) I got it to crash once, but I have no idea what was special about that time. Otherwise I can reproduce the exception traceback printed to the console, with the following steps: 1) Start IDLE from the console, e.g.: python c:\python26\Lib\idlelib\idle.py 2) Make sure num-lock is turned OFF. 3) Enter a few characters, e.g: rhubarb 4) Press shift+left to create a selection of at least one character. 5) Press shift+home. The stack trace appears in the console: Exception in Tkinter callback Traceback (most recent call last): File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__ return self.func(*args) File "C:\Python26\lib\idlelib\MultiCall.py", line 150, in handler r = l[i](event) File "C:\Python26\lib\idlelib\EditorWindow.py", line 333, in home_callback if self.text.compare(first,">",last): File "C:\Python26\lib\lib-tk\Tkinter.py", line 2858, in compare self._w, 'compare', index1, op, index2)) TclError: expected boolean value but got "" This is consistent with my understanding that Tk 8.5 does not use a mark named "anchor" to indicate the selection anchor. I have written a patch that directly calls "tk::TextKeySelect" instead of trying to duplicate its behaviour using the "anchor" mark. I'm not terribly confident with using diff and patch, so please let me know if I've done it wrong. I did use -u. |
|
|
| msg80742 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-29 02:55 |
| > Weeble added the comment: > > In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to > each Text widget. The code to make the home key toggle between column 0 > and the start of the text tries to make use of the "anchor" mark and > gets confused. > > In the email I proposed a simple fix which I'm testing out right now. > Should I attach it as a patch? > I see your simple fix depends on a unsupported proc provided by tk, how good is to depend on it ? And I don't think that is backwards compatible till tk 8.2, is it ? |
|
|
| msg80749 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-29 08:47 |
| Well, the status quo depends on an unsupported field - "anchor". As far as I can tell, the only other option that allows any customisation of cursor behaviour is to re-implement the entire selection system from the ground up. Would it be acceptable to detect the Tk version and change strategy accordingly? I don't know how far back this would work: I've tested it with Tk 8.5 and 8.4. I'll ask on comp.lang.tcl and see what they recommend fpr customising the behaviour of a text widget. Thanks for looking over this. |
|
|
| msg80750 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-29 09:06 |
| I posted a question on comp.lang.tcl here: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/aab17806f6fa837f# By the way, which versions of Tk must Python support? Where do I find out things like that? |
|
|
| msg80758 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-29 11:50 |
| > Weeble added the comment: > > Well, the status quo depends on an unsupported field - "anchor". Better not repeat the mistake then ? > As far > as I can tell, the only other option that allows any customisation of > cursor behaviour is to re-implement the entire selection system from the > ground up. Would it be acceptable to detect the Tk version and change > strategy accordingly? > IDLE already reimplements several things, which were useful back then when it wasn't reimplementing -- just adding functionality. If the only correct solution is really to reimplement the selection, then it would be better to do it anyway, but I don't think it is. I'm interested in knowing how many interactive shells implement this same behaviour, or if there are that many I would like at least some examples. I'm unsure about the usefulness of the current functionality (supposing it was working as intended). > I don't know how far back this would work: I've tested it with Tk 8.5 > and 8.4. > All versions of 8.4 ? I've seen complaints about early releases of tk 8.4 and the use of the unsupported function. |
|
|
| msg80764 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-29 13:56 |
| You're right: we should find a solution that's safe and supported. I *think* the primary reason for overriding the home key behaviour was not for the interactive shell, but to make it easier to edit code. Most programmer's editors that do automatic indentation also let you use home to move to the beginning of the text on a line, rather than the absolute beginning of the line. I couldn't say for sure though: I'm new here. I've proposed some changes to the ctrl-left, ctrl-right behaviour on idle-dev that would also require custom handling of selection behaviour. If it were to be decided that reimplementing the selection-handling was worthwhile I would be willing to work on such a patch to redo the selection-handling using only supported Tk features, but I get the impression I'd need lots of help to get it tested with every possible version of Tcl/Tk. |
|
|
| msg80766 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-29 14:49 |
| > Weeble added the comment: > > I *think* the primary reason for overriding the home key behaviour was > not for the interactive shell, but to make it easier to edit code. Most > programmer's editors that do automatic indentation also let you use home > to move to the beginning of the text on a line, rather than the absolute > beginning of the line. > Yes, but IDLE goes beyond that and adds some weird behaviour. Suppose you have this line in IDLE: >>> xxxx Why would you want to go at the absolute beginning there ? That is what happens when you press home twice. Then there is the other case, the reason for the current home code: y, ... Pressing home twice while on the second line toggles between the absolute start of that line and one position before y, this is the behaviour that I haven't seen used anywhere else (but it is not like I have used many GUI shells). If it is used everywhere else I haven't looked at then this might be good because people are accustomed to, otherwise it is just a feature that IDLE has for no reason. > I've proposed some changes to the ctrl-left, ctrl-right behaviour on > idle-dev that would also require custom handling of selection behaviour. I'm subscribed to idle-dev but I assume I don't read it at all. > If it were to be decided that reimplementing the selection-handling was > worthwhile I would be willing to work on such a patch to redo the > selection-handling using only supported Tk features, but I get the > impression I'd need lots of help to get it tested with every possible > version of Tcl/Tk. > Before start writing new code I suggest to check how many IDLE forks exist, and check if any of them has this fixed. It would be good to start writing tests for idlelib too. Testing with every possible version of Tcl/Tk is not going to work, the minimal possible is 8.2 as it is what _tkinter supports. But I suspect most people are using tk 8.4 (and then there are a lot of minor releases), some tk 8.5 and very few using other versions. The externally maintained tk versions are 8.4.12, 8.4.16, 8.4.18.1 and 8.5.2.0 so we could target these versions. |
|
|
| msg80768 - (view) |
Author: Weeble (weeble) |
Date: 2009-01-29 15:01 |
| I can't see any useful reason to go to the absolute start of the line in the interactive shell. However, it does make sense in the source editor, and it is consistent with, for example, Visual Studio. The first use- case off the top of my head is when you want to copy a block of code and not lose the relative indentation of the first line. You press home- twice to go to the absolute start of line and select from there. It's also the only quick way in IDLE to be sure that the text widget is scrolled all the way to the left, since there's no horizontal scrollbar. (Any idea why that is? I assumed it's to discourage long lines, but I don't know.) The proposal I refer to in IDLE-dev is this: http://mail.python.org/pipermail/idle-dev/2009-January/002742.html I only mention it because it demonstrates another reason why we might want to override the default selection/navigation mechanics. |
|
|
| msg80769 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-01-29 15:21 |
| > It's > also the only quick way in IDLE to be sure that the text widget is > scrolled all the way to the left, since there's no horizontal scrollbar. > (Any idea why that is? I assumed it's to discourage long lines, but I > don't know.) The shell is configured to wrap lines if they get too long, but you will notice that pressing 'end' doesn't really get you to the end of line. It should be easier to not wrap there too and add a horizontal scrollbar (if needed) to all text widgets used by idle. |
|
|
| msg85377 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2009-04-04 06:56 |
| Thanks for the research on the home key toggle. Let's take that to , it seems it's different from the rest of this issue. |
|
|
| msg128252 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-02-10 00:26 |
| Can this bug be closed? |
|
|
| msg132193 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2011-03-26 00:35 |
| New changeset c4d355363114 by Kurt B. Kaiser in branch '3.1': toggle failing on Tk 8.5, causing IDLE exits. Issue #4676 http://hg.python.org/cpython/rev/c4d355363114 |
|
|
| msg132204 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2011-03-26 01:35 |
| Fixed in 2.7 and forward ported. |
|
|