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...
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.
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.
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 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.
---
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. 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.
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.
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.
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...
Header/source - based on the current file's path, of course.
And of course, connect to Geany's new/open/close project, instead of having duplicate actions on the sidebar.
Using "additional paths" may be helpful to Yura Siamashka too - there would be no need to deal with several projects.