Regarding the wrong cursor position problem: Changing the default monospace font (in config.h) to a Chinese font is a good workaround for now.
The problem is that drw.c implements a font fallback mechanism on its own, but _only when_ drawing characters. When calculating the width of a string, it always use the first font (drw->fonts[0]) and no fallback mechanism is active.
Some patch suggestions:
1. You can implement another font fallback mechanism for calculating the width of a UTF-8 string. This would result in a bigger drw_font_getexts_width() function.
2. You can combine the drawing of the string and of the cursor. That is, drw_text() optionally draws the cursor after a specified position (in characters). Because drw_text() keeps track of the position of the character that is just drawn, it would put the cursor at the correct position.
Hope it helps,
Rui
________________________________________
发件人: Pickfire <pickfire_AT_riseup.net>
发送时间: 2016年5月9日 7:40
收件人: dev_AT_suckless.org
主题: Re: [dev] 答复: [dev] 答复: [dev] 转发: [dmenu] support for input methods
On Mon, May 09, 2016 at 02:31:21PM +0000, 张 睿 wrote:
>Can you make it clear about whether you can _type_ anything with fcitx with the git version of dmenu?
I can type something with fcitx but not chinese characters.
>If yes, All right. I guess it was a bad idea that I did not try the git version before making a patch. :-(
>Otherwise, please try out my patch.
Where's your patch?
>Anyway, now I can at least type something in dmenu. Wrong cursor position is just a minor problem, since I hardly need any editing for what I type in. I guess it has something to do with calculating the width of a text, and it should be easy to fix.
It should have something to do with wcwidth, I am not very sure, you can
take a look in st's code.
--
_____________________________________
< Do what you like, like what you do. >
-------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
Received on Mon May 09 2016 - 18:01:07 CEST