@elextr not sure how it handles non-ASCII, but it might be plain bytes, so the output encoding is whatever the input is was -- and doesn't handle non-ASCII-compatible support anyway.
And yes, it's the "old" vi format, but augmented with a lot of extra fields in a compatible manner.

Your concerns about non-ASCII is a good one, but AFAICT we'd have the same problem, or even worse with the proprietary one, I don't think we do much conversion when generating tag files. OTOH, we should be happy with UTF-8 ones as we mostly (?) use that internally. I'm actually not sure how we deal with non-"real time" parsing, I'm afraid we still feed in the file itself, which means no encoding conversion.

So I'm all for @techee's idea of putting the binary format to soft retirement, but indeed now might be a good time to sit down and think on possible issues it should tackle.

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