Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74881 > unrolled thread

PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!

Back to article view | Back to comp.lang.python

Contents

  PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 14:14 -0700
    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-20 22:36 +0100
    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2014-07-20 23:40 +0200
      Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 15:44 -0700
        Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 11:02 +1000
          Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 19:06 -0700
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Tim Chase <python.list@tim.thechases.com> - 2014-07-20 21:30 -0500
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 12:38 +1000
              Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 14:27 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Shiyao Ma <i@introo.me> - 2014-07-21 22:40 +0800
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:51 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:57 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 00:48 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 00:51 +1000
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:55 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 03:56 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Monte Milanuk <memilanuk@invalid.com> - 2014-07-21 14:55 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-21 16:19 +0100
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Grant Edwards <invalid@invalid.invalid> - 2014-07-21 16:56 +0000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 01:27 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Lele Gaifax <lele@metapensiero.it> - 2014-07-21 17:57 +0200
                  Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-21 17:03 +0000
                    Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Lele Gaifax <lele@metapensiero.it> - 2014-07-21 19:40 +0200
                    Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-18 20:49 +0200
                      Re: Adapt bash readline operate-and-get-next Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-19 10:17 +1000
                        Re: Adapt bash readline operate-and-get-next Chris Angelico <rosuav@gmail.com> - 2014-08-19 10:32 +1000
                        Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 10:49 +0200
                        Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 11:51 +0200
                    Re: Adapt bash readline operate-and-get-next Skip Montanaro <skip@pobox.com> - 2014-08-18 14:06 -0500
                    Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 10:44 +0200
                    Re: Adapt bash readline operate-and-get-next Skip Montanaro <skip@pobox.com> - 2014-08-19 07:45 -0500
                    Re: Adapt bash readline operate-and-get-next Lele Gaifax <lele@metapensiero.it> - 2014-08-19 15:10 +0200
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-22 02:05 +1000
                Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Terry Reedy <tjreedy@udel.edu> - 2014-07-21 15:16 -0400
              RE: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! "Coll-Barth, Michael" <Michael.Coll-Barth@VerizonWireless.com> - 2014-07-21 10:51 -0400
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-21 03:45 +0100
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Terry Reedy <tjreedy@udel.edu> - 2014-07-20 23:05 -0400
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Chris Angelico <rosuav@gmail.com> - 2014-07-21 13:09 +1000
            Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"! Martin S <shieldfire@gmail.com> - 2014-07-21 09:51 +0200
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Tim Chase <python.list@tim.thechases.com> - 2014-07-20 19:56 -0500
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Chris Angelico <rosuav@gmail.com> - 2014-07-21 11:04 +1000
      Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!) Tim Chase <tim@thechases.com> - 2014-07-20 19:55 -0500
    Idle open file dialogs (was ...) Terry Reedy <tjreedy@udel.edu> - 2014-07-20 22:59 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#74924

Chris Angelico <rosuav@gmail.com> writes:

> Take, for instance, the behaviour of Windows's cmd.exe
> editing keys: enter three commands, then up-arrow three times and hit
> enter, then press down, enter, down, enter. You'll repeat the three
> commands. In other interfaces (eg GNU readline), you'd do the same job
> by pressing up, up, up, enter each time. Personally, I find the
> cmd.exe behaviour extremely surprising, especially when I've been
> working with some very similar commands (imagine: ./configure
> some_bunch_of_args; make; some_command_to_test; rm -rf *; git checkout
> HEAD - then repeat with a different set of configure arguments), and I
> end up "stuck half way up command history", wondering why I'm not
> seeing what I wanted. Can be extremely awkward. But even so, I don't
> call this a bug.

Granted, the readline library exposes a "operate-and-get-next" function,
by default bound to \C-o, with the same behaviour as the cmd.exe
one. I find it very handy in the scenario you picted. So again,
"feature" and "bug" may be effectively subjective :-)

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#74935

On Mon, 21 Jul 2014 17:57:22 +0200, Lele Gaifax wrote:

