Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
This is a continuation of #3049 (comment):
IIUC what would happen now is that a symbol in an olde tags file will show as a different kind from what it would show as if the source file file was open in Geany, or the tags file re-generated. But it would still load, and will still show as the same kind it always did.
If it were only a matter of showing it as a different type, it probably wouldn't be such a big problem. I'm more worried about more advanced stuff like scope autocompletion or things like
https://github.com/geany/geany/blob/37d20a823fb1bca67cea57ef73aa9e64009d8138/src/symbols.c#L2017
where we make decisions based on the mapped type. And then you have some language mappings that were probably made just based on what was free (or what looked good in the symbol tree in the sidebar) like the namespace here:
What I was thinking is that if we had the original ctags kind in the file, we could fix such mappings invisibly to the user in the future and users wouldn't need to regenerate such files by themselves.
IIUC both of those mean relevant symbols from tags files from before the mapping change will change the kind they show. That may not be right, for example one of the recent parser updates split a kind into two IIRC (was it Ada? can't remember and too lazy to search) so now old file symbols using the letter that was split will all show as one of the halves. So both 1. and 2. will show something different for existing tags files.
I'm not sure if I understand completely the first part but the last sentence is what will actually happen if we don't store the ctags kind letter. Suppose you generate
ctags.tags file with ctags for some C sources.1-38.C.tags with Geany 1.38 for the same C sources.1-39.C.tags with Geany 1.39 for the same C sources.and that there's some change in the mapping between 1.38 and 1.39. When you load ctags.tag, it will reflect the current Geany's version mappings while 1-38.C.tags will (forever) represent the mapping made in 1.38 and 1-39.C.tags will (forever) represent the mapping made in 1.39. So 1-38.C.tags will show something different than 1-39.C.tags (which should be the same as ctags.tags in Geany 1.39 but in Geany 1.40 it may be something different again).
And if the parser removed a letter what happens, do we need to keep it in the mapping? Hopefully ctags will never reuse the same letter for a totally different kind, then we would have to complain to ctags?
I think kind letters are the "API" of ctags and that ctags is rather conservative about these. The situation in this relase was rather exceptional because we were replacing some parsers which existed only in Geany with parsers that didn't exist in ctags at all and which were developed completely independently of their Geany versions. So I don't think this will be common.
In any case what I should have done in the patch (and which I'm going to update) is to ignore the kind letter if it doesn't map to anything (the case of the potentially removed kind in ctags parser) and use the stored mapped kind instead.
One more possibility is to store the kind letter to the tags files and not to do anything with it for now and decide later whether we want to use it or not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.