[Alpine-info] UTF-8 test message for your viewing (dis?)pleasure
chappa at u.washington.edu
Mon Mar 9 14:13:38 PDT 2009
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
:) 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?
More information about the Alpine-info