> Chris Angelico <rosuav@gmail.com> writes:
> 
>> Take, for instance, the behaviour of Windows's cmd.exe editing keys:
>> enter three commands, then up-arrow three times and hit enter, then
>> press down, enter, down, enter. You'll repeat the three commands. In
>> other interfaces (eg GNU readline), you'd do the same job by pressing
>> up, up, up, enter each time. Personally, I find the cmd.exe behaviour
>> extremely surprising, especially when I've been working with some very
>> similar commands (imagine: ./configure some_bunch_of_args; make;
>> some_command_to_test; rm -rf *; git checkout HEAD - then repeat with a
>> different set of configure arguments), and I end up "stuck half way up
>> command history", wondering why I'm not seeing what I wanted. Can be
>> extremely awkward. But even so, I don't call this a bug.
> 
> Granted, the readline library exposes a "operate-and-get-next" function,
> by default bound to \C-o, with the same behaviour as the cmd.exe one. I
> find it very handy in the scenario you picted. So again, "feature" and
> "bug" may be effectively subjective :-)

Have you actually got that working in Python with the readline module? 
I've tried and tried and cannot get it to work. Any hints gratefully 
appreciated.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#74936

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

>> Granted, the readline library exposes a "operate-and-get-next" function,
>> by default bound to \C-o, with the same behaviour as the cmd.exe one. I
>> find it very handy in the scenario you picted. So again, "feature" and
>> "bug" may be effectively subjective :-)
>
> Have you actually got that working in Python with the readline module? 
> I've tried and tried and cannot get it to work. Any hints gratefully 
> appreciated.

I was pretty sure it worked when I revamped the readline support[1],
many years ago, but effectively I'm not able to do it now, and I find
this

  https://github.com/ipython/ipython/issues/41

where Chet Ramey says it's something that bash injects into the
library... and that it should be easy to implement by the calling
application.

So I guess my memory is faulty.

ciao, lele.

[1] http://ftp.vim.org/languages/python/python/contrib-09-Dec-1999/System/Pyrl.README
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#76502 — Adapt bash readline operate-and-get-next

[Multipart message — attachments visible in raw view] — view raw

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Mon, 21 Jul 2014 17:57:22 +0200, Lele Gaifax wrote:
>> Granted, the readline library exposes a "operate-and-get-next" function,
>> by default bound to \C-o...
>
> Have you actually got that working in Python with the readline module? 
> I've tried and tried and cannot get it to work. Any hints gratefully 
> appreciated.

This is just a first attempt to adapt the Bash code to the Python
readline.c module: I'm very surprised that the half-an-hour I spent on
it, mostly to locate related code, actually full filled the goal :-)

The patch isn't complete, in particular, it does not work on Apple's
libedit, because I have no way to try it on that system. Also, I'm not
fluent with Mercurial, so this is just a "hg diff".

Even if I know this is not the right forum and I should (and I
eventually do, assuming a positive feedback) instead open a ticket and
attach the patch there, I'd like to hear opinions on whether this should
be enabled by default, and possibly get in touch with some Apple
owner...

ciao, lele.

[toc] | [prev] | [next] | [standalone]

#76529 — Re: Adapt bash readline operate-and-get-next

Lele Gaifax wrote:

> This is just a first attempt to adapt the Bash code to the Python
> readline.c module: I'm very surprised that the half-an-hour I spent on
> it, mostly to locate related code, actually full filled the goal :-)

You're my hero!!!

[...]
> Even if I know this is not the right forum and I should (and I
> eventually do, assuming a positive feedback) instead open a ticket and
> attach the patch there, I'd like to hear opinions on whether this should
> be enabled by default, and possibly get in touch with some Apple
> owner...

I would love to see support for this in Python. Unfortunately, I'm not
qualified to review your code. Can you create a feature request for it on
the bug tracker, mark me (steven.daprano) as interested, and upload your
diff? If the patch is accepted, you may be asked to sign a contributor's
agreement. It's not very complicated.

I wouldn't worry about Apple users for the time being. Let's see if we can
get it accepted first.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#76532 — Re: Adapt bash readline operate-and-get-next

On Tue, Aug 19, 2014 at 10:17 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I would love to see support for this in Python. Unfortunately, I'm not
> qualified to review your code. Can you create a feature request for it on
> the bug tracker, mark me (steven.daprano) as interested, and upload your
> diff? If the patch is accepted, you may be asked to sign a contributor's
> agreement. It's not very complicated.

