Closed mntos closed 9 years ago
This reproduces only no-window(-nw
) option. I cannot reproduce this issue with GUI Emacs.
This is terminal emulator constraint, not popup-el.
After evaluating popup-tip
, popup.el
waits for your key by read-event
and popup.el
pushes the key to unread-command-events
. But read-event
does not work for multiple
byte characters on no-window Emacs. And it is very difficult(impossible) to fix this issue.
For example,
(read-event)
あ
GUI Emacs returns 12354 (#o30102, #x3042, ?あ)
,
while no window Emacs returns 227(#o343, #xe3, ?ã)
and inserting \201\202
.
So there are no way of distinguishing between typing あ
or typing ã
on no-window Emacs.
Last time, I tried it was on emacs version 24.4.1. And now I've found that this does not happen on version 24.3.1.
Anyway. I understood that it is caused by read-event. and almost impossible to fix it. Thank you for your explanation.
Thanks for information, read-event
works well for multiple byte characters if 2nd argument is non-nil.
I suppose that popup-el
can know users use some input-methods such as leim, ddskk,
mozc.el etc and can set second argument of read-event
, however it is impossible to know
whether input-method is used if users use Google Japanese Input(which you use), Windows IME
etc because they works on the outer side of Emacs.
@syohex @mntos How do you guys record .gif screenshot like that? (sorry that github does not have internal message way, so I have to post after this closed issue)
@stardiviner I use byzanz and my own helper utility. If you use Windows or MacOSX, there are some free software for creating Gif, such as LICEcap
@syohex thanks for your helper utility.
On OSX terminal, I tried to type Japanese letter while showing popup-tip but the letter went unreadable. I’m not using Japanese input method on emacs but using system wide Japanese input method. the gif shows what I did.