Hi ...
I really like the way Geany is developing, and after making some changes my self I have found a few things I really like to be a part of the nice IDE.
There have been done a lot to make code handling really nice, and I am growing very addicted to stuff like the symbol list and the fast highlight feature. Many of the features in Geany are normally found in much larger IDE systems and I have therefor never really used these before.
I really like the light weight idea, so I guess we have to be careful of what will be put inside the base system and what we put into a plugin.
But there are a few things I am missing :
* emacs keys and behavior (like auto structure) * make file generation (cmake, automake or plain make) * network code development
emacs : If the plugin interface could handle key strokes, code insertion handles, and be able to work directly inside the text buffer, this should be do able from a plugin really soon. Maybe the plugin should be able to take over the key stroke table ? It would be nice to see this as a Lua script too.
Project: It would be sad to see a full size make file generation go into Geany as part of the IDE, but plugins would be the proper way to handle this. But it would be nice if the central project system could handle a list of project files (not session) and that a plugin could get access to this list, and from this generate makefiles, setting options and other usefull stuff.
If Geany gets a plugin manager, we could also select the makefile support that we needed.
But Geany need to have a "project files", along with the "symbols", "Documents", "Files" in the sidebar.
This feature could also be used for web site uploads and other project orientated stuff.
Network: A friend of my have this nice idea of making a distributing editor environment where more than one person could work on the same file, while talking on the phone or using IM of a kind. If a plugin could have total power of file load, save and all changes made in the editor, this could be a perfect playgroud for a feature like this, without bloating Geany itself.
This is some of my idea's ... is this do able and within scope of Geany or am I way off track ?
/BL
On Sun, 18 Nov 2007 12:23:40 +0100, Bo Lorentsen bl@lue.dk wrote:
Hi,
emacs : If the plugin interface could handle key strokes, code insertion handles, and be able to work directly inside the text buffer, this should be do able from a plugin really soon. Maybe the plugin should be able to take over the key stroke table ? It would be nice to see this as a Lua script too.
I guess John would be happy about an emacs keybinding plugin ;-). But yes, plugins should be able to define own keybindings or even be able to change existing ones. Just need to be implemented.
Project: It would be sad to see a full size make file generation go into Geany as part of the IDE, but plugins would be the proper way to handle this. But it would be nice if the central project system could
Yes, IMO this is an ideal purpose for a plugin.
handle a list of project files (not session) and that a plugin could get access to this list, and from this generate makefiles, setting options and other usefull stuff.
Project management is missing a discrete file list by design. We decided to not add a file list to the project object to keep it small and easy to use. Anyway, we wanted to add a file pattern option so that a general bunch of files could be added to the project. But as an alternative, the plugin API could get access to the project's config file and so plugins could maintain a file list for a project by themselves. Not sure about this.
But Geany need to have a "project files", along with the "symbols", "Documents", "Files" in the sidebar.
Hmmm, see above.
This feature could also be used for web site uploads and other project orientated stuff.
Network: A friend of my have this nice idea of making a distributing editor environment where more than one person could work on the same file, while talking on the phone or using IM of a kind.
This is a completely different kind of applications with different needs and purposes. Furthermore, there are already a couple of projects to provide such apps. I'm not completely sure at the moment, but some time ago I read something about this and IIRC there were three well-known applications mentioned, but I don't remember the names, sorry.
If a plugin could have total power of file load, save and all changes made in the editor, this could be a perfect playgroud for a feature like this, without bloating Geany itself.
This sounds a bit like the gnomevfs stuff. Please no. File operations are quite elementary and they should remain in the core, IMO. Anyway, there are already plugin signals for file new, open and save. So, a plugin could use these signals to do some external operations.
Regards, Enrico
On Nov 18, 2007 10:31 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 18 Nov 2007 12:23:40 +0100, Bo Lorentsen bl@lue.dk wrote:
emacs : If the plugin interface could handle key strokes, code insertion handles, and be able to work directly inside the text buffer, this should be do able from a plugin really soon. Maybe the plugin should be able to take over the key stroke table ? It would be nice to see this as a Lua script too.
I guess John would be happy about an emacs keybinding plugin ;-).
Yes, I do think putting Geany's ease of use together with Emacs' key bindings would be a great combination. :)
But yes, plugins should be able to define own keybindings or even be able to change existing ones. Just need to be implemented.
Emacs, of course, makes use of the Alt keys heavily. For Geany to be able to provide Emacs key bindings, you'd need to first shut off all (or most) current Alt key bindings, including ones that open menus. No idea how easy or difficult this would be. I remember hearing Enrico mention previously that "some" GTK-related key bindings could not be remapped. I don't know the details of that though.
---John
John Gabriele wrote:
Yes, I do think putting Geany's ease of use together with Emacs' key bindings would be a great combination. :)
Agreed ... do you have an idea to what kind of interface we may need to make these changed from an plugin ?
Emacs, of course, makes use of the Alt keys heavily. For Geany to be able to provide Emacs key bindings, you'd need to first shut off all (or most) current Alt key bindings, including ones that open menus. No idea how easy or difficult this would be. I remember hearing Enrico mention previously that "some" GTK-related key bindings could not be remapped. I don't know the details of that though.
Would it help to be able to remap all the existing key bindings ? That way the user also may be able to edit it manually afterwards.
Is so, would it not be necessary to be able to keep two key combinations too like "ctrl-x ctrl-s" ?
/BL
On Nov 18, 2007 5:43 PM, Bo Lorentsen bl@lue.dk wrote:
John Gabriele wrote:
Yes, I do think putting Geany's ease of use together with Emacs' key bindings would be a great combination. :)
Agreed ... do you have an idea to what kind of interface we may need to make these changed from an plugin ?
Nope. I haven't done anything yet with Geany's plug-in system. Actually, I've been holding out hope that someone writes a Python plug-in for it -- similar to Jeff's nice Lua plug-in. Nothing against Lua, but I already know Python, and currently, the next extension language in my queue to learn is elisp.
Emacs, of course, makes use of the Alt keys heavily. For Geany to be able to provide Emacs key bindings, you'd need to first shut off all (or most) current Alt key bindings, including ones that open menus. No idea how easy or difficult this would be. I remember hearing Enrico mention previously that "some" GTK-related key bindings could not be remapped. I don't know the details of that though.
Would it help to be able to remap all the existing key bindings ? That way the user also may be able to edit it manually afterwards.
Is so, would it not be necessary to be able to keep two key combinations too like "ctrl-x ctrl-s" ?
I think that if there were an Emacs key-binding-compatibility plug-in, the goal should be to make it as authentic as possible. The "two key combinations" (that is, using prefix keys) is an important component of the bindings. They actually hierarchically organize commands quite nicely. Any anyway, if Geany were to have Emacs bindings, I'm guessing that the point would probably be to allow current Emacs users to easily move between Emacs and Geany (thus it would be beneficial to be as similar as possible).
---John
John Gabriele wrote:
Nope. I haven't done anything yet with Geany's plug-in system. Actually, I've been holding out hope that someone writes a Python plug-in for it -- similar to Jeff's nice Lua plug-in. Nothing against Lua, but I already know Python, and currently, the next extension language in my queue to learn is elisp.
Hmm, I am sure Lua is much faster to learn than elisp :-)
Ok, I like to see a emacs binding plugin, but I'm am not sure I'm able to make the needed changes myself.
I think that if there were an Emacs key-binding-compatibility plug-in, the goal should be to make it as authentic as possible. The "two key combinations" (that is, using prefix keys) is an important component of the bindings. They actually hierarchically organize commands quite nicely. Any anyway, if Geany were to have Emacs bindings, I'm guessing that the point would probably be to allow current Emacs users to easily move between Emacs and Geany (thus it would be beneficial to be as similar as possible).
And when that works vi have all the vi (vim) users that like the same :-)
/BL
On Nov 19, 2007 1:16 AM, Bo Lorentsen bl@lue.dk wrote:
Ok, I like to see a emacs binding plugin, but I'm am not sure I'm able to make the needed changes myself.
I'm pretty sure that it is not a goal of Geany to be like Emacs, so I'm guessing that priority is not very high for making additions to facilitate such a key bindings plug-in.
That said however, the todo list includes an item that says "plugin keybindings"... Not sure exactly what that means though.
---John
On Mon, 19 Nov 2007 03:05:08 -0500, "John Gabriele" jmg3000@gmail.com wrote:
On Nov 19, 2007 1:16 AM, Bo Lorentsen bl@lue.dk wrote:
Ok, I like to see a emacs binding plugin, but I'm am not sure I'm able to make the needed changes myself.
I'm pretty sure that it is not a goal of Geany to be like Emacs, so I'm guessing that priority is not very high for making additions to facilitate such a key bindings plug-in.
Exactly.
That said however, the todo list includes an item that says "plugin keybindings"... Not sure exactly what that means though.
Basically, it means to provide the ability for plugins to register keybindings to certain actions provided by the plugin. But details have to be defined and at the moment I'm not sure how to implement it. Be patient.
Regards, Enrico
On Mon, 19 Nov 2007 07:16:46 +0100, Bo Lorentsen bl@lue.dk wrote:
John Gabriele wrote:
Nope. I haven't done anything yet with Geany's plug-in system. Actually, I've been holding out hope that someone writes a Python plug-in for it -- similar to Jeff's nice Lua plug-in. Nothing against Lua, but I already know Python, and currently, the next extension language in my queue to learn is elisp.
Hmm, I am sure Lua is much faster to learn than elisp :-)
Ok, I like to see a emacs binding plugin, but I'm am not sure I'm able to make the needed changes myself.
I think that if there were an Emacs key-binding-compatibility plug-in, the goal should be to make it as authentic as possible. The "two key combinations" (that is, using prefix keys) is an important component of the bindings. They actually hierarchically organize commands quite nicely. Any anyway, if Geany were to have Emacs bindings, I'm guessing that the point would probably be to allow current Emacs users to easily move between Emacs and Geany (thus it would be beneficial to be as similar as possible).
And when that works vi have all the vi (vim) users that like the same :-)
This sounds to me like are reason to not implement plugin keybinding support ;-). Did I ever mention Geany is not emacs and vi? ;-)
Regards, Enrico
Hi,
On Mon, 19 Nov 2007 07:16:46 +0100 Bo Lorentsen bl@lue.dk wrote:
I think that if there were an Emacs key-binding-compatibility plug-in, the goal should be to make it as authentic as possible. The "two key combinations" (that is, using prefix keys) is an important component of the bindings. They actually hierarchically organize commands quite nicely. Any anyway, if Geany were to have Emacs bindings, I'm guessing that the point would probably be to allow current Emacs users to easily move between Emacs and Geany (thus it would be beneficial to be as similar as possible).
And when that works vi have all the vi (vim) users that like the same :-)
http://www.kubieziel.de/blog/archives/672-Editorwar.html ;)
(Even when it is in German it should understandable for everybody....)
Regards. Frank
On Sun, 18 Nov 2007 18:30:02 -0500, "John Gabriele" jmg3000@gmail.com wrote:
On Nov 18, 2007 5:43 PM, Bo Lorentsen bl@lue.dk wrote:
John Gabriele wrote:
Yes, I do think putting Geany's ease of use together with Emacs' key bindings would be a great combination. :)
Agreed ... do you have an idea to what kind of interface we may need to make these changed from an plugin ?
Nope. I haven't done anything yet with Geany's plug-in system. Actually, I've been holding out hope that someone writes a Python plug-in for it -- similar to Jeff's nice Lua plug-in. Nothing against
Sometime ago, I tried to write something like this. It is definitely possible but need some work. I ended up without any usuable results, if I have some time and some delight, maybe I will work on this again.
Regards, Enrico
On Sun, 18 Nov 2007 16:31:15 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Network: A friend of my have this nice idea of making a distributing editor environment where more than one person could work on the same file, while talking on the phone or using IM of a kind.
This is a completely different kind of applications with different needs and purposes. Furthermore, there are already a couple of projects to provide such apps. I'm not completely sure at the moment, but some time ago I read something about this and IIRC there were three well-known applications mentioned, but I don't remember the names, sorry.
There was an article at linux.user (a german Linux mag) in 9/2007 about a tool called gobby (1). I never tested it, but the article was really interesting and it seems that it's what Bo's friend is looking for :D
Frank
Frank Lanitz wrote:
There was an article at linux.user (a german Linux mag) in 9/2007 about a tool called gobby (1). I never tested it, but the article was really interesting and it seems that it's what Bo's friend is looking for :D
Ok, cool I will take a deeper look into this ... thanks.
/BL
Hi,
On Tue, 20 Nov 2007 17:07:38 +0100 Bo Lorentsen bl@lue.dk wrote:
Frank Lanitz wrote:
There was an article at linux.user (a german Linux mag) in 9/2007 about a tool called gobby (1). I never tested it, but the article was really interesting and it seems that it's what Bo's friend is looking for :D
Ok, cool I will take a deeper look into this ... thanks.
I reread the article again and there were also MateEdit and MoonEdit mentioned. But these seems to be dead according to the article.
Regards, Frank
Frank Lanitz wrote:
Hi,
On Tue, 20 Nov 2007 17:07:38 +0100 Bo Lorentsen bl@lue.dk wrote:
Frank Lanitz wrote:
There was an article at linux.user (a german Linux mag) in 9/2007 about a tool called gobby (1). I never tested it, but the article was really interesting and it seems that it's what Bo's friend is looking for :D
Ok, cool I will take a deeper look into this ... thanks.
I reread the article again and there were also MateEdit and MoonEdit mentioned. But these seems to be dead according to the article.
Yeps, but gobby really works, very nice idea :-)
I still like the idea that this functionality could be a Geany plugin, but gabby will be nice to test on first.
But thanks for your input.
/BL
Enrico Tröger wrote:
I guess John would be happy about an emacs keybinding plugin ;-). But yes, plugins should be able to define own keybindings or even be able to change existing ones. Just need to be implemented.
Ok, I will be looking forward to that kind of interface in the plugin API.
Project management is missing a discrete file list by design. We decided to not add a file list to the project object to keep it small and easy to use. Anyway, we wanted to add a file pattern option so that a general bunch of files could be added to the project. But as an alternative, the plugin API could get access to the project's config file and so plugins could maintain a file list for a project by themselves. Not sure about this.
Hmm, this would demand several implementations of the same file handling in each and every project plugin.
And, how about the sidebar ? Will a plugin the add a tab in the notebook in the sidebar, to integrate to Geany ?
This is a completely different kind of applications with different needs and purposes.
Ok ...
/BL
On Sun, 18 Nov 2007 23:31:13 +0100, Bo Lorentsen bl@lue.dk wrote:
Enrico Tröger wrote:
I guess John would be happy about an emacs keybinding plugin ;-). But yes, plugins should be able to define own keybindings or even be able to change existing ones. Just need to be implemented.
Ok, I will be looking forward to that kind of interface in the plugin API.
But be patient. There are some other things to do, too.
And, how about the sidebar ? Will a plugin the add a tab in the notebook in the sidebar, to integrate to Geany ?
See the filebrowser plugin, it does add a notebook tab in the sidebar.
Regards, Enrico
Enrico Tröger wrote:
And, how about the sidebar ? Will a plugin the add a tab in the notebook in the sidebar, to integrate to Geany ?
See the filebrowser plugin, it does add a notebook tab in the sidebar.
Ok, this is really nice ... I have not seen that. Not many excuses left for not making a cMake plugin :-)
"All we need then" is for the plugin interface to be called whenever a project is opened or closed, and that it gets a "handle" for the prober keyfile. That way it can persist all project relevant data in that file.
Are there plugin handles/hooks for things like a gdb or pydb ?
/BL
On Mon, 19 Nov 2007 20:33:01 +0100, Bo Lorentsen bl@lue.dk wrote:
Enrico Tröger wrote:
And, how about the sidebar ? Will a plugin the add a tab in the notebook in the sidebar, to integrate to Geany ?
See the filebrowser plugin, it does add a notebook tab in the sidebar.
Ok, this is really nice ... I have not seen that. Not many excuses left for not making a cMake plugin :-)
"All we need then" is for the plugin interface to be called whenever a project is opened or closed, and that it gets a "handle" for the
Ok, can be easily achieved by adding two signals for opening and closing, maybe a third one for project configuration.
prober keyfile. That way it can persist all project relevant data in that file.
It isn't really needed. There is no consistent handle for the project's keyfile while Geany is running. The file is only opened when the project is opened, configured or closed. Plugins already have access to the project's configuration file path. Maybe, when opening or closing a project, the used handle can be passed to the signal handler to minimize file access(i.e. the plugin doesn't have to open and write the configuration file again on project open/close).
Are there plugin handles/hooks for things like a gdb or pydb ?
Not sure what you mean with handles for gdb but there is nothing similar.
Regards, Enrico
Enrico Tröger wrote:
Ok, can be easily achieved by adding two signals for opening and closing, maybe a third one for project configuration.
That sounds awesome !
It isn't really needed. There is no consistent handle for the project's keyfile while Geany is running. The file is only opened when the project is opened, configured or closed. Plugins already have access to the project's configuration file path. Maybe, when opening or closing a project, the used handle can be passed to the signal handler to minimize file access(i.e. the plugin doesn't have to open and write the configuration file again on project open/close).
Passing a valid keyfile pointer when firing the signals would be a huge help, and a nice way of doing this.
Regarding configure signal, the plugin would not need to persist changes and it only need it to maintain internal states. When the project is closed it could save these in the keyfile, if needed.
Not sure what you mean with handles for gdb but there is nothing similar.
Hmm, I was juster wondering if the plugin interface could handle things like a thin debug wrapper.
/BL
On Tue, 20 Nov 2007 16:59:55 +0100, Bo Lorentsen bl@lue.dk wrote:
It isn't really needed. There is no consistent handle for the project's keyfile while Geany is running. The file is only opened when the project is opened, configured or closed. Plugins already have access to the project's configuration file path. Maybe, when opening or closing a project, the used handle can be passed to the signal handler to minimize file access(i.e. the plugin doesn't have to open and write the configuration file again on project open/close).
Passing a valid keyfile pointer when firing the signals would be a huge help, and a nice way of doing this.
I just added three signals: project-open, project-save and project-close. project-open and project-save submit the keyfile object which may be modified. Some basic documentation can be found at the top of src/plugindata.h, I'll write some more plugin documentation soon.
At the moment, I'm not completely sure whether it is save to pass the keyfile object when emitting the signal. It might be it can already be invalid(due to free()) in the signal handler although my tests worked fine. I just don't know for sure whether g_signal_emit emits the signal instantly and wait for all connected handlers to return or whether it returns before handlers are finished. In the latter case, the passed keyfile object may become invalid because after the signal(e.g. project-open) is emitted, the keyfile object is freed.
Regards, Enrico
Enrico Tröger wrote:
I just added three signals: project-open, project-save and project-close. project-open and project-save submit the keyfile object which may be modified. Some basic documentation can be found at the top of src/plugindata.h, I'll write some more plugin documentation soon.
Ok, that is nice ... lets see what that can bring :-)
At the moment, I'm not completely sure whether it is save to pass the keyfile object when emitting the signal. It might be it can already be invalid(due to free()) in the signal handler although my tests worked fine. I just don't know for sure whether g_signal_emit emits the signal instantly and wait for all connected handlers to return or whether it returns before handlers are finished. In the latter case, the passed keyfile object may become invalid because after the signal(e.g. project-open) is emitted, the keyfile object is freed.
I am no expert in GTK, but it seems like g_signal_emit is synchronous and passings along a pointer should not be a problem. Or have i misunderstood the problem ?
Will you open a keyfile and pass that on project-save ?
Anyway, I have what I need for now, now for some plugin code :-)
/BL
On Wed, 21 Nov 2007 21:32:49 +0100, Bo Lorentsen bl@lue.dk wrote:
At the moment, I'm not completely sure whether it is save to pass the keyfile object when emitting the signal. It might be it can already be invalid(due to free()) in the signal handler although my tests worked fine. I just don't know for sure whether g_signal_emit emits the signal instantly and wait for all connected handlers to return or whether it returns before handlers are finished. In the latter case, the passed keyfile object may become invalid because after the signal(e.g. project-open) is emitted, the keyfile object is freed.
I am no expert in GTK, but it seems like g_signal_emit is synchronous and passings along a pointer should not be a problem. Or have i
Probably, I just wanted to mention I'm not completely sure and when anyone experience problems at this point, this could be a reason.
Will you open a keyfile and pass that on project-save ?
Yes, the keyfile is created and the project's config file is written into the keyfile object, then the new project settings are written to the keyfile object and then the project-save signal is emitted with this keyfile object. When all signal handlers returned, the keyfile object is written to disk.
Anyway, I have what I need for now, now for some plugin code :-)
Hehe, so go ahead and surprise us ;-).
Regards, Enrico
On Mon, 26 Nov 2007 13:53:43 +0100, Frank Lanitz linux@partysoke.de wrote:
Hi,
On Mon, 19 Nov 2007 20:33:01 +0100 Bo Lorentsen bl@lue.dk wrote:
Ok, this is really nice ... I have not seen that. Not many excuses left for not making a cMake plugin :-)
This would be a real great thing. Could it also support the autotools?
Why should a cmake plugin support autotools? Why making the things bad again? ;-)
SCNR, Enrico
Enrico Tröger wrote:
On Mon, 26 Nov 2007 13:53:43 +0100, Frank Lanitz linux@partysoke.de wrote:
Hi,
On Mon, 19 Nov 2007 20:33:01 +0100 Bo Lorentsen bl@lue.dk wrote:
Ok, this is really nice ... I have not seen that. Not many excuses left for not making a cMake plugin :-)
This would be a real great thing. Could it also support the autotools?
Why should a cmake plugin support autotools? Why making the things bad again? ;-)
I agree, Anjuta has nice autotools support so please use that. I have some ideas to make this simple and useful and I like to keep it small :-)
/BL
On Tue, 27 Nov 2007 16:46:05 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Why should a cmake plugin support autotools? Why making the things bad again? ;-)
Should I ask for smake support instead? :D
Frank
On Nov 18, 2007 5:23 AM, Bo Lorentsen bl@lue.dk wrote:
If the plugin interface could handle key strokes, code insertion handles, and be able to work directly inside the text buffer, this should be do able from a plugin really soon. Maybe the plugin should be able to take over the key stroke table ? It would be nice to see this as a Lua script too.
I just added a "development snapshot" link on the geanylua page.
The new version supports assigning custom keybindings on a per-script basis.
Check the file "docs/geanylua-keys.html" for more info...
- Jeff
On Tue, 20 Nov 2007 03:50:15 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Nov 18, 2007 5:23 AM, Bo Lorentsen bl@lue.dk wrote:
If the plugin interface could handle key strokes, code insertion handles, and be able to work directly inside the text buffer, this should be do able from a plugin really soon. Maybe the plugin should be able to take over the key stroke table ? It would be nice to see this as a Lua script too.
I just added a "development snapshot" link on the geanylua page.
The new version supports assigning custom keybindings on a per-script basis.
Check the file "docs/geanylua-keys.html" for more info...
Nice. Basically, all plugins can assign already keybindings for themselves but they need to connect to the main window's key-press-event and add a handler which catches the event. And in this way, there is no way to prevent conflicting keybindings with Geany's (as Jeff already mentioned in the geanylua docs). We will add some interface to the plugin API which allows plugins to assign keybindings and detect conflicts with Geany's keybindings.
Regards, Enrico
On Tue, 20 Nov 2007 17:15:04 +0100, Bo Lorentsen bl@lue.dk wrote:
Jeff Pohlmeyer wrote:
I just added a "development snapshot" link on the geanylua page.
I don't quite understand why the lua plugin is not part of geany ? What is the reason ?
We can't and don't want to add any plugin into the Geany SVN tree. This doesn't mean we don't like Jeff's plugin or don't appreciate his great work. It's just the first external plugins. The other plugins, which are shipped with Geany are just maintained inside the SVN because we (the Geany developers) have written them.
Should we create an extra SVN repository to give all plugin authors access?
Regards, Enrico
On Tue, 20 Nov 2007 17:27:33 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Should we create an extra SVN repository to give all plugin authors access?
Would be a great thing.
Frank