모아치기 버그. 중간에 삭제시 채움문자 남음

[hayarobi]

모아치기 때문에 생긴 것이니까 아마도 세벌식 사용할 때만 발생하는 버그처럼 보이긴 하는데요.

글자의 처음을 초성이 아닌 중성이나 종성을 먼저 치고 그 다음 다른 부분을 칠 때 입력기가 모아치기로 순서를 재조정해 주던데요, 이 때 아직 완성이 안 된 부분에 자동으로 넣어주는 채움문자가 좀 말썽을 일으키고 있습니다.
예를 들어 st를 친다면 (코딩중 영어로 string을 쓰다가 자주 이 실수를 해서요) ㄴㅓ처럼 나올텐데, 모아치기 때문에 화면에는 ᅟᅥᆫ처럼 순서를 보정해서 보여줍니다. 이 때 내부에서는 ㅓ 앞에 초성채움문자 U+115F (utf-8로 e1859f)를 자동으로 삽입하고 있습니다. 이 상황에서 마지막 초성을 잘 쓰면 글자가 완성되어 문자가 한글 음절 영역의 문자로 바뀌거나, 아니면 오타를 인지하고 바로 딜리트로 삭제하면 이 채움문자도 잘 지워줘서 문제가 없습니다.

그런데 제가 반응이 느려 str까지 쳤다면... ᅟᅥᆫㅐ가 되는데, 이 때는 채움문자를 포함한 앞의 세 문자가 변환이 되지 않고 그대로 남게 됩니다. 화면상에는 글자가 세 개만 보이까 딜리트도 세 번만 누르게 되는데 그러면 채움문자가 지워지지 않아서 데이터 공간을 차지하는데, 화면상으로는 전혀 티가 안 나니 여러가지로 난감한 일이 생기고 있습니다. 클래스 선언하는 코드에서 이 채움문자가 끼여들어간 것을 모르고 있어서 디버깅할 때 한참 헤멘 적도 있고요. (자바에서는 저 문자도 허용되는 문자라서 컴파일 에러도 안 나는 바람에 꼬이기 쉽습니다) 샘플 문자열 중간에도 들어가는 바람에 문자열 길이 비교가 예상치와 달라서 원인 찾는 부분에서도 많이 헤메고 그랬습니다.

정상적인 경우라면 글자 조합중 나오는 한글 자모 문자는 글자가 완성이 가능하게 되면 한글 음절 문자로 변환되고, 그렇지 못한 상태에서 다음으로 넘어갈 상황이면 채움문자는 삭제하고 나머지 자모 문자는 한글호환자모 문자로 변환이 되는게 맞지 않나 싶습니다.

제 환경은 gentoo, gnome-3.18 에 ibus-1.5.11 , ibus-hangul-1.4.2 를 쓰고 있습니다.

[choehwanjin]

이 증상은 여러 가지 문제점이 복합적으로 작용하여 나타나는 것이라서 해결이 좀 애매합니다.
'ᅟᅥᆫ'는 미완성 음절이기 때문에 자모 문자열로 'U+115f U+1165 U+11ab'와 같이 입력이 됩니다.
'ㅐ'가 눌린 상태에서는 이미 입력된(commit된) 문자이기 때문에 지우는 동작은 app에서 일어나게 됩니다.
App은 'ᅟᅥᆫ'를 한 문자로 인식하여 backspace 한 번에 지우는 것이 바른 동작일 수 있습니다.
그렇다면 app의 버그라고 볼 수도 있겠습니다.

gedit로 테스트해보니 캐럿 이동이나 선택영역은 'ᅟᅥᆫ'를 한 글자로 인식하지만 backspace만
세 글자로 인식하는 군요

유니코드에서는 자모 문자열로 미완성 음절을 표현하는 것이 비표준입니다만, 모아치기 과정에서
미완성 음절은 필연적으로 나타날 수 밖에 없고 이를 사용자에게 보여주어야 합니다. 그래서 비표준이지만
미완성 음절을 사용하고 있습니다. 유니코드 렌더러에서 미완성 음절을 비표준이더라도 제대로 그려줄
수만 있다면 한 음절이 한 글자로 표시되어 더 보기 좋은 상태가 됩니다.

말씀하신대로 미완성 음절을 호환자모로 표시하는 방법이 있습니다만, 그러면 사실은 한 글자인데 두 글자로
보이는 문제점이 있습니다. 모아치기를 할때 글자 길이가 두 자가 되었다가 다시 한 자로 줄어드는 현상이
발생합니다. 글자를 입력하는데 캐럿이 문자열이 짧아지는 방향으로 이동한다면 사용자는 상당히 익숙하지
않은 느낌을 받는다는 점에서 별로 좋은 방식이 아니라고 생각했습니다.

[hayarobi]

