I didn't mean they would always be invalidated

Perhaps invalidated was a poor choice of word and made it seem worse than it is.

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.

That does not seem to be an issue to me. Olde tags files are no worse, memory symbols and new tags files are an improvement, yay!

Store the ctags kind letter to the tagmanager-format tag files and use it instead of the mapped type if present
Use the ctags file format for the tag files we ship with Geany

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. 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?

So it seems with either 1. or 2. there is the same potential behaviour change.

My current evaluation is that having old tags file load the same way they always did, but different to new tags and open files is less likely to cause user issues. So doing nothing happens to be both the best solution and the easiest :-)

Or both.

Or neither for now.

But I agree that in the longer term it might be better to use ctags tags files directly, which this PR is a necessary step towards.

Now conflicts are fixed will try to test in the next few days.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.