Re: [PATCH 0/2] Enlarge the storage of chars in virtual terminal

[Tejun Heo <tj@kernel.org>]

Hello,

On 05/27/2010 10:59 AM, Frank Pan wrote:
> You are right, I've missed a big count of languages.
> Nonetheless, the vt already identified several ranges in the unicode
> space, and made them 2 times wide as ASCII chars.
> My idea depends on this.

Hmmm... I see.

>> And then, if you think about multilingual terminal, output is only one
>> half of the story.  You gotta be able to input something too and in
>> many scripts, input handling needs to interact constantly with
>> rendering, which means that the kernel will also need to supply input
>> framework, at which point I start to wonder whether the whole thing is
>> just too complicated.
> 
> Agree. Input method is much complex than a data structure expanding.
> 
> I don't know about other languages, but I bet the thing goes like:
> one press one or more keys, (choose the char he/she really want to, )?
> and commit an input.
> We need not to implement the whole thing inside kernel, a user space
> app can catch keyboard inputs and push unicode chars into the tty.
> The only change should be done in kernel is reserve a space on screen
> for the potential char choosing, which is really easy to do in any
> console drivers(report a smaller height/width).

I'm not an export on the issue but if I'm not mistaken it gets more
complex than that.  It took quite some time to solve the problem
properly even on full desktop envs.

>> What's the use case other than "I just want to use console"?
> 
> Many times I type startx is just for checking time of a meeting
> (in a CJK web page, etc).
> Many times I've found emails in mutt with question marks, I must
> open a X and a terminal in X, and mutt in terminal in X.

And other than yourself, how many would such users be?  What's your
reason for not using X other than "console looks cooler"?  Even if you
have some valid reason to not use X and absolutely have to have
multilingual support, what prevents you from using fb based terminals
like jfbterm which already works with input and all without
introducing any i18n related complexities into kernel?  To me, it
seems like low activiy on jfbterm seems to show the low demand for
such feature.  So, just use X.

> Is there anything worse?

Sure, there are plenty of worse things.  :-)

Thanks.

-- 
tejun