On Sun, Jun 13, 2010 at 14:07, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 12 Jun 2010 01:06:34 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 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.
A zero is displayed for a file open via gproject, which you never navigated into. Once you click inside the editor, use the arrows or something, that becomes non-zero. Not an issue.
Aha, interesting, I wonder if this is a scintilla bug or an expected behaviour. I can add "if 0 then 1" or something like that.
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 prefer to have bookmarks, for example src and include, and avoid the entire tree as much as possible. And have an idea about them below.
Apparently you find one of the best features of the plugin to be its drawback ;-)
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, [...]
Ah, I forgot to start with the main ideological change (there was only a hint "unless you really need 2+ projects"). So then:
Instead of multi-project, make gproject single-project, multi path (with the base path from Geany project). Then the base and additional paths will be displayed like the current paths for 2+ projects.
With this, you'll will be able to have a "/home/.../geany-testing" as base project path, and several other geany trees as "additonal" for browsing and searching. Or a project with several main paths (Yura's), as long as there is a single build command - that's the limitation.
As of the additional paths being absolute or relative, we woudn't really know if they are part of the project, and even if so, whether they are moved together with the project base path. The absolute paths look like a safe bet...
But what if APs _inside_ the project tree are used as directory bookmarks? :) Obviously, they'll be relative - and so the simplest solution seems the best: let the user enter the APs as absolute or relative, and save/use them as entered.
Just to make sure, do I understand correctly that the bookmarks should be subtrees of the project tree copied and put somewhere behind the project root at the top level? I think this could be done but to be able to quickly distinguish between project/external project/bookmark the sidebar should be somehow divided into three parts (e.g using separators or different color for icons or something like that). Clearly it has to be made sure that the bookmarks are not scanned for tags because the files are already scanned within the project.
there could be "ignored dirs for tag generation patterns"
Yes, having directories excluded from tag scan will be much better than any per-project or per-path options. Perpaps a check menu item in the directory right click menu? It'll be good to store these as relative
I don't like the clicking idea much - for complex trees the ignored dirs would be hiding somewhere in the tree and it would be a nasty clicking exercise to find them.
to their path, but that will require a real list of APs, not a single string of space-or-whatever separated entries.
Well, looking at it it would be best not to have external projects - everything would get clear then - and this is probably how I'll implement it. The external dirs idea already doesn't fulfill my needs - I really need to switch between several projects each of which has the same "rights" as the remaining ones (header/source swapping, searching in project files and so on). But I think that your idea will integrate much better to geany's project management (only a single project open). For more open projects one should probably have more geany instances running (well, tag sharing won't be possible, I know).
Unfortunately I'll have very little time to spend on implementing that in the next two months (even though the implementation looks like only one week of evening coding). But I'll definitely implement that once I have some free time left.
Thanks for your ideas!
Jiri