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 <pickf...@riseup.net>
发送时间: 2016年5月9日 7:40
收件人: dev@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 |
|| ||
