From Slack:
EB: We now have the new km_core_state_context_set_if_needed (which takes a UTF-16 string) and km_core_state_context_clear API methods which replace the previous km_core_context_* methods. It seems to me that we should have a method that returns the context for debug purposes (km_core_state_context_get_debug?). Then we wouldn't have to go through km_core_context_items by calling km_core_context_get and km_core_context_items_to_utf8 which is a bit confusing compared to setting the context, and not symmetric.
MD: That seems like a good idea -- so long as it is clear it is for debugging use and not integration. The question is, should it return it as a formatted string to enforce that? Can you open an issue for that?
EB: Return a formatted string is a good idea. Currently I use |string| (len) [Unicode code points] on Linux, e.g. |ខ្មែរ| (len:5) [U+1781 U+17d2 U+1798 U+17c2 U+179a ]
From Slack:
EB: We now have the new
km_core_state_context_set_if_needed(which takes a UTF-16 string) andkm_core_state_context_clearAPI methods which replace the previouskm_core_context_*methods. It seems to me that we should have a method that returns the context for debug purposes (km_core_state_context_get_debug?). Then we wouldn't have to go throughkm_core_context_itemsby callingkm_core_context_getandkm_core_context_items_to_utf8which is a bit confusing compared to setting the context, and not symmetric.MD: That seems like a good idea -- so long as it is clear it is for debugging use and not integration. The question is, should it return it as a formatted string to enforce that? Can you open an issue for that?
EB: Return a formatted string is a good idea. Currently I use
|string| (len) [Unicode code points]on Linux, e.g.|ខ្មែរ| (len:5) [U+1781 U+17d2 U+1798 U+17c2 U+179a ]