Hi,
I'm sending my stack of patches against geany again, this time as individual patches. Here's the full list:
[PATCH 01/19] Prevent -Wmissing-prototypes report warning when compiling a plugin [PATCH 02/19] Add signals for project options dialog opening and closing [PATCH 03/19] Make the project menu accessible by plugins [PATCH 04/19] Make it possible to change project patterns by plugins [PATCH 05/19] Don't be annoying when not necessary [PATCH 06/19] Make it possible for plugins to change the base directory of msgwindow [PATCH 07/19] Open the file in the msgwindow even if no linenumber is specified [PATCH 08/19] When closing tab, return to the document at the top of the MRU list [PATCH 09/19] Use wider entry for project file path [PATCH 10/19] New utils function to get relative path from one directory to another [PATCH 11/19] File name in the project settings dialog shouldn't look it is editable [PATCH 12/19] Use relative paths in the project files [PATCH 13/19] Remove the "set" button from the project properties dialog [PATCH 14/19] Rewrite tab switching queue [PATCH 15/19] Do not insert --include= when the search pattern entry is empty [PATCH 16/19] Use project patterns in the FIF dialog [PATCH 17/19] Make the tab switching dialog a bit more useful [PATCH 18/19] Use standard include paths for "open selected file" [PATCH 19/19] Use per document indent sizes
Only some of them are required by gproject - others are just suggestions for improvements. I didn't explicitly distinguish between these two types of patches but it should be pretty clear from the description. There have been some minor changes since my last post - mainly the change of the FIF dialog to contain combo box for pattern selection and there are also some new patches - the detailed description is in the individual emails. Of course many of the patches are suggestions only so further discussion is welcome.
Cheers,
Jiri
Signed-off-by: Jiří Techet techet@gmail.com --- src/plugindata.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
On Thu, 5 Aug 2010 01:59:35 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
This has been committed to svn. Thank you very much.
Thanks, Frank
These signals can be used by plugins to add their settings tab and read the settings when the user presses OK. The code had to be reorganized slightly because first project-dialog-confirmed has to be emitted (so the plugin can read the settings) and project-save afterwards.
Signed-off-by: Jiří Techet techet@gmail.com --- doc/pluginsignals.c | 19 +++++++++++++++++++ src/geanyobject.c | 18 ++++++++++++++++++ src/geanyobject.h | 4 ++++ src/project.c | 14 +++++++++----- 4 files changed, 50 insertions(+), 5 deletions(-)
Not really a hard requirement but since the project plugin settings can now be also integrated to the project settings dialog, it looks strange when the project-related items are in the Tools menu.
Signed-off-by: Jiří Techet techet@gmail.com --- src/main.c | 1 + src/ui_utils.h | 1 + 2 files changed, 2 insertions(+), 0 deletions(-)
Plugins can override project patterns. In that case the "file patterns" field is made inactive in the Project tab of the project properties dialog.
Signed-off-by: Jiří Techet techet@gmail.com --- plugins/geanyfunctions.h | 2 + src/plugindata.h | 9 +++++++ src/plugins.c | 8 +++++- src/project.c | 57 +++++++++++++++++++++++++++++---------------- src/project.h | 1 + 5 files changed, 56 insertions(+), 21 deletions(-)
When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified.
Signed-off-by: Jiří Techet techet@gmail.com --- src/callbacks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
Jiří Techet wrote:
When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified.
I've been running with this patch for about a week. Looks good to me.
Cheers, Erik
Hi,
Le 16/08/2010 02:51, Erik de Castro Lopo a écrit :
Jiří Techet wrote:
When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified.
I've been running with this patch for about a week. Looks good to me.
This one seems to have been applied as r5190, and I have a little complain about it, so perhaps it would need a little more thought.
The problem is that reloading a document not only looses unsaved changes, but also undo/redo stack. This is particularly annoying if you hit the shortcut by accident (which I unfortunately did :( ). So I propose to two possible solutions: 1) simply check whether there's possible undo/redo, and if yes, ask before reloading (little patch joined); 2) the solution 1 fixes my problem, but probably not (?) for somebody that was annoyed by this dialog like Jiří was. So, perhaps a... setting (!) would be useful?
What do you think?
Regards, Colomban
Colomban Wendling wrote:
This one seems to have been applied as r5190, and I have a little complain about it, so perhaps it would need a little more thought.
The problem is that reloading a document not only looses unsaved changes, but also undo/redo stack. This is particularly annoying if you hit the shortcut by accident (which I unfortunately did :( ). So I propose to two possible solutions:
- simply check whether there's possible undo/redo, and if yes, ask
before reloading (little patch joined);
That seems sensible to me.
- the solution 1 fixes my problem, but probably not (?) for somebody
that was annoyed by this dialog like Jiří was. So, perhaps a... setting (!) would be useful?
Yep, and 'Always prompt on reload' option might be useful.
On a related note, I'm working on an LLVM backend for a compiler and quote often I with have the generated LLVM code in a tab to check how my code generation is going. Once loaded, I never change it, however when the code changes on disk, I would like the tab to automatically reload the version on disk.
I was thinking for this case, it the file has no changes, is marked as read-only in geany, it would be sensible to automatically reload it when in changes on disk. Does that sound sane to people?
Another alternative would be to have a mode that is like the current read-only mode, but is called view mode that is like a read only mode but with automatic reload from disk.
Thoughts?
Erik
On Thu, 16 Sep 2010 07:54:12 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Another alternative would be to have a mode that is like the current read-only mode, but is called view mode that is like a read only mode but with automatic reload from disk.
I haev a similar situation, but I prefer the explicit reloading as a way of seeing the changes. That said, an explicit tracking mode could be very useful and I'm sure that I'd get used to it soon enough!
Jon
On Wed, Sep 15, 2010 at 23:15, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Le 16/08/2010 02:51, Erik de Castro Lopo a écrit :
Jiří Techet wrote:
When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified.
I've been running with this patch for about a week. Looks good to me.
This one seems to have been applied as r5190, and I have a little complain about it, so perhaps it would need a little more thought.
The problem is that reloading a document not only looses unsaved changes, but also undo/redo stack. This is particularly annoying if you hit the shortcut by accident (which I unfortunately did :( ). So I propose to two possible solutions:
- simply check whether there's possible undo/redo, and if yes, ask
before reloading (little patch joined); 2) the solution 1 fixes my problem, but probably not (?) for somebody that was annoyed by this dialog like Jiří was. So, perhaps a... setting (!) would be useful?
(1) is OK with me. The moment when I found the previous behaviour annoying was when I created a new project, opened several files and then realized that the indent indent size in the project settings was different than the actual indents in the files. I modified the project settings but the open files had to be reloaded in order to get the new indent settings.
The patch was meant to fix this little annoyance I had with confirming the dialog in a trivial way but if it's causing troubles in other situations, it's OK with me if the patch is reverted. The above situation is not something I run into every day.
Jiri
What do you think?
Regards, Colomban
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 15 Sep 2010 23:15:05 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified.
I've been running with this patch for about a week. Looks good to me.
This one seems to have been applied as r5190, and I have a little complain about it, so perhaps it would need a little more thought.
The problem is that reloading a document not only looses unsaved changes, but also undo/redo stack. This is particularly annoying if you hit the shortcut by accident (which I unfortunately did :( ). So I propose to two possible solutions:
- simply check whether there's possible undo/redo, and if yes, ask
before reloading (little patch joined); 2) the solution 1 fixes my problem, but probably not (?) for somebody that was annoyed by this dialog like Jiří was. So, perhaps a... setting (!) would be useful?
Applied, thanks. As Jiří said the patch was OK for him I think there's no need for a pref.
Regards, Nick
Plugins might want to open file relatively to certain directory so make it possible by this patch.
Signed-off-by: Jiří Techet techet@gmail.com --- plugins/geanyfunctions.h | 2 ++ src/msgwindow.c | 23 +++++++++++++++++++---- src/msgwindow.h | 4 +++- src/plugindata.h | 1 + src/plugins.c | 3 ++- src/search.c | 3 +-- 6 files changed, 28 insertions(+), 8 deletions(-)
Plugins may need to open a file from the message window without specifying the line number (e.g. gproject has the feature "find project file"). In addition to the original behaviour this patch makes it possible to open files when the message is of the form
filename(:[whatever])*
so for instance
/home/techet/geany/foo.c /home/techet/geany/foo.c: this the file you were searching for
are both valid and the file is opened when the message is clicked.
Signed-off-by: Jiří Techet techet@gmail.com --- src/msgwindow.c | 33 +++++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-)
This is a pretty frequent work pattern of mine:
1. Editing file A 2. Searching for function and opening file B 3. Closing file B because I just wanted to look at the function definition 4. Without this patch I get to the file following the B's tab (which is just a random file) but my brain expects that I get to A
I know it's possible to kind of simulate the behaviour I want with the "next to current" placement option but I really don't see a single advantage of having tabs closed in sequential order. This is also why I didn't make this behaviour optional. But maybe I miss some use case of tabs being closed sequentially - just tell me.
Signed-off-by: Jiří Techet techet@gmail.com --- src/keybindings.c | 10 ++++++++++ src/notebook.c | 9 --------- 2 files changed, 10 insertions(+), 9 deletions(-)
Jiří Techet wrote:
This is a pretty frequent work pattern of mine:
- Editing file A
- Searching for function and opening file B
- Closing file B because I just wanted to look at the function definition
- Without this patch I get to the file following the B's tab (which
is just a random file) but my brain expects that I get to A
I know it's possible to kind of simulate the behaviour I want with the "next to current" placement option but I really don't see a single advantage of having tabs closed in sequential order. This is also why I didn't make this behaviour optional. But maybe I miss some use case of tabs being closed sequentially - just tell me.
I like this patch. It seems logical to me.
I have another thing to add on top of this.
When closing the last tab, I feel is a bit weird to have a huge window in the colour of the Gtk menu background. The attached patch detects the closing of the last tab and immediately creates a new Untitled tab.
I haven't tested it, but I'm pretty sure my patch depends on Jiří's patch:
0008-When-closing-tab-return-to-the-document-at-the-top-o.patch
Cheers, Erik
30 is too little. For instance
/home/techet/projects/geany/geany.geany
is 39 characters long and this is really short path. I find 50 characters to be about minimal usable size so users do not have to scroll inside the edit box too often. --- src/project.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
On Thu, 5 Aug 2010 01:59:43 +0200 Jiří Techet techet@gmail.com wrote:
30 is too little. For instance
/home/techet/projects/geany/geany.geany
is 39 characters long and this is really short path. I find 50 characters to be about minimal usable size so users do not have to scroll inside the edit box too often.
50 makes the dialog seem too wide IMO. The user can stretch the dialog as well as scroll the entry. I don't like forcing the entry to be at least 50 characters wide, I wouldn't mind so much if it displays as 50 so long as the screen can take it, but could be reduced by GTK or the user if necessary.
Regards, Nick
On Tue, Aug 24, 2010 at 13:57, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 5 Aug 2010 01:59:43 +0200 Jiří Techet techet@gmail.com wrote:
30 is too little. For instance
/home/techet/projects/geany/geany.geany
is 39 characters long and this is really short path. I find 50 characters to be about minimal usable size so users do not have to scroll inside the edit box too often.
50 makes the dialog seem too wide IMO. The user can stretch the dialog as well as scroll the entry. I don't like forcing the entry to be at least 50 characters wide, I wouldn't mind so much if it displays as 50 so long as the screen can take it, but could be reduced by GTK or the user if necessary.
I agree the dialog looks better with not so wide entries, on the other hand I *always* have to scroll the entry to be able to edit the path at the end. But I don't care so much about the future of this patch, it's just a minor usability problem I have noticed.
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
This is used by the patch that writes relative paths to the project file. I put it to utils because I use it in gproject as well and might be useful for others.
Signed-off-by: Jiří Techet techet@gmail.com --- plugins/geanyfunctions.h | 2 ++ src/plugindata.h | 2 +- src/plugins.c | 3 ++- src/utils.c | 41 +++++++++++++++++++++++++++++++++++++++++ src/utils.h | 2 ++ 5 files changed, 48 insertions(+), 2 deletions(-)
2010/8/5 Jiří Techet techet@gmail.com:
This is used by the patch that writes relative paths to the project file. I put it to utils because I use it in gproject as well and might be useful for others.
Signed-off-by: Jiří Techet techet@gmail.com
plugins/geanyfunctions.h | 2 ++ src/plugindata.h | 2 +- src/plugins.c | 3 ++- src/utils.c | 41 +++++++++++++++++++++++++++++++++++++++++ src/utils.h | 2 ++ 5 files changed, 48 insertions(+), 2 deletions(-)
Ah, this patch is leaky as hell. Please use the attached patch instead.
Jiri
Use selectable GtkLabel so it's possible to copy the file name but it is immediatelly clear that it cannot be edited.
Signed-off-by: Jiří Techet techet@gmail.com --- src/project.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Use selectable GtkLabel so it's possible to copy the file name but it is immediatelly clear that it cannot be edited.
Although I can't see any use for it, why can't the name be editable? There is no rule that says it has to be the same as the filename.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/project.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Aug 5, 2010 at 04:54, Lex Trotman elextr@gmail.com wrote:
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Use selectable GtkLabel so it's possible to copy the file name but it is immediatelly clear that it cannot be edited.
Although I can't see any use for it, why can't the name be editable? There is no rule that says it has to be the same as the filename.
No, you misread what the patch does. The name remains editable - the thing that shouldn't *look* it is editable is the *filename*.
Cheers,
Jiri
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/project.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 5 August 2010 18:56, Jiří Techet techet@gmail.com wrote:
On Thu, Aug 5, 2010 at 04:54, Lex Trotman elextr@gmail.com wrote:
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Use selectable GtkLabel so it's possible to copy the file name but it is immediatelly clear that it cannot be edited.
Although I can't see any use for it, why can't the name be editable? There is no rule that says it has to be the same as the filename.
No, you misread what the patch does. The name remains editable - the thing that shouldn't *look* it is editable is the *filename*.
Oh, Ok, that makes sense.
Cheers Lex
Cheers,
Jiri
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/project.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Right now projects cannot be moved to other directories without losing the base directory setting of the project and the list of open files. This makes the project totally unportable to different machines because even if the directory structure under your home is identical, the user name can be different so the path is different too.
The paths should be relative to the project file, which is what every other IDE I know does. If you keep the project file in the same relative path to the project files, you can move it wherever you want.
This patch does this in a backwards-compatible way - when the path in the project settings file is absolute, it uses the absoulte path. However, when the project is saved, all paths are converted to relative. This means that all new applications will be able to read the old project definition files but the old applications won't read the new files (or more precisely, the paths in them).
For the global session file absolute paths are still used mainly because in Windows you cannot create a relative path to a different volume and the global settings file can be at a volume different from the project dir. (I don't expect anyone has the project definition file at different volume than the project files so this shouldn't be an issue for projects).
As Dimitar suggested, absolute paths could be used for files outside the base directory which makes sense because the paths outside the project would be preserved even if the project moves somewhere else. This feature can be included depending on the further discussion.
One more possibility is to add a settings option (either per project or global) that determines what kind of paths should be used.
Signed-off-by: Jiří Techet techet@gmail.com --- src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Right now projects cannot be moved to other directories without losing the base directory setting of the project and the list of open files. This makes the project totally unportable to different machines because even if the directory structure under your home is identical, the user name can be different so the path is different too.
The paths should be relative to the project file, which is what every other IDE I know does. If you keep the project file in the same relative path to the project files, you can move it wherever you want.
This patch does this in a backwards-compatible way - when the path in the project settings file is absolute, it uses the absoulte path. However, when the project is saved, all paths are converted to relative. This means that all new applications will be able to read the old project definition files but the old applications won't read the new files (or more precisely, the paths in them).
For the global session file absolute paths are still used mainly because in Windows you cannot create a relative path to a different volume and the global settings file can be at a volume different from the project dir. (I don't expect anyone has the project definition file at different volume than the project files so this shouldn't be an issue for projects).
As Dimitar suggested, absolute paths could be used for files outside the base directory which makes sense because the paths outside the project would be preserved even if the project moves somewhere else. This feature can be included depending on the further discussion.
One more possibility is to add a settings option (either per project or global) that determines what kind of paths should be used.
Hi Jiri,
If I understand correctly this patch depends on the project file being in the project tree, but that is not the Geany default. Some people don't like storing the project file in the project tree because it contains an individual users session files and these shouldn't be in a version controlled tree, imagine if you did a git commit -a.
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Aug 5, 2010 at 04:48, Lex Trotman elextr@gmail.com wrote:
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Right now projects cannot be moved to other directories without losing the base directory setting of the project and the list of open files. This makes the project totally unportable to different machines because even if the directory structure under your home is identical, the user name can be different so the path is different too.
The paths should be relative to the project file, which is what every other IDE I know does. If you keep the project file in the same relative path to the project files, you can move it wherever you want.
This patch does this in a backwards-compatible way - when the path in the project settings file is absolute, it uses the absoulte path. However, when the project is saved, all paths are converted to relative. This means that all new applications will be able to read the old project definition files but the old applications won't read the new files (or more precisely, the paths in them).
For the global session file absolute paths are still used mainly because in Windows you cannot create a relative path to a different volume and the global settings file can be at a volume different from the project dir. (I don't expect anyone has the project definition file at different volume than the project files so this shouldn't be an issue for projects).
As Dimitar suggested, absolute paths could be used for files outside the base directory which makes sense because the paths outside the project would be preserved even if the project moves somewhere else. This feature can be included depending on the further discussion.
One more possibility is to add a settings option (either per project or global) that determines what kind of paths should be used.
Hi Jiri,
If I understand correctly this patch depends on the project file being in the project tree, but that is not the Geany default. Some people don't like storing the project file in the project tree because it contains an individual users session files and these shouldn't be in a version controlled tree, imagine if you did a git commit -a.
Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
Another example:
the project directory is in: ~/projects/bar and the project file under: ~/project_files/baz/bar.geany then bar.geany refers to files as: ../../projects/bar
The only problem might be under Windows if you store the project file on different volume than the project directory - then you cannot construct the relative path but I think nobody would do that. And of course you should move project files so that the relative path against the project file and the project directory remains unchanged. This would work well if you have:
~/projects/foo.geany ~/projects/bar.geany ~/projects/baz.geany ~/projects/foo ~/projects/bar ~/projects/baz
which is something geany defaults to with having project file one directory above the project directory. (In this case without the patch if you rename "projects" to something else, all the paths get broken but they remain preserved with my patch applied.)
That said, I'm not against making this behavior optional - depends on what others think.
Cheers,
Jiri
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 5 August 2010 19:13, Jiří Techet techet@gmail.com wrote:
On Thu, Aug 5, 2010 at 04:48, Lex Trotman elextr@gmail.com wrote:
On 5 August 2010 09:59, Jiří Techet techet@gmail.com wrote:
Right now projects cannot be moved to other directories without losing the base directory setting of the project and the list of open files. This makes the project totally unportable to different machines because even if the directory structure under your home is identical, the user name can be different so the path is different too.
The paths should be relative to the project file, which is what every other IDE I know does. If you keep the project file in the same relative path to the project files, you can move it wherever you want.
This patch does this in a backwards-compatible way - when the path in the project settings file is absolute, it uses the absoulte path. However, when the project is saved, all paths are converted to relative. This means that all new applications will be able to read the old project definition files but the old applications won't read the new files (or more precisely, the paths in them).
For the global session file absolute paths are still used mainly because in Windows you cannot create a relative path to a different volume and the global settings file can be at a volume different from the project dir. (I don't expect anyone has the project definition file at different volume than the project files so this shouldn't be an issue for projects).
As Dimitar suggested, absolute paths could be used for files outside the base directory which makes sense because the paths outside the project would be preserved even if the project moves somewhere else. This feature can be included depending on the further discussion.
One more possibility is to add a settings option (either per project or global) that determines what kind of paths should be used.
Hi Jiri,
If I understand correctly this patch depends on the project file being in the project tree, but that is not the Geany default. Some people don't like storing the project file in the project tree because it contains an individual users session files and these shouldn't be in a version controlled tree, imagine if you did a git commit -a.
Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
But then how does it work when I move projects/foo somewhere, foo.geany is again disconnected. Thats why I suggested that the project file had to move with the project tree so the relative addresses kept working.
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Cheers Lex
Another example:
the project directory is in: ~/projects/bar and the project file under: ~/project_files/baz/bar.geany then bar.geany refers to files as: ../../projects/bar
The only problem might be under Windows if you store the project file on different volume than the project directory - then you cannot construct the relative path but I think nobody would do that. And of course you should move project files so that the relative path against the project file and the project directory remains unchanged. This would work well if you have:
~/projects/foo.geany ~/projects/bar.geany ~/projects/baz.geany ~/projects/foo ~/projects/bar ~/projects/baz
which is something geany defaults to with having project file one directory above the project directory. (In this case without the patch if you rename "projects" to something else, all the paths get broken but they remain preserved with my patch applied.)
That said, I'm not against making this behavior optional - depends on what others think.
Cheers,
Jiri
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 05.08.2010 11:28, schrieb Lex Trotman:
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Cheers Lex
I also think that'd make probably more sense.
Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
But then how does it work when I move projects/foo somewhere, foo.geany is again disconnected. Thats why I suggested that the project file had to move with the project tree so the relative addresses kept working.
Yes, that's true. Clearly both ways of doing it have some advantages and some disadvantages. The disadvantage of your solution is that the thing like renaming the projects directory I mentioned in my last example wouldn't work. For me, relative paths are better (I can move the project to different accounts with different home directory and directory structure) but I can imagine that for someone who often moves the project file relatively to the project directory, absolute paths are better. But is the latter really common real-life use case scenario? If so, a configuration option should be introduced.
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Sure, can be done, but this won't do what you expect would happen. Why:
1. Move the project file so the paths become invalid. 2. Load the project (none of the files opens because the paths are invalid) 3. Edit the base directory. 4. Save the project file - this saves all the open documents but because there are none of them open, it just clears the list in the project file.
This would only work if you edit the project file manually before you open it.
Cheers,
Jiri
Cheers Lex
Another example:
the project directory is in: ~/projects/bar and the project file under: ~/project_files/baz/bar.geany then bar.geany refers to files as: ../../projects/bar
The only problem might be under Windows if you store the project file on different volume than the project directory - then you cannot construct the relative path but I think nobody would do that. And of course you should move project files so that the relative path against the project file and the project directory remains unchanged. This would work well if you have:
~/projects/foo.geany ~/projects/bar.geany ~/projects/baz.geany ~/projects/foo ~/projects/bar ~/projects/baz
which is something geany defaults to with having project file one directory above the project directory. (In this case without the patch if you rename "projects" to something else, all the paths get broken but they remain preserved with my patch applied.)
That said, I'm not against making this behavior optional - depends on what others think.
Cheers,
Jiri
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 5 August 2010 21:20, Jiří Techet techet@gmail.com wrote:
Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
But then how does it work when I move projects/foo somewhere, foo.geany is again disconnected. Thats why I suggested that the project file had to move with the project tree so the relative addresses kept working.
Yes, that's true. Clearly both ways of doing it have some advantages and some disadvantages. The disadvantage of your solution is that the thing like renaming the projects directory I mentioned in my last example wouldn't work. For me, relative paths are better (I can move the project to different accounts with different home directory and directory structure) but I can imagine that for someone who often moves the project file relatively to the project directory, absolute paths are better. But is the latter really common real-life use case scenario? If so, a configuration option should be introduced.
Oh, I agree that relative paths with everything in the project tree are fine.
And I want to be able to move project trees, its quite common, so I am happy you are trying to fix the problem.
But for the reasons given previously I don't keep the project file in the tree. Therefore all moves or renames of project directories break the project file irrespective of absolute or relative paths.
And the Geany default is to keep the project file out of the tree.
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Sure, can be done, but this won't do what you expect would happen. Why:
- Move the project file so the paths become invalid.
- Load the project (none of the files opens because the paths are invalid)
- Edit the base directory.
- Save the project file - this saves all the open documents but
because there are none of them open, it just clears the list in the project file.
This would only work if you edit the project file manually before you open it.
True it would need to re-try the file list after the edit of the base directory, maybe a reload files tick box on the project properties? The file list should not have been overwritten at this stage.
Cheers Lex
Cheers,
Jiri
Cheers Lex
Another example:
the project directory is in: ~/projects/bar and the project file under: ~/project_files/baz/bar.geany then bar.geany refers to files as: ../../projects/bar
The only problem might be under Windows if you store the project file on different volume than the project directory - then you cannot construct the relative path but I think nobody would do that. And of course you should move project files so that the relative path against the project file and the project directory remains unchanged. This would work well if you have:
~/projects/foo.geany ~/projects/bar.geany ~/projects/baz.geany ~/projects/foo ~/projects/bar ~/projects/baz
which is something geany defaults to with having project file one directory above the project directory. (In this case without the patch if you rename "projects" to something else, all the paths get broken but they remain preserved with my patch applied.)
That said, I'm not against making this behavior optional - depends on what others think.
Cheers,
Jiri
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Aug 5, 2010 at 13:50, Lex Trotman elextr@gmail.com wrote:
On 5 August 2010 21:20, Jiří Techet techet@gmail.com wrote:
Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
But then how does it work when I move projects/foo somewhere, foo.geany is again disconnected. Thats why I suggested that the project file had to move with the project tree so the relative addresses kept working.
Yes, that's true. Clearly both ways of doing it have some advantages and some disadvantages. The disadvantage of your solution is that the thing like renaming the projects directory I mentioned in my last example wouldn't work. For me, relative paths are better (I can move the project to different accounts with different home directory and directory structure) but I can imagine that for someone who often moves the project file relatively to the project directory, absolute paths are better. But is the latter really common real-life use case scenario? If so, a configuration option should be introduced.
Oh, I agree that relative paths with everything in the project tree are fine.
And I want to be able to move project trees, its quite common, so I am happy you are trying to fix the problem.
But for the reasons given previously I don't keep the project file in the tree. Therefore all moves or renames of project directories break the project file irrespective of absolute or relative paths.
And the Geany default is to keep the project file out of the tree.
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Sure, can be done, but this won't do what you expect would happen. Why:
- Move the project file so the paths become invalid.
- Load the project (none of the files opens because the paths are invalid)
- Edit the base directory.
- Save the project file - this saves all the open documents but
because there are none of them open, it just clears the list in the project file.
This would only work if you edit the project file manually before you open it.
True it would need to re-try the file list after the edit of the base directory, maybe a reload files tick box on the project properties? The file list should not have been overwritten at this stage.
I'm a bit worried about having too many special cases (like doing something else when the project file is outside the base directory, especially when it only fixes some problems but introduces another ones) and possibly doing unexpected things (users probably don't expect that files start opening when they edit project properties). So my current preference is:
1. Have relative paths as a global option (per-project option isn't probably needed because every person has usually only one preferred way of storing project files) 2. Use full paths for files outside of the project directory (relative paths couldn't be used for open files from other volumes) 3. Use full paths for the session file (already works this way) 4. Use relative paths against the project file (IMO using relative paths against the base directory doesn't solve anything and it's more logical to have all the relative paths against the file in which they are defined)
Cheers,
Jiri
Cheers Lex
I'm a bit worried about having too many special cases (like doing something else when the project file is outside the base directory, especially when it only fixes some problems but introduces another ones) and possibly doing unexpected things (users probably don't expect that files start opening when they edit project properties). So my current preference is:
- Have relative paths as a global option (per-project option isn't
probably needed because every person has usually only one preferred way of storing project files)
Ok
- Use full paths for files outside of the project directory (relative
paths couldn't be used for open files from other volumes)
Ok
- Use full paths for the session file (already works this way)
Ok
- Use relative paths against the project file (IMO using relative
paths against the base directory doesn't solve anything and it's more logical to have all the relative paths against the file in which they are defined)
Good points, neither is a really good solution, so I don't care which you do.
To maintain backward compatibility why not continue to save the absolute paths in [files] and save the relative paths in a separate group in the project file eg [files-relative]. And that way you will know which are relative paths without checking.
Cheers Lex
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, Aug 7, 2010 at 01:42, Lex Trotman elextr@gmail.com wrote:
I'm a bit worried about having too many special cases (like doing something else when the project file is outside the base directory, especially when it only fixes some problems but introduces another ones) and possibly doing unexpected things (users probably don't expect that files start opening when they edit project properties). So my current preference is:
- Have relative paths as a global option (per-project option isn't
probably needed because every person has usually only one preferred way of storing project files)
Ok
- Use full paths for files outside of the project directory (relative
paths couldn't be used for open files from other volumes)
Ok
- Use full paths for the session file (already works this way)
Ok
- Use relative paths against the project file (IMO using relative
paths against the base directory doesn't solve anything and it's more logical to have all the relative paths against the file in which they are defined)
Good points, neither is a really good solution, so I don't care which you do.
To maintain backward compatibility why not continue to save the absolute paths in [files] and save the relative paths in a separate group in the project file eg [files-relative]. And that way you will know which are relative paths without checking.
That's a very good idea! Saving both relative and absolute path for each file (and base directory) would solve all the problems we have. First the absolute paths would be checked and if not successful, the relative paths would be used. There is some redundancy but this would make all the problems disappear so I think it's worth it.
Cheers,
Jiri
Cheers Lex
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
On Thu, Aug 5, 2010 at 04:48, Lex Trotman elextr@gmail.com wrote:
If I understand correctly this patch depends on the project file being in the project tree, but that is not the Geany default. Some people don't like storing the project file in the project tree because it contains an individual users session files and these shouldn't be in a version controlled tree, imagine if you did a git commit -a.
`git commit -a` isn't a problem since it commits all changes, but only to tracked files. `git add .` OTOH may be a problem, but as it is generally run at the very beginning of a project, the Geany project file is likely not to exist yet I think.
Keeping the .geany project file in the project tree is at least what I personally do, and without any harm.
On 5 August 2010 11:13, Jiří Techet techet@gmail.com wrote:
That said, I'm not against making this behavior optional - depends on what others think.
I definitely like the feature! (I even though to implement it a while ago, but I wasn't probably bothered enough to actually do it...)
Regards, Colomban
Unless I miss something the button just adds %d to the corresponding fields, but this is already the default settings so I don't see any point of doing it. --- src/build.c | 12 ------------ src/build.h | 2 -- src/project.c | 31 ++++--------------------------- 3 files changed, 4 insertions(+), 41 deletions(-)
Hi,
This got committed, but actually the button did set "%p" (not %d) to the directory in which execute non-filetype commands (like make). This is useful for anybody with a basedir-only build system (non-recursive autotools, handmade Makefiles, Waf, plenty of others), so I think providing an easy way to set this is useful.
Commit is 9add067c040b23753d982688eb19fee932437301
What do you think?
Le 05/08/2010 01:59, Jiří Techet a écrit :
Unless I miss something the button just adds %d to the corresponding fields, but this is already the default settings so I don't see any point of doing it.
src/build.c | 12 ------------ src/build.h | 2 -- src/project.c | 31 ++++--------------------------- 3 files changed, 4 insertions(+), 41 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 06/10/2012 17:25, Colomban Wendling wrote:
Hi,
This got committed, but actually the button did set "%p" (not %d) to the directory in which execute non-filetype commands (like make). This is
I was aware that it sets %p, not %d.
useful for anybody with a basedir-only build system (non-recursive autotools, handmade Makefiles, Waf, plenty of others), so I think providing an easy way to set this is useful.
Commit is 9add067c040b23753d982688eb19fee932437301
What do you think?
I had 2 reasons to remove it:
* It's bad UI design to have a button on one notebook page that silently affects fields on another notebook page. * It's quite easy to type %p, select it and middle-click paste it to any other fields desired.
I'm not against adding something like it, so long as it's on the Build page.
Regards, Nick
On 7 October 2012 04:39, Nick Treleaven nick.treleaven@btinternet.comwrote:
On 06/10/2012 17:25, Colomban Wendling wrote:
Hi,
This got committed, but actually the button did set "%p" (not %d) to the directory in which execute non-filetype commands (like make). This is
I was aware that it sets %p, not %d.
useful for anybody with a basedir-only build system (non-recursive
autotools, handmade Makefiles, Waf, plenty of others), so I think providing an easy way to set this is useful.
Commit is 9add067c040b23753d982688eb19fe**e932437301
What do you think?
I had 2 reasons to remove it:
- It's bad UI design to have a button on one notebook page that silently
affects fields on another notebook page.
- It's quite easy to type %p, select it and middle-click paste it to any
other fields desired.
I'm not against adding something like it, so long as it's on the Build page.
Regards, Nick
I agree with Nick to remove it, but I wouldn't move it anywhere.
I don't think we need it any more, IIRC it was just to allow a "one-click" setting that matched the way pre-0.19 project build settings worked. And who remembers pre-0.19?
Cheers Lex
______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 06/10/2012 19:39, Nick Treleaven a écrit :
On 06/10/2012 17:25, Colomban Wendling wrote:
Hi,
This got committed, but actually the button did set "%p" (not %d) to the directory in which execute non-filetype commands (like make). This is
I was aware that it sets %p, not %d.
OK, fine then; I wanted to check it wasn't a mistake since Jiří's original patch talked about %d.
useful for anybody with a basedir-only build system (non-recursive autotools, handmade Makefiles, Waf, plenty of others), so I think providing an easy way to set this is useful.
Commit is 9add067c040b23753d982688eb19fee932437301
What do you think?
I had 2 reasons to remove it:
- It's bad UI design to have a button on one notebook page that silently
affects fields on another notebook page.
Agreed, UI wasn't great.
- It's quite easy to type %p, select it and middle-click paste it to any
other fields desired.
OK, fair enough.
I'm not against adding something like it, so long as it's on the Build page.
Well, maybe we don't need any UI, as you said it's not hard to manually set. However, perhaps we should make it easier to discover the feature, or suggest user to use it, maybe ad a hint in the manual. I just think that it's a common enough use case to do something for "suggest" the way to go.
Regards, Colomban
There was one more bug related to the tab switching. When we switch so many times that we return back to the original document (so we actually don't switch at all) then the following switch attempt doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote the whole thing in a different way. The problem with the previous implementation was that before you couldn't just look what's in the queue "now" - you had to imagine what will be inserted there in the next step because the switch_in_progress variable was set after the first switch (this is also why I put the long comment why mru_pos = 2 - that is not clear at all when you first look at it). Also there were some not very nice "workarounds" like the idle function that was executed after the switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue starts with the current document and the previously opened documments follow. It's *always* like that, no exceptions. The idle function is gone and cb_func_switch_tablastused() is simplified too. The rest of the functionality should be clear from the code.
Signed-off-by: Jiří Techet techet@gmail.com --- src/keybindings.c | 65 +++++++++++++++++++++++----------------------------- 1 files changed, 29 insertions(+), 36 deletions(-)
On Thu, 5 Aug 2010 01:59:48 +0200 Jiří Techet techet@gmail.com wrote:
There was one more bug related to the tab switching. When we switch so many times that we return back to the original document (so we actually don't switch at all) then the following switch attempt doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote the whole thing in a different way. The problem with the previous implementation was that before you couldn't just look what's in the queue "now" - you had to imagine what will be inserted there in the next step because the switch_in_progress variable was set after the first switch (this is also why I put the long comment why mru_pos = 2 - that is not clear at all when you first look at it). Also there were some not very nice "workarounds" like the idle function that was executed after the switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue starts with the current document and the previously opened documments follow. It's *always* like that, no exceptions. The idle function is gone and cb_func_switch_tablastused() is simplified too. The rest of the functionality should be clear from the code.
Thanks, I'd like to commit this now. I realize it's been a while, but the patch doesn't apply cleanly and I can't see any commits since that would have caused conflicts. Any chance you could update and resubmit please?
Regards, Nick
On Tue, Sep 14, 2010 at 16:41, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 5 Aug 2010 01:59:48 +0200 Jiří Techet techet@gmail.com wrote:
There was one more bug related to the tab switching. When we switch so many times that we return back to the original document (so we actually don't switch at all) then the following switch attempt doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote the whole thing in a different way. The problem with the previous implementation was that before you couldn't just look what's in the queue "now" - you had to imagine what will be inserted there in the next step because the switch_in_progress variable was set after the first switch (this is also why I put the long comment why mru_pos = 2 - that is not clear at all when you first look at it). Also there were some not very nice "workarounds" like the idle function that was executed after the switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue starts with the current document and the previously opened documments follow. It's *always* like that, no exceptions. The idle function is gone and cb_func_switch_tablastused() is simplified too. The rest of the functionality should be clear from the code.
Thanks, I'd like to commit this now. I realize it's been a while, but the patch doesn't apply cleanly and I can't see any commits since that would have caused conflicts. Any chance you could update and resubmit please?
Hi Nick,
no problem, I have just rebased all my patches on top of mainline. This particular patch is attached. You can find the remaining pending patches under for_review3 branch here:
http://gitorious.org/~techy/geany/gproject-geany
If you wish me to resubmit them by email, just tell me - I would really like to see the patches extending geany's API to be a part of mainline so my gproject plugin would not depend on patched geany and could be moved among other plugins repository. By the way, the last commit in my tree performes indentation based on regex matching as I was proposing some time ago. I haven't published it yet because there are already quite many of my patches pending here and I want them to be reviewed first. Anyway, if you (or anyone else) are interested, you can have a look.
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
By the way, the last
commit in my tree performes indentation based on regex matching as I was proposing some time ago. I haven't published it yet because there are already quite many of my patches pending here and I want them to be reviewed first. Anyway, if you (or anyone else) are interested, you can have a look.
Hi Jiri,
I couldn't get this to work at all, it printed "calling indent this line" all the time but didn't indent :-(
I only had half an hour so I couldn't investigate much.
Cheers Lex
PS patch installed and compiled cleanly on yesterdays SVN head.
On Thu, 16 Sep 2010 10:23:41 +1000 Lex Trotman elextr@gmail.com wrote:
By the way, the last
commit in my tree performes indentation based on regex matching as I was proposing some time ago. I haven't published it yet because there are already quite many of my patches pending here and I want them to be reviewed first. Anyway, if you (or anyone else) are interested, you can have a look.
We're interested, I've thought for a while how this could be useful.
I couldn't get this to work at all, it printed "calling indent this line" all the time but didn't indent :-(
Regards, Nick
On 16.09.2010 02:23, Lex Trotman wrote:
Hi Jiri,
I couldn't get this to work at all, it printed "calling indent this line" all the time but didn't indent :-(
I only had half an hour so I couldn't investigate much.
I have the same experience. Auto-indentation doesn't seem to work anymore (e.g. when hitting enter after on a line that ends with {, or when typing }).
Best regards.
On Wed, 15 Sep 2010 21:34:52 +0200 Jiří Techet techet@gmail.com wrote:
Thanks, I'd like to commit this now. I realize it's been a while, but the patch doesn't apply cleanly and I can't see any commits since that would have caused conflicts. Any chance you could update and resubmit please?
Hi Nick,
no problem, I have just rebased all my patches on top of mainline. This particular patch is attached.
Thanks, but still no joy. The problem is these 2 hunks:
@@ -599,7 +599,7 @@ static void on_document_close(GObject *obj, GeanyDocument *doc) { GeanyDocument *last_doc;
last_doc = g_queue_peek_head(mru_docs);
last_doc = g_queue_peek_nth(mru_docs, 1);if (DOC_VALID(last_doc) && document_get_current() == doc) {
@@ -607,8 +607,10 @@ static void on_document_close(GObject *obj, GeanyDocument *doc) document_get_notebook_page(last_doc)); } g_queue_remove(mru_docs, doc);
g_idle_add(on_idle_close, NULL);
/* this prevents the pop up window from showing when there's a single* document */if (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)g_queue_clear(mru_docs);}
I haven't been able to work out where they apply to. It didn't seem that a conflict had been introduced since your first patch for this code, but maybe I'm missing something.
You can find the remaining pending patches under for_review3 branch here:
http://gitorious.org/~techy/geany/gproject-geany
If you wish me to resubmit them by email, just tell me - I would
Thanks - no need to resend. I can download the patches.
really like to see the patches extending geany's API to be a part of mainline so my gproject plugin would not depend on patched geany and could be moved among other plugins repository.
I've applied some this afternoon, will get through them soon hopefully.
Regards, Nick
On Thu, Sep 16, 2010 at 17:52, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Sep 2010 21:34:52 +0200 Jiří Techet techet@gmail.com wrote:
Thanks, I'd like to commit this now. I realize it's been a while, but the patch doesn't apply cleanly and I can't see any commits since that would have caused conflicts. Any chance you could update and resubmit please?
Hi Nick,
no problem, I have just rebased all my patches on top of mainline. This particular patch is attached.
Thanks, but still no joy. The problem is these 2 hunks:
@@ -599,7 +599,7 @@ static void on_document_close(GObject *obj, GeanyDocument *doc) { GeanyDocument *last_doc;
- last_doc = g_queue_peek_head(mru_docs);
- last_doc = g_queue_peek_nth(mru_docs, 1);
if (DOC_VALID(last_doc) && document_get_current() == doc) { @@ -607,8 +607,10 @@ static void on_document_close(GObject *obj, GeanyDocument *doc) document_get_notebook_page(last_doc)); } g_queue_remove(mru_docs, doc);
- g_idle_add(on_idle_close, NULL);
- /* this prevents the pop up window from showing when there's a single
- * document */
- if (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)
- g_queue_clear(mru_docs);
} }
I haven't been able to work out where they apply to. It didn't seem that a conflict had been introduced since your first patch for this code, but maybe I'm missing something.
I see, the patch depends on the "When closing tab, return to the document at the top of the MRU list" commit. This is actually a commit I'd really like to see in geany so even though I could make the patch independent of this commit, I would like both to be applied in which case their separation doesn't make sense.
Please see the attached files. First apply tab_closing.patch and then tab_switching.patch. Everything should apply cleanly now.
Jiri
You can find the remaining pending patches under for_review3 branch here:
http://gitorious.org/~techy/geany/gproject-geany
If you wish me to resubmit them by email, just tell me - I would
Thanks - no need to resend. I can download the patches.
really like to see the patches extending geany's API to be a part of mainline so my gproject plugin would not depend on patched geany and could be moved among other plugins repository.
I've applied some this afternoon, will get through them soon hopefully.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
As a result search in all files instead in no files --- src/search.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
On Thu, 5 Aug 2010 01:59:49 +0200 Jiří Techet techet@gmail.com wrote:
--- a/src/search.c +++ b/src/search.c @@ -1329,7 +1329,8 @@ static GString *get_grep_options(void) g_strstrip(settings.fif_files); tmp = g_string_new(settings.fif_files); do {} while (utils_string_replace_all(tmp, " ", " "));
g_string_prepend_c(tmp, ' ');
if (tmp->len != 0)g_string_prepend_c(tmp, ' ');
I implemented this differently to not process the block if the pattern is empty, which seems clearer.
Regards, Nick
User can now select what kind of file patterns should be used: all - all files are searched, project - project patterns are used, custom - manually entered custom patterns are used.
Signed-off-by: Jiří Techet techet@gmail.com --- src/search.c | 126 ++++++++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 92 insertions(+), 34 deletions(-)
Right now the tab switching dialog shows the full path of the current file. However this dialog is too narrow and in my case usually displays one directory per line. This makes it hard to find the base filename, which is the thing you are most probably looking for.
This patch displays only the base name - in bold. In addition, it displays the following three filenames in the MRU list, each on a new line (not in bold). This helps to see what file comes next and how many times one has to press ctrl+tab. --- src/keybindings.c | 34 ++++++++++++++++++++++++++++++---- 1 files changed, 30 insertions(+), 4 deletions(-)
Under linux, try to locate the file with the given name also under /usr/local/include and /usr/include. This feature is probably most often used for opening include files so this helps for the system ones.
Signed-off-by: Jiří Techet techet@gmail.com --- src/callbacks.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-)
Different documents may use different indent size and it's often necessary to have all of them opened in parallel and use the correct indent size for each of them.
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Right now the indent size is set from a submenu of the document menu. This can be changed to use dialog to set the indent size; also a combined approach is possible - display only the common sizes in the submenu (2, 4, 8) with "others" item that opens the dialog to set the more esoteric indent sizes.
Signed-off-by: Jiří Techet techet@gmail.com --- geany.glade | 150 ++++++++++++++++++++---- src/callbacks.c | 23 ++++- src/callbacks.h | 4 + src/document.c | 8 +- src/editor.c | 16 ++- src/editor.h | 3 + src/interface.c | 350 +++++++++++++++++++++++++++++++++++-------------------- src/keyfile.c | 2 +- src/ui_utils.c | 10 ++ 9 files changed, 406 insertions(+), 160 deletions(-)
Jiří Techet wrote:
Different documents may use different indent size and it's often necessary to have all of them opened in parallel and use the correct indent size for each of them.
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Right now the indent size is set from a submenu of the document menu. This can be changed to use dialog to set the indent size; also a combined approach is possible - display only the common sizes in the submenu (2, 4, 8) with "others" item that opens the dialog to set the more esoteric indent sizes.
I like this, but it uses gtk_menu_item_get_label() which according to this:
http://library.gnome.org/devel/gtk/unstable/GtkMenuItem.html#gtk-menu-item-g...
arrived in Gtk 2.16. Currently the configure script accepts gtk >= 2.8.
Cheers, Erik
On 6 August 2010 11:19, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Jiří Techet wrote:
Different documents may use different indent size and it's often necessary to have all of them opened in parallel and use the correct indent size for each of them.
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Right now the indent size is set from a submenu of the document menu. This can be changed to use dialog to set the indent size; also a combined approach is possible - display only the common sizes in the submenu (2, 4, 8) with "others" item that opens the dialog to set the more esoteric indent sizes.
I like this, but it uses gtk_menu_item_get_label() which according to this:
http://library.gnome.org/devel/gtk/unstable/GtkMenuItem.html#gtk-menu-item-g...
arrived in Gtk 2.16. Currently the configure script accepts gtk >= 2.8.
Cheers, Erik --
It should be possible to use ui_menu_item_get_text from ui_utils instead.
Cheers Lex
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, Aug 6, 2010 at 04:15, Lex Trotman elextr@gmail.com wrote:
On 6 August 2010 11:19, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Jiří Techet wrote:
Different documents may use different indent size and it's often necessary to have all of them opened in parallel and use the correct indent size for each of them.
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Right now the indent size is set from a submenu of the document menu. This can be changed to use dialog to set the indent size; also a combined approach is possible - display only the common sizes in the submenu (2, 4, 8) with "others" item that opens the dialog to set the more esoteric indent sizes.
I like this, but it uses gtk_menu_item_get_label() which according to this:
http://library.gnome.org/devel/gtk/unstable/GtkMenuItem.html#gtk-menu-item-g...
arrived in Gtk 2.16. Currently the configure script accepts gtk >= 2.8.
Ah, thanks for noticing this - I build geany with the latest gtk and usually forget to look at in which version the given function was introduced.
Cheers, Erik --
It should be possible to use ui_menu_item_get_text from ui_utils instead.
Thanks for the hint - will post a corrected patch soon.
Jiri
Cheers Lex
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Jiří Techet wrote:
Different documents may use different indent size and it's often necessary to have all of them opened in parallel and use the correct indent size for each of them.
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Right now the indent size is set from a submenu of the document menu. This can be changed to use dialog to set the indent size; also a combined approach is possible - display only the common sizes in the submenu (2, 4, 8) with "others" item that opens the dialog to set the more esoteric indent sizes.
Jiri,
I've applied this patch to my own tree and I'm not sure its working as it should.
When I have a document open (with default tabs width set to 4) and I use your menu item to set the document to 8 I expect the indent to switch from 4 to 8 but that doesn't happen.
Did my cherry picking of this patch miss out something that was in one of the other patches?
Cheers, Erik
Erik de Castro Lopo wrote:
Jiri,
I've applied this patch to my own tree and I'm not sure its working as it should.
When I have a document open (with default tabs width set to 4) and I use your menu item to set the document to 8 I expect the indent to switch from 4 to 8 but that doesn't happen.
Did my cherry picking of this patch miss out something that was in one of the other patches?
Hmm, for some reason your code expected "_8" while on my machine I was getting "4". The attached patch handles both variants.
Cheers, Erik
On Sun, Aug 8, 2010 at 04:40, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
Jiri,
I've applied this patch to my own tree and I'm not sure its working as it should.
When I have a document open (with default tabs width set to 4) and I use your menu item to set the document to 8 I expect the indent to switch from 4 to 8 but that doesn't happen.
Did my cherry picking of this patch miss out something that was in one of the other patches?
Hmm, for some reason your code expected "_8" while on my machine I was getting "4". The attached patch handles both variants.
Interesting.
I wanted to avoid 8 callback functions for each menu entry by reading the label but apparently it wasn't a good idea. When thinking about it, the label can be localized and completely changed so I shouldn't rely on its value.
Instead of using your patch I think it's cleaner to really use the 8 callbacks which should fix all the problems. So please use the attached patch instead of the original one.
Cheers,
Jiri
Cheers, Erik
--
Erik de Castro Lopo http://www.mega-nerd.com/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Jiří Techet wrote:
Interesting.
I wanted to avoid 8 callback functions for each menu entry by reading the label but apparently it wasn't a good idea. When thinking about it, the label can be localized and completely changed so I shouldn't rely on its value.
Instead of using your patch I think it's cleaner to really use the 8 callbacks which should fix all the problems. So please use the attached patch instead of the original one.
Applied here and working as expected. Thanks.
Erik
On 10 August 2010 07:45, Jiří Techet techet@gmail.com wrote:
On Sun, Aug 8, 2010 at 04:40, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
Jiri,
I've applied this patch to my own tree and I'm not sure its working as it should.
When I have a document open (with default tabs width set to 4) and I use your menu item to set the document to 8 I expect the indent to switch from 4 to 8 but that doesn't happen.
Did my cherry picking of this patch miss out something that was in one of the other patches?
Hmm, for some reason your code expected "_8" while on my machine I was getting "4". The attached patch handles both variants.
Interesting.
I wanted to avoid 8 callback functions for each menu entry by reading the label but apparently it wasn't a good idea. When thinking about it, the label can be localized and completely changed so I shouldn't rely on its value.
Instead of using your patch I think it's cleaner to really use the 8 callbacks which should fix all the problems. So please use the attached patch instead of the original one.
Hi Jiri,
While this works fine and the handlers are only one line each, another way would have been to use one handler and set different user_data for each menu item.
Cheers Lex
Cheers,
Jiri
Cheers, Erik
--
Erik de Castro Lopo http://www.mega-nerd.com/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman wrote:
While this works fine and the handlers are only one line each, another way would have been to use one handler and set different user_data for each menu item.
To be explicit, you can do:
g_signal_connect ((gpointer) indent_width_1, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (1));
g_signal_connect ((gpointer) indent_width_2, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (2));
and in the on_indent_width_activate() callback use
GPOINTER_TO_INT(user_data)
to get the int back.
Erik
On Tue, Aug 10, 2010 at 02:41, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
While this works fine and the handlers are only one line each, another way would have been to use one handler and set different user_data for each menu item.
To be explicit, you can do:
g_signal_connect ((gpointer) indent_width_1, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (1));
g_signal_connect ((gpointer) indent_width_2, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (2));
and in the on_indent_width_activate() callback use
GPOINTER_TO_INT(user_data)
to get the int back.
Sure, you can do it when connecting callbacks to signals manually. But how do you do this with glade (2.12)? I was searching for some possibility to pass user data but without any success and that's why I decided first to check the labels and later to use different callbacks. I think it's not possible - no other glade-defined callback in geany uses callback data either.
Jiri
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 10 August 2010 18:22, Jiří Techet techet@gmail.com wrote:
On Tue, Aug 10, 2010 at 02:41, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
While this works fine and the handlers are only one line each, another way would have been to use one handler and set different user_data for each menu item.
To be explicit, you can do:
g_signal_connect ((gpointer) indent_width_1, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (1));
g_signal_connect ((gpointer) indent_width_2, "activate", G_CALLBACK (on_indent_width_activate), GUINT_TO_POINTER (2));
and in the on_indent_width_activate() callback use
GPOINTER_TO_INT(user_data)
to get the int back.
Sure, you can do it when connecting callbacks to signals manually. But how do you do this with glade (2.12)? I was searching for some possibility to pass user data but without any success and that's why I decided first to check the labels and later to use different callbacks. I think it's not possible - no other glade-defined callback in geany uses callback data either.
Oh yeah, now I remember why I don't like Glade :-)
Cheers Lex
Jiri
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 9 Aug 2010 23:45:02 +0200 Jiří Techet techet@gmail.com wrote:
I wanted to avoid 8 callback functions for each menu entry by reading the label but apparently it wasn't a good idea. When thinking about it, the label can be localized and completely changed so I shouldn't rely on its value.
Instead of using your patch I think it's cleaner to really use the 8 callbacks which should fix all the problems. So please use the attached patch instead of the original one.
I've now applied the patch as (recently) updated by Erik for merge conflicts, thanks.
I changed the code to use ui_menu_item_get_text() but not to translate any indent width menu items.
Regards, Nick
On Thu, 5 Aug 2010 01:59:53 +0200 Jiří Techet techet@gmail.com wrote:
The current implementation doesn't save the indent size to the project and session file - this can be added if desired.
Now added in SVN.
Regards, Nick