Hi!
I have a feature request, that would make my life so much simpler. I am Python coder and I use geany all the time to code in it - both at work and for personal projects.
So: right now geany detects some symbols, that are defined in open files and suggests them, when you type the beggining of a symbol. Could Geany also do the following: check imports at the beggining of a file and use them in suggestions? This would be very cool, as I am using always named imports (and they are recommended) and thanks to this, I would get names of objects, even though I don't have files with definitions opened. This especially useful for third party libraries - I ain't going to open files from /usr/lib just to get suggestions, but this way I will still get them.
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
On Sun, 17 May 2009 23:29:26 +0200, Filip wrote:
Hi!
I have a feature request, that would make my life so much simpler. I am Python coder and I use geany all the time to code in it - both at work and for personal projects.
So: right now geany detects some symbols, that are defined in open files and suggests them, when you type the beggining of a symbol. Could Geany also do the following: check imports at the beggining of a file and use them in suggestions? This would be very cool, as I am using always named imports (and they are recommended) and thanks to this, I would get names of objects, even though I don't have files with definitions opened. This especially useful for third party libraries - I ain't going to open files from /usr/lib just to get suggestions, but this way I will still get them.
This was already requested a couple of times. I'm not sure whether we want this. It would probably require quite some effort to parse import statements from an opened source file, find the corresponding Python files, parse them, merge the parsed information into tagmanager(the code which provides the main part of symbol completion data). Additionally, added symbols should maybe removed again when the source file is closed which also might not be that trivial.
And after all as always, the code still has to be written.
Another, more manual way could be to create a global tags file yourself from these Python libs you usually use. General information about globals tags and how to use them can be found on http://geany.org/manual/#global-tags. For creating your custom Python tags files, you could use http://geany.svn.sourceforge.net/viewvc/geany/trunk/scripts/create_py_tags.p... as an inspiration on how to create one.
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
Sure, but as usual it needs someone to write the code.
Regards, Enrico
This was already requested a couple of times. I'm not sure whether we want this. It would probably require quite some effort to parse import statements from an opened source file, find the corresponding Python files, parse them, merge the parsed information into tagmanager(the code which provides the main part of symbol completion data). Additionally, added symbols should maybe removed again when the source file is closed which also might not be that trivial.
I am not suggesting anything as complicated, as you say. I understand, that in situation like thos:
import sth
you want to find module sth.py and detect all symbols inside. I think enough is to add sth to namespace. It would became useful in following situation:
from sth import LongNameClass, AnotherLongNameClass
and simply add those two. You need to only parse imports and detect names, that were added to the local namespace.
And after all as always, the code still has to be written.
Yep, as always ;-)
Another, more manual way could be to create a global tags file yourself from these Python libs you usually use. General information about globals tags and how to use them can be found on http://geany.org/manual/#global-tags. For creating your custom Python tags files, you could use http://geany.svn.sourceforge.net/viewvc/geany/trunk/scripts/create_py_tags.p... as an inspiration on how to create one.
I'll seriously consider this ;-)
On Mon, 18 May 2009 19:54:24 +0200, Filip wrote:
This was already requested a couple of times. I'm not sure whether we want this. It would probably require quite some effort to parse import statements from an opened source file, find the corresponding Python files, parse them, merge the parsed information into tagmanager(the code which provides the main part of symbol completion data). Additionally, added symbols should maybe removed again when the source file is closed which also might not be that trivial.
I am not suggesting anything as complicated, as you say. I understand, that in situation like thos:
import sth
you want to find module sth.py and detect all symbols inside. I think enough is to add sth to namespace. It would became useful in following situation:
from sth import LongNameClass, AnotherLongNameClass
and simply add those two. You need to only parse imports and detect names, that were added to the local namespace.
Ha, I guess I was a bit off the road with my ideas...:).
Your suggestion was actually quite easy to implement, I did it in SVN. Geany now parses import statements for Python files and provide it as symbol compeltion. Currently it also lists them in the symbol list though I'm not yet completely sure whether we really want this. Awaiting some feedback of Python users :).
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Regards, Enrico
Le Tue, 19 May 2009 22:33:07 +0200, Enrico Tröger enrico.troeger@uvena.de s'exprima ainsi:
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Yes, sadly, there's a variant that will complicate a bit your table updating: from soup import foo as f, bar as b, ... renames (in local scope) while importing.
There are also imports from sub packages (read: sub-dir): import foo.bar from foo.bar import fish, chips as crisps
And recently (python 2.5 I guess) relative imports using leading dot(s), in a form similar to *nix filesystems: from ..foo import bar
Denis ------ la vita e estrany
On Tue, 19 May 2009 23:12:28 +0200, spir wrote:
Le Tue, 19 May 2009 22:33:07 +0200, Enrico Tröger enrico.troeger@uvena.de s'exprima ainsi:
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Yes, sadly, there's a variant that will complicate a bit your table updating: from soup import foo as f, bar as b, ... renames (in local scope) while importing.
There are also imports from sub packages (read: sub-dir): import foo.bar from foo.bar import fish, chips as crisps
And recently (python 2.5 I guess) relative imports using leading dot (s), in a form similar to *nix filesystems: from ..foo import bar
Yay, would have been too cool if my code would have been working :). I'll took into your example later (read end of the week or next week).
If anyone wants to improve it, have a look at parseImports() in tagmanager/python.c.
Regards, Enrico
On Tue, 19 May 2009 23:12:28 +0200, spir wrote:
Le Tue, 19 May 2009 22:33:07 +0200, Enrico Tröger enrico.troeger@uvena.de s'exprima ainsi:
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Yes, sadly, there's a variant that will complicate a bit your table updating: from soup import foo as f, bar as b, ... renames (in local scope) while importing.
I get "f" and "b" for this one which seems correct to me.
There are also imports from sub packages (read: sub-dir): import foo.bar
This one is ugly, currently it is detected as "foo" and "bar". But "fixing" this would mean to consider the dot as a valid chacracter for identifiers. Not sure whether it's worth at all.
from foo.bar import fish, chips as crisps
This is one is detected as "fish" and "crisps" which is what the code should do. Is this wrong?
And recently (python 2.5 I guess) relative imports using leading dot (s), in a form similar to *nix filesystems: from ..foo import bar
The current code detects this as "bar" which seems correct to me?
Maybe my understanding of the import statements is wrong as I never really read the docs about it :). But I thought something like from foo import bar as b means that I import the class "bar" from the module(i.e. file?) "foo" and in the following code "bar" can be referred as "b". If so, the current parsing code is correct.
Regards, Enrico
Am 19.05.2009 22:33, schrieb Enrico Tröger:
On Mon, 18 May 2009 19:54:24 +0200, Filip wrote:
This was already requested a couple of times. I'm not sure whether we want this. It would probably require quite some effort to parse import statements from an opened source file, find the corresponding Python files, parse them, merge the parsed information into tagmanager(the code which provides the main part of symbol completion data). Additionally, added symbols should maybe removed again when the source file is closed which also might not be that trivial.
I am not suggesting anything as complicated, as you say. I understand, that in situation like thos:
import sth
you want to find module sth.py and detect all symbols inside. I think enough is to add sth to namespace. It would became useful in following situation:
from sth import LongNameClass, AnotherLongNameClass
and simply add those two. You need to only parse imports and detect names, that were added to the local namespace.
Ha, I guess I was a bit off the road with my ideas...:).
Your suggestion was actually quite easy to implement, I did it in SVN. Geany now parses import statements for Python files and provide it as symbol compeltion. Currently it also lists them in the symbol list though I'm not yet completely sure whether we really want this. Awaiting some feedback of Python users :).
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Regards, Enrico
Can we have this for C'ish #includes as well, if not already done that is. The tricky part is the various include dirs which are totally custom in many projects :(
Best regards.
On Wed, 20 May 2009 00:30:30 +0200, Thomas wrote:
Am 19.05.2009 22:33, schrieb Enrico Tröger:
On Mon, 18 May 2009 19:54:24 +0200, Filip wrote:
This was already requested a couple of times. I'm not sure whether we want this. It would probably require quite some effort to parse import statements from an opened source file, find the corresponding Python files, parse them, merge the parsed information into tagmanager(the code which provides the main part of symbol completion data). Additionally, added symbols should maybe removed again when the source file is closed which also might not be that trivial.
I am not suggesting anything as complicated, as you say. I understand, that in situation like thos:
import sth
you want to find module sth.py and detect all symbols inside. I think enough is to add sth to namespace. It would became useful in following situation:
from sth import LongNameClass, AnotherLongNameClass
and simply add those two. You need to only parse imports and detect names, that were added to the local namespace.
Ha, I guess I was a bit off the road with my ideas...:).
Your suggestion was actually quite easy to implement, I did it in SVN. Geany now parses import statements for Python files and provide it as symbol compeltion. Currently it also lists them in the symbol list though I'm not yet completely sure whether we really want this. Awaiting some feedback of Python users :).
For testing the parser, I mainly used the following code snippet: import os, sys, errno, re, glob, gc, datetime, shutil try: import cPickle except: import pickle as cPickle import Runner, TaskGen, Node, Scripting, Utils, Environment, Task, Logs, Options from Logs import debug, error, info from Constants import *
Are there other variants of "import" statements possible? You know, my Python knowledge is very limited :).
Regards, Enrico
Can we have this for C'ish #includes as well, if not already done that is. The tricky part is the various include dirs which are totally custom in many projects :(
It wouldn't be more tricky than the current Python implementation, the file and directory structure behind isn't related.
Thomas, only the imported module names are parsed, not the files they are pointing to. So, in theory this could be done for C-like #includes as well but I doubt it would be that useful.
Regards, Enrico
Enrico, you are just AWESOME! You have just made my everyday hacking so much easier :-) Since I am import freak and I explicitly import everything in Python, this will make produce much faster, since I like long names.
Geany rox, guys :-)
On Mon, 18 May 2009 19:13:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
Sure, but as usual it needs someone to write the code.
Now done in SVN. Actually it removes any existing word part to the right.
Regards, Nick
Now done in SVN. Actually it removes any existing word part to the right.
And it's quite smart - it didn't remove function args, even though it removed old function name. This is very cool Nick, thanks a lot!
On Tue, 19 May 2009 12:24:40 +0100, Nick wrote:
On Mon, 18 May 2009 19:13:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
Sure, but as usual it needs someone to write the code.
Now done in SVN. Actually it removes any existing word part to the right.
Cool. I didn't expect Scintilla provide this feature already. I would have ended up in writing this on my own and then realising Scintilla can do it as well and then getting frustrated :).
Regards, Enrico
On Tue, 19 May 2009 22:20:54 +0200, Enrico wrote:
On Tue, 19 May 2009 12:24:40 +0100, Nick wrote:
On Mon, 18 May 2009 19:13:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
Sure, but as usual it needs someone to write the code.
Now done in SVN. Actually it removes any existing word part to the right.
Cool. I didn't expect Scintilla provide this feature already. I would have ended up in writing this on my own and then realising Scintilla can do it as well and then getting frustrated :).
Ah, forgot again to finish my message before sending it:
I'm not sure whether we need a pref for it. I'd say let's use it for some time and then decide. So far after about an hour of using this change, I got three times into a replacement where more were deleted than I wanted. But I think this is just a matter of time to get used to the changed behaviour. Let's see.
Regards, Enrico
I've just started using Geany again lately, with 0.17, after a long spell using just Gedit. Gedit doesn't really do completion and I didn't really miss it much, but coming back to Geany, this completiontiontion stuff is really quite annoying - it makes the completion feature annoying about 50% of the time I use it and I've increasingly found my self pressing escape when it pops up, especially when editing existing code.
So, in essence, this new vesrion sounds much better and I think it should probably be the default.
Dunc
2009/5/19 Enrico Tröger enrico.troeger@uvena.de
On Tue, 19 May 2009 22:20:54 +0200, Enrico wrote:
On Tue, 19 May 2009 12:24:40 +0100, Nick wrote:
On Mon, 18 May 2009 19:13:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Furthermore, there is one more thing, that I once noted on this list, but wasn't addressed. Let's take following examples: there is symbol SomeClassWithLongName and I have already typed WithLongName. If I start typing Some right before WithLongName and I get the following:
SomeWithLongName
I'll get a completion suggestion, which I will choose. But then it will turn into SomeClassWithLongNameWithLongName. Is it possible for geany to be smarter and simple add Class and nothing else?
Sure, but as usual it needs someone to write the code.
Now done in SVN. Actually it removes any existing word part to the right.
Cool. I didn't expect Scintilla provide this feature already. I would have ended up in writing this on my own and then realising Scintilla can do it as well and then getting frustrated :).
Ah, forgot again to finish my message before sending it:
I'm not sure whether we need a pref for it. I'd say let's use it for some time and then decide. So far after about an hour of using this change, I got three times into a replacement where more were deleted than I wanted. But I think this is just a matter of time to get used to the changed behaviour. Let's see.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Tue, 19 May 2009 22:35:35 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I'm not sure whether we need a pref for it. I'd say let's use it for some time and then decide. So far after about an hour of using this change, I got three times into a replacement where more were deleted than I wanted. But I think this is just a matter of time to get used to the changed behaviour. Let's see.
OK, let me know if you decide we need a pref.
Regards, Nick