On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet techet@gmail.com wrote:
Find in project segfaults. I'll compile a -g version tomorrow.
Fixed & pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case).
Pulled. So the current file must belong to the project...
Yes. The good thing about it is that if you swap between several files from different projects, it automatically selects the active project for you. But I'm aware that this might be confusing. Another option is to select the active project manually - e.g. by using a combobox in the sidebar's statusbar.
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Again, because the project wasn't active.
Probably forgot to reopen it after Find in project crashed.
When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks).
Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find
What is pathbar selector?
Invoke File -> Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example "/usr/local/bin", and have each path part cickable.
OK I understand, thanks for explanation.
I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you.
Bookmarks with commonly used directories, for example "src".
I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your "favorites" in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add.
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a
You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem.
The actions from Project -> Properties -> Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only.
With the current API, there's no integration with the geany's project possible. Right now it's completely independent of any project functionality of geany. See below.
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative.
It's actually an interesting alternative and by coincidence I've been thinking about the same when going home by train today. Unfortunately it's not possible right now. If you have a look at what one can do with the project:
http://www.geany.org/manual/reference/project_8h.html
you realize there's nothing you can actually do. You can just read the GeanyProject struct.
IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly:
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates.
I would have to be able to add extra settings to .geany - not possible now.
Add a gproject setting, "additional paths" or something, which contains a list of paths, for example the base paths of the projects you need to open files from.
I would like to avoid that. I want all the paths to be relative to base_directory so you can move the directory wherever you want without making the paths invalid. As you have no control of what happens outside the base directory, the additional paths may be moved and the project settings becomes inconsistent. Also displaying these extra directories might be confusing (where in the tree should they be displayed?) - I'd like to display only what's on the disk without the need of "meta" directories.
My current preference is to support only a single project and solve the rest by what the unix filesystem already offers. If people want to use external directories, they should add a symlink to them into the project directory (if you ask what about Windows users, my answer will be that they should start using Linux). If the symlink becomes invalid, it just won't be read but there will be no settings inconsistency. The symlinked directories would be displayed in a different color in the tree.
Add a gproject setting "Generate tags for additional paths" - since opening a file from them may not be so common, and they can be large.
Continuing in my idea above, similarly to "ignored dirs patterns" there could be "ignored dirs for tag generation patterns" (both of these settings could be made more flexible, e.g. could contain something like .gitignore does - right now the patterns match against the current directory only so you cannot ignore only e.g. the toplevel "src" directory and keep others)
Well, you won't be able to use another project's "Generate tags for all project files", but OTOH, you'll be able to control the tag scan separately for the base project path and the additional paths.
Browser, Find file, Find in project - display / work with all paths, no matter under which of them (if any) is the current file. The current behaviour is confusing, and to search for a file, I have to select a file from the same project, or switch to the panel and navigate to the project...
Should be solved with my variant too.
Header/source - based on the current file's path, of course.
Internally I could treat symlinked dirs as projects with base directory where the symlink points to so header/source swapping could work for external projects too.
And of course, connect to Geany's new/open/close project, instead of having duplicate actions on the sidebar.
Not possible now. Geany also should make it possible for plugins to add a new tab to the project properties dialog so all the project settings are at one place.
Using "additional paths" may be helpful to Yura Siamashka too - there would be no need to deal with several projects.
The symlink solution works here too I think (after all, it's just a different implementation of your idea).
Thanks a lot for spending your time thinking about how to improve the plugin! It has been very inspiring for me. Please let me know what you think about my variant of your idea.
Cheers,
Jiri