> But my question was, apart from not having a filename, whats special about > "global" tags that needs them to be distinguished? Or is "global" just a > confusing way of saying "no filename"?
In autocompletion, for instance, we put non-global tags first, see the sorting in https://github.com/geany/geany/pull/3269 so we need to distinguish them somehow. And of course, we can use some boolean or, what I would prefer, having some `filename` member directly in TMTag for global tags. > Ok, good point, but presumably the one open in Geany wins. This is another point - Geany itself currently doesn't open files when doing goto definition/declaration (it's the ProjectOrganizer plugin which does for the files which are in the project directory). Geany assumes that all there exists are the open documents and only toggles among them. Should Geany itself start opening documents if it finds a matching global tag with a filename? > That would affect autocompletes, rarely is it good to call other languages > functions directly, but it shouldn't impact goto, if a tag with the same > language as the current file is loaded (using the extension of the filename > stored in the TMSourceFile to decide), go there, else pop up the list and > give the problem to the user. My point was that TMSourceFile assumes all its tags are from the same language and I'm not sure if it wouldn't cause some problems with tag management. I would personally avoid creating TMSourceFile for global tags and would prefer having some `filename` member of TMTag if we decided to implement it. > Anyway, clearly its not something that is nearly there as I hoped it might > be, oh well never mind. It wouldn't be really that hard to implement, we just have to decide if we really want it and if Geany itself should start opening files when doing the goto lookup. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3379#issuecomment-1407429209 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/3379/[email protected]>