And please mark me (rosuav) as interested ("nosy"), too - I'm curious
to see how this works out.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76548 — Re: Adapt bash readline operate-and-get-next

Chris Angelico <rosuav@gmail.com> writes:

> On Tue, Aug 19, 2014 at 10:17 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>
>> Can you create a feature request for it on the bug tracker, mark me
>> (steven.daprano) as interested, and upload your diff?
>
> And please mark me (rosuav) as interested ("nosy"), too

Sure, will do that ASAP.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#76553 — Re: Adapt bash readline operate-and-get-next

Lele Gaifax <lele@metapensiero.it> writes:

> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Tue, Aug 19, 2014 at 10:17 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>
>>> Can you create a feature request for it on the bug tracker, mark me
>>> (steven.daprano) as interested, and upload your diff?
>>
>> And please mark me (rosuav) as interested ("nosy"), too
>
> Sure, will do that ASAP.

I have created http://bugs.python.org/issue22228, where I attached a
slightly edited version of the patch.

Chris, I wasn't able to add you to the nosy list, because "rosuav"
didn't come up in the lookup, sorry.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#76504 — Re: Adapt bash readline operate-and-get-next

On Mon, Aug 18, 2014 at 1:49 PM, Lele Gaifax <lele@metapensiero.it> wrote:
> Even if I know this is not the right forum and I should (and I
> eventually do, assuming a positive feedback) instead open a ticket and
> attach the patch there, I'd like to hear opinions on whether this should
> be enabled by default, and possibly get in touch with some Apple
> owner...

Looks reasonable to me, at least if I understand the intent correctly.
I've never used this functionality in bash (wasn't aware it existed).
I assume the intention here is to easily re-execute compound
statements pulled from saved history. Does your position in the
history disappear if you operate_and_get_next(), then modify the next
recalled input line? When you are finished with a series of Ctl-O
keystrokes I presume you (as the user) press Ctl-U or Ctl-K to clear
the input buffer?

Skip

[toc] | [prev] | [next] | [standalone]

#76544 — Re: Adapt bash readline operate-and-get-next

Skip Montanaro <skip@pobox.com> writes:

> Looks reasonable to me, at least if I understand the intent correctly.
> I've never used this functionality in bash (wasn't aware it existed).
> I assume the intention here is to easily re-execute compound
> statements pulled from saved history.

Yes, or any arbitrary sequence of statements/expressions.

> Does your position in the history disappear if you
> operate_and_get_next(), then modify the next recalled input line?

Not sure what you mean with "disappear": basically o-a-g-n "accepts" the
current line (that is, "executes" it, and this means it gets pushed at
the top of history), regardless you edited or not, then fetches the
following input line from the history and presents it to you.

Given these lines in the history:

    >>> a=10
    >>> a-=1
    >>> print(a)
    9

Going back twice, to reach the assignment to "a", and then typing ^O
(bound to o-a-g-n by default) repeatedly, you get:

    >>> a-=1
    >>> print(a)
    8
    >>> a-=1
    >>> print(a)
    7
    >>> a-=1
    >>> print(a)
    6
    >>> a-=1
    >>> print(a)
    5
    >>> a-=1[#]

where the "[#]" is the input cursor.

> When you are finished with a series of Ctl-O
> keystrokes I presume you (as the user) press Ctl-U or Ctl-K to clear
> the input buffer?

Yes.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#76560 — Re: Adapt bash readline operate-and-get-next

On Tue, Aug 19, 2014 at 3:44 AM, Lele Gaifax <lele@metapensiero.it> wrote:
>> Does your position in the history disappear if you
>> operate_and_get_next(), then modify the next recalled input line?
>
> Not sure what you mean with "disappear": basically o-a-g-n "accepts" the
> current line (that is, "executes" it, and this means it gets pushed at
> the top of history), regardless you edited or not, then fetches the
> following input line from the history and presents it to you.
>
> Given these lines in the history:
>
>     >>> a=10
>     >>> a-=1
>     >>> print(a)
>     9

Suppose you have the above, as you indicated. Ctl-P your way back to
the a=10 line. Press Ctl-O. It executes that assignment and fills the
input buffer with "a-=1". Instead of just pressing Ctl-O, type a "1"
first, changing the input buffer to "a-=11". *Now* press Ctl-O. I
assume it executes that statement. You've edited the line, however.
Does it present you with the print statement or not?

I guess I could have answered my own question using bash:

firefly% a=10
firefly% a='a'
firefly% echo $a
a
firefly% a=10
firefly% a='b'
firefly% echo $a
b

The second batch of three lines were executed from history with this
key sequence:

Ctl-P Ctl-P Ctl-P Ctl-O DEL DEL b ' Ctl-O RET

That's pretty cool. Even if I never live to see it in Python (I'm
still using 2.7), I will definitely start using it in bash. :-)