제가 입력기 내부에 대해서는 잘 몰라서 그런데, 말씀하신 commit이라는 게 ㅎㅏㄴ처럼 음소로 입력된 내용을 한이라는 문자로 확정해서 변환하는 시점을 뜻하는 것인지요?
저 commit이 제가 생각하는 것이 맞다면, 커밋이 되기 전까지의 키보드 입력은 전적으로 ime가 제어하는 부분으로 생각했습니다. 그리고 문자의 commit여부도 ime가 판단해서 처리하는 것이 아닐까 해서, 그렇다면 커밋 전까지는 자모문자열로 표기하다가 commit을 해야하는 상황이 되면 한글자모 조합을 한글음절로 변환하든지 미완성 음절이면 호환자모로 바꾸어서 내보내는 것도 가능하지 않을까 하는 생각에에서 말씀을 드렸습니다.

그리고 자음어를 칠 때는 글자를 호환자모로 변환을 하는데 모아치기 모드(?)로 들어온 것들은 한글자모 상태 그대로 남아있는 것도 이것대로 일관성이 깨지는 정책같기도 했습니다. 애초에 미완성인 상태의 입력이라면 사용자의 애초 의도가 자음어처럼 음소를 그대로 표시하려는 것을 간주해도 상관없지 않을까 하는 생각도 들고요.

[choehwanjin]

말씀하신 대로 한다면 commit text와 preedit text를 다르게 하자는 이야기가 되는데
사용자는 preedit text가 입력될 줄 알았는데 다른 글자가 입력되는 것이 되어
좋지 못한 동작이라 생각합니다.

사용자는 중성와 종성을 입력한 상태라서 사용자의 의도가 분리된 자모를 입력하려는 상황이
아님을 알 수 있습니다. 분리된 자모를 입력한다면 중성과 초성을 입력했을 것입니다.

또한 호환자모로 표현하면 미완성 음절의 preedit text는 두 자가 됩니다.
이후 초성이 입력되면 두 글자로 보이던 preedit text가 다시 한 글자로 길이가 줄어들어 보이는 문제가 있습니다.
저는 그보다는 자모 문자열로 표현하는 편이 좋을 것 같습니다.

[hayarobi]

유니코드 표준을 좀 살펴보니 호환자모는 말 그대로 과거 인코딩과 호환만을 목적으로 있는 거라고 씌여있네요. 오히려 현재처럼 필러를 넣어서 표기하고, 글자를 삭제할 때 필러도 함께 삭제가 되는 것이 더 표준에 부합하는 것이라는 생각이 듭니다. 그런 면에서는 현재 정책이 더 이상적인 모습처럼 보이지만, 현실적으로 필러를 자동으로 삭제해 주는 데가 없어서 어려움이 많네요. 일단 이클립스쪽에는 안 되는 영어로 이슈를 올려보긴 했는데 언제 해결이 될 지, 아니 해결을 해 주긴 할지도 잘 모르겠는 상황이고, 지에디트나 터미널 같은데서도 조금씩 다른 경우는 있어도 깔끔하게 동작하는 경우가 없네요.

윈도우에서 세벌식 모아치기를 지원하는 날개셋의 경우는 중성과 종성만 입력이 된 상태에서는 일단 중성만 보여주다가 불완전한 상태로 커밋이 될 상황이면 중성만 호환자모로 표기하고 종성은 버리는 정책을 취하고 있습니다. 이것이 옳다는 것은 아니지만 아마도 위에 쓴 현실적인 문제도 있고, preedit상태에서도 미완성 글자가 차지하는 공간이 항상 한 글자 크기만 유지가 되어서 화면상에서는 조금 더 깔끔하게 보인다는 장점이 있습니다. 현재 상황에서 미완성 음절을 한 글자로 렌더링하는 앱이 없어서 텍스트 중간에 커서를 옮겨 모아치기로 타이핑을 하다보면 커서 뒤쪽의 텍스트가 뒤로갔다 다시 앞으로 당겨지는 현상이 발생하고 있습니다.

그리고 ㅎㅎㅎ나 ㅜㅜㅜ처럼 초성이나 중성 음소만 타이핑하는 경우 한글호환자모를 사용하는게 비표준에 가깝고, (필러),한글자모,zero-witdth space 로 쓰는게 유니코드 표준에 더 부합하는 표기법이라는 생각이 드는데, 현재처럼 호환자모로 표기하는 것도 일종의 타협이 아닌가 싶습니다. 그런 면에서 이 부분도 어느 정도 타협이 가능하게 수정하거나 혹은 옵션을 줄 수는 없을까 합니다.

[choehwanjin]

말씀하신대로 미완성 음절의 경우 호환자모를 우선 사용하게하는 옵션을 추가하도록 해보겠습니다.
한글 자모중에 호환자모로 표현불가능한 글자가 있으므로 호환자모만 사용할 수는 없어 우선 사용하는 옵션이라 하였습니다.