[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 hwe 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
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 hwe 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
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 hwe 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: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 hwe 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 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 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 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 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 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
[PyKDE] eric3 and x86_64
Hello. I've been trying to get some (any) version of eric3 installed on a gentoo amd64 box. I've completely rebuilt all dependant libraries, just in case that was an issue. I've also tried different combinations of the PyQt (3.11, 3.12), sip (4.0.rc2, 4.0rc4, 4.0) and qscintilla (1.54, 1.60) libraries to no avail. Despite changing libraries, behavior seems consistent. All 3.4+ (3.4.1, 3.4.2, snapshot-20040622) versions seem to die after the splash screen with a segfault. All versions prior to 3.4 (3.3.x, 3.2.x) make it past the splash screen, the main window is displayed briefly (about 1 second) and terminates with a bus error. Any suggestions? ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] A simple PyQt program
Hi,
I'm having problem with a simple PyQt program I'm writing. It will
eventually become a GUI frontend to the Unix 'watch' command, but for
now, it's just a simple test. When I run the program, type in something
into the Command text box, then click OK, Python gives me the
following message:
TypeError: update() takes exactly 2 arguments (3 given)
I don't understand this, since I only gave update 2 arguments. If anyone
could shed some light on this, I'd greatly appreciate it. Here's the code:
import sys, os
from qt import *
from kwatchui import frmKwatch
from kwatcherui import frmKwatcher
class dlgKwatch(frmKwatch):
def __init__(self, parent=None):
frmKwatch.__init__(self, parent)
#self.txtCommand.setText(Joshua)
#this is old stuff
#self.cmbHost.insertItem(another item)
def accept(self):
command = self.txtCommand.text()
command = str(command)
os.system(command)
win2.update(self, command)
#frmKwatch.accept(self)
def exec_help(self):
os.system(khelpcenter)
class dlgKwatcher(frmKwatcher):
def __init__(self, parent=None):
frmKwatcher.__init__(self, parent)
def update(self, command):
print 'Updating the text in Kwatch - watching...'
self.txtWatcher.setText(command)
if __name__=='__main__':
app = QApplication(sys.argv)
QObject.connect(app, SIGNAL('lastWindowClosed()'), app, SLOT('quit()'))
win = dlgKwatch()
app.setMainWidget(win)
win.show()
win2 = dlgKwatcher()
win2.show()
app.exec_loop()
If you need the other files, I can attach them. Thanks.
Joshua K.
[EMAIL PROTECTED]
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] A simple PyQt program
On Sat, 26 Jun 2004, Joshua wrote: Hi, TypeError: update() takes exactly 2 arguments (3 given) ... win2.update(self, command) This has 3 arguments to the update command. Your arguments are (win2, self, command) - the win2 is an implicit first argument. I haven't looked through your code much, since I suspect this is the bit stumping you, but I suspect what you want is either: win2.update(command) self.update(command) I suspect the former of the 2. Michael. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] eric3 and x86_64
On Saturday 26 June 2004 05:00 pm, Hans-Peter Jansen wrote: Eric is definitely not the offender here, as I ran some of the above combinations on my SuSE 9.1-x86_64 system properly. That does help a bit. At least I know it's not a 64 bit issue... but just a gentoo amd64 issue. Did you supplied proper build arguments to the whole set, aka. lib64 vs. lib issues, and the like? I'm just building from the gentoo packages, but that could very well be part of the issue with the gentoo ebuilds. Providing a backtrace would be helpful, probably from a debug build, as well as trying some example3 scripts.. I think the next step will be to test the PyQT, sip and qscintilla libraries as installed. I doubt it goes as deep as qt, since I've been running KDE for awhile. I wonder if anyone else is having trouble with using one or more of these libs on gentoo amd64? -- Rick L. Vinyard, Jr. http://miskatonic.cs.nmsu.edu ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] A simple PyQt program
OK, that fixes that problem. Now I have another TypeError: TypeError: update() takes exactly 2 arguments (1 given) This happens when I open the app, type something in Command, click OK, then press Enter in the win2 window one or more times. I just don't understand why the dlgKwatcher.update() updating works so well when called from the dlgKwatch class, but yet not when it is called independently. I am using Qt Designer, so I have other files, from which I have included relevant sections: class frmKwatcher(QWidget): def __init__(self,parent = None,name = None,fl = 0): QWidget.__init__(self,parent,name,fl) if not name: self.setName(frmKwatcher) self.txtWatcher = QLineEdit(self,txtWatcher) self.txtWatcher.setGeometry(QRect(11,39,500,220)) self.languageChange() self.resize(QSize(527,306).expandedTo(self.minimumSizeHint())) self.clearWState(Qt.WState_Polished) self.connect(self.txtWatcher,SIGNAL(returnPressed()),self.update) def languageChange(self): self.setCaption(self.__tr(Kwatch - watching...)) def update(self): print frmKwatcher.update(): Not implemented yet Thanks. Josh Michael Sparks wrote: On Sat, 26 Jun 2004, Joshua wrote: Hi, TypeError: update() takes exactly 2 arguments (3 given) ... win2.update(self, command) This has 3 arguments to the update command. Your arguments are (win2, self, command) - the win2 is an implicit first argument. I haven't looked through your code much, since I suspect this is the bit stumping you, but I suspect what you want is either: win2.update(command) self.update(command) I suspect the former of the 2. Michael. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] A simple PyQt program
On Saturday 26 June 2004 15:49, Joshua wrote: TypeError: update() takes exactly 2 arguments (3 given) win2.update(self, command) win2.update (command) 'win2' effectively takes care of the 'self' argument. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] A simple PyQt program
Joshua wrote: TypeError: update() takes exactly 2 arguments (3 given) I don't understand this, since I only gave update 2 arguments. If anyone could shed some light on this, I'd greatly appreciate it. Here's the code: This is something fairly fundamental to Python programming, so you have to make sure that you understand how this works. When you have a class with a method: class Foo: def bar(self, x): print x And you call that method on an instance of the class: f = Foo() f.bar(abc) The instance, f, is automatically passed as the first argument to the function before any other arguments that are provided in the call. Therefore, when you declare methods in a class they must have a self parameter as the first parameter. There's more to this than I've explained here so you should read a Python book or online manual. Ciao, Gordon ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
