OGRECave / ogre

scene-oriented, flexible 3D engine (C++, Python, C#, Java)
https://ogrecave.github.io/ogre/
MIT License
3.91k stars 966 forks source link

[OGRE-508] Stray Unicode Character OgreResourceTransition.h #201

Closed paroj closed 8 years ago

paroj commented 8 years ago

[reporter="dermont", created="Tue, 10 Nov 2015 14:17:56 +0000"]

Sorry for raising such trivial issue again, another unicode problem parsing OgreResourceTransition.h with gccxml.

Same position/problem as https://ogre3d.atlassian.net/browse/OGRE-495.

Version v2-1 7983:3675ffea3b57 on Linux.

paroj commented 8 years ago

[author="dark_sylinc", created="Sun, 20 Mar 2016 04:28:00 +0000"]

The thing with this ticket is that it was feeling like a whack-a-mole. Fix it once, appears again later.
Those weird bytes at the beginning aren't a bug. They're the UTF-8 BOM header https://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding.
Perhaps there's a way to configure gccxml to recognize the BOM?

Some text editors will add it, some will remove it; some will keep whatever was there before it was opened. And this is hard to notice.
QtCreator (my favourite editor) supports the three options (adding it, removing it, keeping what was in the file). I've configured it now to remove them, so I figured the problem would eventually be fixed the next time I edit the troublesome file(s).

But if I happen to edit a file in a different text editor that adds the BOM header, it will reappear again (unless I also open it on QtCreator before I commit). Thus the whack-a-mole situation.

paroj commented 8 years ago

[author="dark_sylinc", created="Sun, 20 Mar 2016 04:30:09 +0000"]

Once we get close to shipping a release we may gather all files that have a BOM header and fix them all. But doing it now... I'm just chasing ghosts that will reappear later.