Attachment virtualBufferModes.zip added by aleksey_s on 2008-11-26 18:15
Description:
bzr merge-directive of my branch, which implements requested thing

Comment 1 by aleksey_s on 2008-11-26 18:17
Changes:
Changed title from "update virtual buffer code to remove legacy passthrough on and off" to "update virtual buffer code to remove outdated passthrough on and `off"

Comment 2 by jteh on 2008-11-26 22:46
There are a few reasons I didn't do this:

• We weren't sure if the names might change at a later point.
• Although I changed the names for users, the internal concept is still the same; it still "passes through" the virtual buffer.
• There is no name that can cover both browse mode and focus mode except pass-through. In your patch, you have called it virtualBufferMode, but this could refer to many things. However, passThrough clearly defines what it refers to.
• In your patch, you have changed the config names to "autoFocusModeOnFocusChange", etc. I realise that this is what I have called them in the GUI< but the problem is that it doens't cover the fact that it also automatically changes to browse mode on focus change if appropriate. This is one example of why a term that covers both modes is necessary. I'm not convinced that the terms I used in the GUI are ideal.
  Mick, any thoughts on this?

A few other comments on your patch:

• I'd probably prefer "==" instead of "is" when comparing the mode against its constants. In this case, they have the same effect because they're actually the same object, but using "is" is generally better when you explicitly care that they're the same object, rather than when testing for equality. This is a minor point, and Mick and I argue about this one all the time. :)
• If you want two explicitly different modes, you should probably not use True and False. Once you define two explicitly separate modes, you are no longer talking about a boolean. This is one reason I prefer the old approach.
  • In particular, using "not mode" to reverse the mode is not logical, as you've defined two explicitly separate modes.

Comment 3 by aleksey_s (in reply to comment 2) on 2008-11-27 07:49
Replying to jteh:

There are a few reasons I didn't do this:

• We weren't sure if the names might change at a later point.

i think this must be exactly defined at one day. isn't it?

• Although I changed the names for users, the internal concept is still the same; it still "passes through" the virtual buffer.

do you sure we will not have another mode never?

• There is no name that can cover both browse mode and focus mode except pass-through. In your patch, you have called it virtualBufferMode, but this could refer to many things.

what things for example? we can describe this property in source one time. personally i think my proposal is better readable that that one with passthrough.

However, passThrough clearly defines what it refers to.

then why did you changed it for users? :-)

• In your patch, you have changed the config names to "autoFocusModeOnFocusChange", etc. I realise that this is what I have called them in the GUI< but the problem is that it doens't cover the fact that it also automatically changes to browse mode on focus change if appropriate.

i just noted, that it must be sorted out. well, lets call it "guess/change virtual buffer mode when focus changes/when caret moves"...

This is one example of why a term that covers both modes is necessary. I'm not convinced that the terms I used in the GUI are ideal.

i think virtual buffer mode also cowers this.

• I'd probably prefer "==" instead of "is" when comparing the mode against its constants. In this case, they have the same effect because they're actually the same object, but using "is" is generally better when you explicitly care that they're the same object, rather than when testing for equality. This is a minor point, and Mick and I argue about this one all the time. :)

accepted. sorry for this, my python knowledges are not quite.

• If you want two explicitly different modes, you should probably not use True and False. Once you define two explicitly separate modes, you are no longer talking about a boolean. This is one reason I prefer the old approach.

i made constants and used they for this where possible.

• In particular, using "not mode" to reverse the mode is not logical, as you've defined two explicitly separate modes.

sorry, my mistake. i thought i removed such entries.

Comment 4 by jteh (in reply to comment 3) on 2008-11-27 08:06
Replying to aleksey_s:

• We weren't sure if the names might change at a later point.

i think this must be exactly defined at one day. isn't it?

Yes. I should have clarified that this was a reason at the time. It is no longer a valid reason. :) Sorry for the confusion.

• Although I changed the names for users, the internal concept is still the same; it still "passes through" the virtual buffer.

do you sure we will not have another mode never?

I don't believe we will, except perhaps not having a buffer at all, which means this concept doesn't exist.

• There is no name that can cover both browse mode and focus mode except pass-through. In your patch, you have called it virtualBufferMode, but this could refer to many things.

what things for example?

I can't think of any other examples right now, but virtual buffer mode has no real meaning; it doesn't describe a concept. It infers "the mode of the virtual buffer", but mode could mean almost anything. For argument's sake, it might mean whether the buffer automatically updates or whether it will include the content of combo boxes. The term "mode" needs to be clarified by something.

personally i think my proposal is better readable that that one with passthrough.

I think pass-through is more specific. However, see below...

However, passThrough clearly defines what it refers to.

then why did you changed it for users? :-)

:) This is a very good point. I believe that pass-through makes sense as a term for developers, but not for users. However, you are right in saying that this is inconsistent.

Comment 5 by aleksey_s (in reply to comment 4) on 2008-11-27 08:39
Replying to jteh:

I can't think of any other examples right now, but virtual buffer mode has no real meaning; it doesn't describe a concept. It infers "the mode of the virtual buffer", but mode could mean almost anything. For argument's sake, it might mean whether the buffer automatically updates or whether it will include the content of combo boxes. The term "mode" needs to be clarified by something.

may be by docstring in source? :-)

I think pass-through is more specific. However, see below...

:) This is a very good point. I believe that pass-through makes sense as a term for developers, but not for users. However, you are right in saying that this is inconsistent.

now i don't understand what do you want. you have said that passthrought is covering our behavior, but you also agree that it implements inconsistency.

Comment 6 by jteh (in reply to comment 5) on 2008-11-27 09:23
Replying to aleksey_s:

The term "mode" needs to be clarified by something.

may be by docstring in source? :-)

If this is the case, we may as well just stick with passThrough. This is my argument: passThrough is at least clear; it defines a concept for which there are two possible values or modes.

now i don't understand what do you want. you have said that passthrought is covering our behavior, but you also agree that it implements inconsistency.

It is inconsistent with the user experience. However, I don't agree that your solution is any better: it might reduce some inconsistency, but it is also less clear what the mode actually does.

Comment 7 by jteh on 2009-02-16 02:07
This will not be implemented, at least until we come up with clearer terminology.
Changes:
Added labels: wontfix
State: closed