Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
Phil Thompson wrote: On Sunday 27 June 2004 12:33 am, Maurizio Colucci wrote: On Saturday 26 June 2004 07:03, Phil Thompson wrote: Obviously it's a very personal issue. If people generally think it's a good idea then I can add it. (It's a QScintilla thing, rather than an eric thing.) So you don't think the examples I gave you justify the change? Ok, thanks for your time anyway. :-) No, not at all. Its about priorities. I was, like you, inviting comments. If 99% of people use auto-completion the way you do then a new option should be high priority. If 99% of people would use the current sorting method then a new option should be low priority. As a data-point, I use (extensively) the search-back-search-forward ordering in PythonWin. It really does feel intuitive when you use it. I tend to rely on it such that, to type common idioms: something = whatever() something = this + something I'll type: s = this + s relying on the back-searching to find the name earlier on the line, and occasionally having to hit ctrl-space a few times if I want something earlier, but actually quite seldom needing to do that. Now, in PythonWin, there's no drop-down for the identifiers (just for methods), so what's actually happening with the ctrl-spaces there is that the word changes in the text, but it's almost the same effect. Typing a character or two and then hitting ctrl-space a few times will cycle through every identifier in the file that starts with that character (search first backward, then forward, which generally results in finding the identifier you want earlier rather than later). Anyway, just a data-point... I'd use it :) , Mike Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ blog: http://zope.vex.net/~mcfletch/plumbing/ ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Sunday 27 June 2004 12:33 am, Maurizio Colucci wrote: > On Saturday 26 June 2004 07:03, Phil Thompson wrote: > > Obviously it's a very personal issue. If people generally think it's a > > good idea then I can add it. (It's a QScintilla thing, rather than an > > eric thing.) > > So you don't think the examples I gave you justify the change? Ok, thanks > for your time anyway. :-) No, not at all. Its about priorities. I was, like you, inviting comments. If 99% of people use auto-completion the way you do then a new option should be high priority. If 99% of people would use the current sorting method then a new option should be low priority. Of course you can raise the priority yourself by submitting a patch :) Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 07:03, Phil Thompson wrote: > Obviously it's a very personal issue. If people generally think it's a good > idea then I can add it. (It's a QScintilla thing, rather than an eric > thing.) So you don't think the examples I gave you justify the change? Ok, thanks for your time anyway. :-) Maurizio ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 of June 2004 16:03, Phil Thompson wrote: > Obviously it's a very personal issue. If people generally think it's a good > idea then I can add it. (It's a QScintilla thing, rather than an eric > thing.) I'd prefer alphabetical order - it's more predictable and I type too fast to bother myself with searching through some lists... Regards, -- * Piotr (pitkali) Kalinowski * mailto: pitkali (at) o2 (dot) pl * * Registered Linux User No. 282090 * Powered by Gentoo Linux * * Fingerprint: D5BB 27C7 9993 50BB A1D2 33F5 961E FE1E D049 4FCD * pgpMI7GTQVfbl.pgp Description: signature
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 10:41 pm, Maurizio Colucci wrote: > On Saturday 26 June 2004 04:41, Phil Thompson wrote: > > In one situation... > > > > I need to type 4 characters of an 8 letter word in order to make that > > word current in the list. > > > > ...or in another... > > > > I can type 1 character, look at the list (the order of which may be > > different each time it is displayed depending on where I am in the file) > > and see that I only need to hit a cursor key twice to make the word > > current. > > > > Personally I'm always going to do the first. > > You mean, you prefer typing 4 characters than typing one and scanning the > list? Yes, of course: you developed this habit because, if you typed only > one character, you would have to scan a list that is too long. But IF the > list was sorted by distance, I bet you would have developed the opposite > habit: type one character and scan the list. Because the scan would NOT be > long in that case. No I wouldn't. For me, scanning the list is relatively time consuming. When I'm typing I'm thinking about what I want to type next, not about what I'm currently typing. To scan the list means that I have to stop thinking about that, start thinking about what I'm currently typing, read and navigate the list, then switch back to what I was originally thinking about. At my age these are non-trivial operations. If the contents of the list are predictable I can start taking it for granted by using without having to think about it too much - ie. without those expensive context switches. > > It's one extra keystroke, but > > it is relatively predictable. If I'm typing the same word many times I > > will quickly get into the habit of typing the 4 characters and selecting > > the current item without even bothering to look at the list. > > I believe typing one character is much more costly than pressing the down > arrow to search in the completion list. So I don't agree that you should > judge based on the number of keystrokes required. I'm saying that the point is to save time. > > Even though the second situation is one less keystroke (but maybe more > > depending on the context) it will be much slower because I have to read > > through the list - particulary if the list might need to be scrolled up > > or down to find what I'm looking for. > > The point is: you are not using the list in order to save typing letters. > You don't mind typing very much. > > My way of thinking, instead, is this: if I know I have typed a word very > recently, I type only the first two letters, then I scan the list until I > find it. Like I said, I'm too busy thinking about the next sentence. Obviously it's a very personal issue. If people generally think it's a good idea then I can add it. (It's a QScintilla thing, rather than an eric thing.) Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 04:41, Phil Thompson wrote: > > > I don't understand why a "near" word is more likely to be the one you > > > want to type than a "distant" word. > > I see you didn't respond to this fundamental point ;) Phil, I apologize. It is not that I don't want to reply, it is just that I considered it very obvious. It is simply something we observe. If I have to give you some examples: 1. example where you need a word typed a few lines ABOVE: class Widget(QObject): def __init__(self, width, height, numberOfLocations, longestPath): self.numberOfLocations = numberOfLocations self.longestPath = longestPath self.width= width self.height = height. Here how many times you use a word immediately after the same word? I would get mad to type this with eric3. I have no choice than to use emacs. What I want to do is type THE FIRST LETTER only, then look for the completion in the list. And the nearest MUST be the first one. 2. example where you need a word typed a few lines BELOW: ... for o in o2a: # HERE: addObjectToListWithProperIconAndButton(o, selectedObjects, k) for o in o2b: addObjectToListWithProperIconAndButton(o, selectedObjects, k) listBox[k].repaint() def addObjectToListWithProperIconAndButton(o, selectedObjects, k): ... - Sorry if I didn't reply. > > > I would think people use auto-completion for two reasons... > > > > Thanks Phil. :-) > > > > However, I must disagree with your reasoning: > > > 1. To save typing, ie. you know the spelling. > > > > Exactly, to save typing. > > > > > In this case you don't use > > > the arrow keys to move through the list. Instead you keep typing the > > > word > > > > But this contradicts the very hypothesis, that I want to save typing! :-) > > The reasoning is unsound... > > In one situation... > > I need to type 4 characters of an 8 letter word in order to make that word > current in the list. > > ...or in another... > > I can type 1 character, look at the list (the order of which may be > different each time it is displayed depending on where I am in the file) > and see that I only need to hit a cursor key twice to make the word > current. > > Personally I'm always going to do the first. You mean, you prefer typing 4 characters than typing one and scanning the list? Yes, of course: you developed this habit because, if you typed only one character, you would have to scan a list that is too long. But IF the list was sorted by distance, I bet you would have developed the opposite habit: type one character and scan the list. Because the scan would NOT be long in that case. > It's one extra keystroke, but > it is relatively predictable. If I'm typing the same word many times I will > quickly get into the habit of typing the 4 characters and selecting the > current item without even bothering to look at the list. I believe typing one character is much more costly than pressing the down arrow to search in the completion list. So I don't agree that you should judge based on the number of keystrokes required. > Even though the second situation is one less keystroke (but maybe more > depending on the context) it will be much slower because I have to read > through the list - particulary if the list might need to be scrolled up or > down to find what I'm looking for. The point is: you are not using the list in order to save typing letters. You don't mind typing very much. My way of thinking, instead, is this: if I know I have typed a word very recently, I type only the first two letters, then I scan the list until I find it. bye Maurizio ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 8:39 pm, Maurizio Colucci wrote: > On Saturday 26 June 2004 03:30, Phil Thompson wrote: > > On Saturday 26 June 2004 8:02 pm, Maurizio Colucci wrote: > > > Hello, > > > > > > IMHO, with a small change, eric3 would become much more usable. > > > > > > I noticed there is a good autocompletion feature, with a listbox that > > > pops up; then you move with the arrows. The overall result is similar > > > to emacs' (M-/) autocompletion feature. The only problem is that the > > > list is not sorted by distance. So it takes many presses on the down > > > arrow to reach the correct completion (on average). > > > > > > Example: > > > imagine the contents of the file is as follows: > > > > > > hbbb > > > hddd > > > h <<< we press "h" here > > > hc > > > ha > > > > > > and suppose we press h in the middle of the file. Then, the list of > > > completions should be sorted as follows: > > > [ hdd, h, hbbb, haa] > > > > > > that is, not by name, but by distance (and if two words have the same > > > distance, you prefer the one above). > > > > > > I think if eric3 could have such a feature, I would prefer it over > > > emacs for editing my code. > > > > > > Thanks for any comment :-) > > > > I don't understand why a "near" word is more likely to be the one you > > want to type than a "distant" word. I see you didn't respond to this fundamental point ;) > > I would think people use auto-completion for two reasons... > > Thanks Phil. :-) > > However, I must disagree with your reasoning: > > 1. To save typing, ie. you know the spelling. > > Exactly, to save typing. > > > In this case you don't use > > the arrow keys to move through the list. Instead you keep typing the word > > But this contradicts the very hypothesis, that I want to save typing! :-) > The reasoning is unsound... In one situation... I need to type 4 characters of an 8 letter word in order to make that word current in the list. ...or in another... I can type 1 character, look at the list (the order of which may be different each time it is displayed depending on where I am in the file) and see that I only need to hit a cursor key twice to make the word current. Personally I'm always going to do the first. It's one extra keystroke, but it is relatively predictable. If I'm typing the same word many times I will quickly get into the habit of typing the 4 characters and selecting the current item without even bothering to look at the list. Even though the second situation is one less keystroke (but maybe more depending on the context) it will be much slower because I have to read through the list - particulary if the list might need to be scrolled up or down to find what I'm looking for. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 03:30, Phil Thompson wrote: > On Saturday 26 June 2004 8:02 pm, Maurizio Colucci wrote: > > Hello, > > > > IMHO, with a small change, eric3 would become much more usable. > > > > I noticed there is a good autocompletion feature, with a listbox that > > pops up; then you move with the arrows. The overall result is similar to > > emacs' (M-/) autocompletion feature. The only problem is that the list is > > not sorted by distance. So it takes many presses on the down arrow to > > reach the correct completion (on average). > > > > Example: > > imagine the contents of the file is as follows: > > > > hbbb > > hddd > > h <<< we press "h" here > > hc > > ha > > > > and suppose we press h in the middle of the file. Then, the list of > > completions should be sorted as follows: > > [ hdd, h, hbbb, haa] > > > > that is, not by name, but by distance (and if two words have the same > > distance, you prefer the one above). > > > > I think if eric3 could have such a feature, I would prefer it over emacs > > for editing my code. > > > > Thanks for any comment :-) > > I don't understand why a "near" word is more likely to be the one you want > to type than a "distant" word. > > I would think people use auto-completion for two reasons... Thanks Phil. :-) However, I must disagree with your reasoning: > 1. To save typing, ie. you know the spelling. Exactly, to save typing. > In this case you don't use > the arrow keys to move through the list. Instead you keep typing the word But this contradicts the very hypothesis, that I want to save typing! :-) The reasoning is unsound... > until it becomes the current one in the list, then you select it. In this > case the order is irrelevant. > > 2. When you can't remember the spelling, so you type as much as you can > remember, then use the list to pick the right (probably only) one. In this > case you want a predictable order, not one that is context sensitive. You > wouldn't know if you needed to scroll the list upwards or downwards to find > what you want. Personally I don't use it for purpose (2), so I can't reply here. Mauri ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Trivial improvement in the autocompletion of Eric3
On Saturday 26 June 2004 8:02 pm, Maurizio Colucci wrote: > Hello, > > IMHO, with a small change, eric3 would become much more usable. > > I noticed there is a good autocompletion feature, with a listbox that pops > up; then you move with the arrows. The overall result is similar to emacs' > (M-/) autocompletion feature. The only problem is that the list is not > sorted by distance. So it takes many presses on the down arrow to reach the > correct completion (on average). > > Example: > imagine the contents of the file is as follows: > > hbbb > hddd > h <<< we press "h" here > hc > ha > > and suppose we press h in the middle of the file. Then, the list of > completions should be sorted as follows: > [ hdd, h, hbbb, haa] > > that is, not by name, but by distance (and if two words have the same > distance, you prefer the one above). > > I think if eric3 could have such a feature, I would prefer it over emacs > for editing my code. > > Thanks for any comment :-) I don't understand why a "near" word is more likely to be the one you want to type than a "distant" word. I would think people use auto-completion for two reasons... 1. To save typing, ie. you know the spelling. In this case you don't use the arrow keys to move through the list. Instead you keep typing the word until it becomes the current one in the list, then you select it. In this case the order is irrelevant. 2. When you can't remember the spelling, so you type as much as you can remember, then use the list to pick the right (probably only) one. In this case you want a predictable order, not one that is context sensitive. You wouldn't know if you needed to scroll the list upwards or downwards to find what you want. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Trivial improvement in the autocompletion of Eric3
Hello, IMHO, with a small change, eric3 would become much more usable. I noticed there is a good autocompletion feature, with a listbox that pops up; then you move with the arrows. The overall result is similar to emacs' (M-/) autocompletion feature. The only problem is that the list is not sorted by distance. So it takes many presses on the down arrow to reach the correct completion (on average). Example: imagine the contents of the file is as follows: hbbb hddd h <<< we press "h" here hc ha and suppose we press h in the middle of the file. Then, the list of completions should be sorted as follows: [ hdd, h, hbbb, haa] that is, not by name, but by distance (and if two words have the same distance, you prefer the one above). I think if eric3 could have such a feature, I would prefer it over emacs for editing my code. Thanks for any comment :-) Maurizio ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
