[Alpine-info] UTF-8 test message for your viewing (dis?)pleasure

[Eduardo Chappa]

On Mon, 9 Mar 2009, Mark Crispin wrote:


:) On Mon, 9 Mar 2009, Eduardo Chappa wrote:

:) > [Mark, (and everyone else) please do not attack me in a public forum.

:) 

:) If you do not like being corrected in public, then don't make false 

:) statements that need correcting in public.


Being corrected in public is different than being called names in public. 
You can correct me all you want. Just don't attach names to it. Thank you.


:) > There is no guess in the code. The decision of the code is clear.

:) 

:) There you go again.

:) 

:) You see something in a snippet of code, assume that you now know all 

:) that there is to know, and then contradict me.

:) 

:) You don't know everything that there is to know.  There is more to the 

:) width calculation than the code that you found.


These are your words:

 case 3:                       /* ambiguous width */
    ret = (c >= 0x2100) ? 2 : 1;/* need to do something better than this */

Obviously you are unhappy with what you did. That's the line that causes 
all the problems in Alpine.

I would like you to talk about how Alpine should fix this problem, even if 
you keep your decision of not changing that line.


:) > But there is a problem, and it needs to be fixed. Would you like to 

:) > help solving that issue?

:) 

:) Don't you understand yet?

:) 

:) There is no solution.


I understood that you meant to say that. That is not a problem. I just 
don't think that this is the last word. But if you want to keep it that 
way, it is fine. I hope you will not prevent those in search of a solution 
from finding one. The problem that your code creates in Alpine must be 
solved, unless you think that the problem does not exist because it can 
not be solved. I would appreciate if you referred to how you think Alpine 
should fix the problems that are being created by this code. Have you seen 
the spaces at the end of the box? have you tried editing them out and see 
what happens? If those characters have width one (in my terminal), then 
there is no problem.


:) There are only compromises.  A compromise will work well in some cases 

:) and less well in other cases.

:) 

:) You can optimize for your particular environment, at the cost of 

:) pessimizing some other environment.


Sometimes the solution is to say "program X is not supported in 
environment Y". As long as the world is moving away from "Y", that is a 
not a bad decision (of course, neither the best decision).


:) The users will be unhappy at how much slower and bandwidth-intensive 

:) display has become.


Unless you only support certain environment "Y", this is not a major 
issue, because you do not need to test for those issues.


:) The real solution is to give up on the notion of Alpine running in a 

:) terminal emulator.  If UNIX Alpine were to display in an X window (NOT 

:) under xterm, but as its own X window application), it becomes possible 

:) to use the knowledge gained from having the rendering engine in the 

:) same application to do correct width judgements.

:) 

:) That is the ONLY solution for characters (e.g., Arabic) that have no 

:) meaningful fixed-width representation.

:) 

:) The only problem is, I don't know why anyone would want to use the 

:) result. There are many GUI-only email clients which have a huge head 

:) start.


I agree. 


:) The lesson that you should learn from all of this is that, sometimes, 

:) what seems to be a "simple" solution is neither simple nor a solution.


I know enough to know that. There are, however, other compromises that can 
be made. Saying that all variable width is width 2 causes more problems 
than it fixes. I wish you checked those problems, so you can see why it 
needs to be corrected. Could you please?

-- 
Eduardo