doublenibble
Unicode characters in buffers seem to be working quite well now. Unfortunately I still can't figure out a way to bind any non-ASCII input characters as keys. This works as expected:
but this doesn't:
Is there any way for me to bind this key? I tried changing my keys to some combinations that I can bind for 4coder, but I just can't get used to the new binds.
Thanks for bringing this to my attention. It's hard to think of all the things I need to support to make unicode really work, so I was specifically targeting getting it working in the buffers for this build, so it's good news that that is working. There are a few problems with the key binding situation. First I am not familiar with the rules in C about putting a utf8 encoded unicode character inside a character literal or string literal, so I need to go read up on all that. According to what you're saying it sounds like it doesn't want to work the easy way.
For now it should work if you look up the unicode value of the characters you're trying to use and put it in as a literal number... but that method obviously sucks so I will see what options are available to make this better.
Edited by Allen Webster
on
Reason: bring quote in due to page break
Thanks, that worked. I tried this earlier but I suppose my random Internet source was wrong and I used a wrong decimal code point number. In case anyone else wants to do the same, this page worked for me converting UTF-8 character to decimal code point:
http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=&mode=char
http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=&mode=char
Edited by doublenibble
on
Update:
After dealing with lots of cross compiler problems with character literals and string literals and C++11 support and so on, I've sort of solved this problem. It isn't 'nice' but it works.
Let me know if this is better for you!
After dealing with lots of cross compiler problems with character literals and string literals and C++11 support and so on, I've sort of solved this problem. It isn't 'nice' but it works.
1 | bind(context, get_key_code("§"), MDFR_CTRL, change_active_panel);
|
Let me know if this is better for you!
Thanks, that helps.
Could you elaborate a little on the problem with character literals/strings and how you solved it ?
Could you elaborate a little on the problem with character literals/strings and how you solved it ?
Sure. There are a number of things that make it tricky.
1. A character literal is suppose to fit in a char, but a char does not have enough space for codepoints over 0xFF.
2. There is a type, tchar which is suppose to be for wide characters, but the encoding and width of this type is not portable. On windows it is 16 bits, on Linux is is 32 bits.
3. There is suppose to be a string/character literal prefix L that supports long characters but it is speced to use the problematic tchar type.
4. The new C++11 spec adds U,u,and u8 prefixes, which all have more standardized meanings. U should have worked for this, it is suppose to be the 32 bit representation of a single character but the MSVC 2013 compiler did not accept it as a prefix to a character literal when the literal is encoded with more than 1 byte in the source code.
5. Finally there is the extra confusing matter that the code itself is usually in utf8 but that encoding is not what we want there, we want the unicode codepoint, so simply reinterpreting a string to an int with a cast wouldn't work either.
This solution takes in a string which it assumes is encoded in utf8 since most code is, and translates the first unicode codepoint out of the string. Most compilers are okay with utf8 characters being in strings and they preserve the utf8 encoding in the actual string memory.
Does that answer your question?
1. A character literal is suppose to fit in a char, but a char does not have enough space for codepoints over 0xFF.
2. There is a type, tchar which is suppose to be for wide characters, but the encoding and width of this type is not portable. On windows it is 16 bits, on Linux is is 32 bits.
3. There is suppose to be a string/character literal prefix L that supports long characters but it is speced to use the problematic tchar type.
4. The new C++11 spec adds U,u,and u8 prefixes, which all have more standardized meanings. U should have worked for this, it is suppose to be the 32 bit representation of a single character but the MSVC 2013 compiler did not accept it as a prefix to a character literal when the literal is encoded with more than 1 byte in the source code.
5. Finally there is the extra confusing matter that the code itself is usually in utf8 but that encoding is not what we want there, we want the unicode codepoint, so simply reinterpreting a string to an int with a cast wouldn't work either.
This solution takes in a string which it assumes is encoded in utf8 since most code is, and translates the first unicode codepoint out of the string. Most compilers are okay with utf8 characters being in strings and they preserve the utf8 encoding in the actual string memory.
Does that answer your question?
Mr4thDimention
This solution takes in a string which it assumes is encoded in utf8 since most code is
Not on Windows. It is very common for files edited in MSVS IDE to be saved in UTF-16 format (Windows native unicode encoding). They will have even BOM at beginning of file. Have had this happen multiple time in my development team when somebody wrote comment with unicode characters. Not talking even about random projects found on github or other places of internet.
Thanks
mmozeikoMr4thDimention
This solution takes in a string which it assumes is encoded in utf8 since most code is
Not on Windows. It is very common for files edited in MSVS IDE to be saved in UTF-16 format (Windows native unicode encoding). They will have even BOM at beginning of file. Have had this happen multiple time in my development team when somebody wrote comment with unicode characters. Not talking even about random projects found on github or other places of internet.
Really? I believe you, I just had no idea. I guess I will have go experiment with that.
Edited by Allen Webster
on