Skip

[toc] | [prev] | [next] | [standalone]

#76562 — Re: Adapt bash readline operate-and-get-next

Skip Montanaro <skip@pobox.com> writes:

> On Tue, Aug 19, 2014 at 3:44 AM, Lele Gaifax <lele@metapensiero.it> wrote:
>> Given these lines in the history:
>>
>>     >>> a=10
>>     >>> a-=1
>>     >>> print(a)
>>     9
>
> Suppose you have the above, as you indicated. Ctl-P your way back to
> the a=10 line. Press Ctl-O. It executes that assignment and fills the
> input buffer with "a-=1". Instead of just pressing Ctl-O, type a "1"
> first, changing the input buffer to "a-=11". *Now* press Ctl-O. I
> assume it executes that statement. You've edited the line, however.
> Does it present you with the print statement or not?

Yes, it presents the print statement. Another Ctrl-O will present
"a-=11" again, and so on.

> I guess I could have answered my own question using bash:
>
> firefly% a=10
> firefly% a='a'
> firefly% echo $a
> a
> firefly% a=10
> firefly% a='b'
> firefly% echo $a
> b
>
> The second batch of three lines were executed from history with this
> key sequence:
>
> Ctl-P Ctl-P Ctl-P Ctl-O DEL DEL b ' Ctl-O RET
>
> That's pretty cool. Even if I never live to see it in Python (I'm
> still using 2.7), I will definitely start using it in bash. :-)

Yes, it's very handy indeed!

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#74925

On Tue, Jul 22, 2014 at 1:57 AM, Lele Gaifax <lele@metapensiero.it> wrote:
> Granted, the readline library exposes a "operate-and-get-next" function,
> by default bound to \C-o, with the same behaviour as the cmd.exe
> one. I find it very handy in the scenario you picted. So again,
> "feature" and "bug" may be effectively subjective :-)

I've never used it, but from the name, I would take it to be
equivalent to "enter, down-arrow" in the above scenario. As a single
action, that's less surprising and just as useful. The problem isn't
when you consciously want the feature - it's when you DON'T want it
and get this unexpected state.

ChrisA

[toc] | [prev] | [next] | [standalone]

#74949

On 7/21/2014 10:27 AM, Grant Edwards wrote:
> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
>
>> You call it a bug because you can't think of any way it could be
>> beneficial. That's the wrong way of looking at it. Something isn't a
>> bug because you find it annoying; it's a bug because it fails to
>> implement the programmer's intentions and/or the docs/specification.
>
> I was always taught that it's a "bug" is when a program doesn't do
> what a reasonable user expects -- that it's got nothing to do with the
> programmer's intent.

For the Python issue tracker at bugs.python.org, one definition of a 
behavior ('bug') issue, one that might lead to a patch in maintenance 
releases of current versions, is a discrepancy between doc claim and 
code behavior. Discrepancies can be fixed by changing either doc or code 
to match the other, depending on which is considered to be wrong. Of 
course, sometime the doc is absent, partial, ambiguous, or confusing.

People (such as Rick) proposing enhancements often consider matching 
code and doc to be buggy by design. But this is different type of issue.

For Idle, the doc briefly specifies behavior at a high, user level. File 
/ open should 'open an existing file'. A text box for entry of a path 
would minimally suffice. The current open file dialog adds the option of 
filling in the box by clicking around the directory tree.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#74930

> -----Original Message-----
> From: Python-list [mailto:python-list-bounces+michael.coll-
> barth=verizonwireless.com@python.org] On Behalf Of Grant Edwards
> Sent: Monday, July 21, 2014 10:27 AM
> To: python-list@python.org
> Subject: Re: PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!
> 
> On 2014-07-21, Chris Angelico <rosuav@gmail.com> wrote:
> 
> > You call it a bug because you can't think of any way it could be
> > beneficial. That's the wrong way of looking at it. Something isn't a
> > bug because you find it annoying; it's a bug because it fails to
> > implement the programmer's intentions and/or the docs/specification.
> 
> I was always taught that it's a "bug" is when a program doesn't do
> what a reasonable user expects -- that it's got nothing to do with the
> programmer's intent.
> 
> --

I have to agree with Chris.  A bug is what you call something that happens contrary to design or intent.  Only.  I build a program, regardless of the platform, with my intent, not yours.  When it blows up or doesn't do what I want, then it's a bug and it's a bug even if there are no users for my program.

Something that happens contrary to user expectations is an annoyance to that user.  You might want to get your money back from those that taught you otherwise.

BTW, there ain't no such thing as a 'reasonable' user.  That's what they call an oxymoron. 

[toc] | [prev] | [next] | [standalone]

#74897

[snipped to bits]

On 21/07/2014 03:38, Chris Angelico wrote:
> On Mon, Jul 21, 2014 at 12:06 PM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>>   STEPS TO REPRODUCE BUG 1: "Attack of the clones!"
>
> This is not an Idle bug at all. It's a window manager issue.
>
> ChrisA
>

Attack of the clown?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#74899

On 7/20/2014 10:38 PM, Chris Angelico wrote:

> on Windows. The file dialog appears in the alt-tab list, which seems
> perfectly sane and sensible, and in fact alt-tab is the most logical
> way to move between maximized windows anyway.

Thank you for the fact, and the suggestion.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#74900

On Mon, Jul 21, 2014 at 1:05 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 7/20/2014 10:38 PM, Chris Angelico wrote:
>
>> on Windows. The file dialog appears in the alt-tab list, which seems
>> perfectly sane and sensible, and in fact alt-tab is the most logical
>> way to move between maximized windows anyway.
>
>
> Thank you for the fact, and the suggestion.

Not sure what suggestion you mean there, as I didn't think I was
making any, but... sure. You're welcome!

ChrisA

[toc] | [prev] | [next] | [standalone]

#74911

2014-07-21 4:30 GMT+02:00 Tim Chase <python.list@tim.thechases.com>:
> On 2014-07-20 19:06, Rick Johnson wrote:
>> ============================================================
>>  STEPS TO REPRODUCE BUG 1: "Attack of the clones!"
>> ============================================================
>>
>> 1. Open the IDLE application
>> 2. Maximize the window that appears
>> 3. Go to the "File Menu" and choose the "Open" command
>>
>> Now repeat step 3 at least one more time, but feel free to
>> keep opening new dialogs until your fingers bleed and/or
>> eyes pop out.
>
> In the versions of IDLE that I have here (2.7.3 and 3.2.3), both
> prevent me from repeating step #3 multiple times.

Not on 2.7.6 and 3.4  on Linux Mint either



-- 
Regards,

Martin S

[toc] | [prev] | [next] | [standalone]

#74887 — Re: Tabbed IDLE (was PyWart(2.7.8) IDLE is more buggy than "Joe's apartment"!)

On 2014-07-20 23:40, Irmen de Jong wrote:
> > And since IDLE is not a "tabbed editor", only *1* document
> > is going to be displayed at a time.  
> 
> False. Idle opens any number of documents at the same time just
> fine (in different windows - rather than tabs).

This sounds like a failing of the OP's window-manager.  Fluxbox lets
me combine any number of windows into a tabbed interface, so IDLE
*is* a tabbed editor on my machine (just like the Gimp).  Moreover, it
can even include other windows, so I just pulled together a tabbed
IDLE interface that also has a terminal for interacting with git, a
file-manager window for project management, and a mail window
(because Zawinski's law[1]). ;-)

-tkc


[1] """
Every program attempts to expand until it can read mail. Those
programs which cannot so expand are replaced by ones which can.
"""






.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web