On Wed, 18 Jun 2003, Nikita V. Borodikhin wrote:

Hello, Jorge !

Jorge, I'm sorry for annoying you but can you say anything about the future of this charset representation patch also posted to dillo-dev list at Mon, 9 Jun 2003 17:40:24 +0700 ?

Some time after that (2003/06/12 20:51:00) you add 0x2022 code to UCStolatin1 handler so this patch differs from mailing list one in one line.

This is at least my third answer to this not high priority issue. From my previous response, still this concern remains unanswered:

(I wrote)

Finally, I can't see (yet) how having this entitites character representation helps when using another character set (as with the russian encoding workaround), unless you first convert the regular HTML character encoding into the current locale! Certainly a hairy problem, and one of the main reasons for GTK+2 design decision of using UCS instead of the current locale as its internal representation.

Now, considering that the default dillo uses Latin1, after reviewing the patch, I found 38% of the big representations table is useless... (and there are other things).

I know you are now hard-working but this patch is not too big to review...

Yes, it is not too big to read, but the work behind integrating a patch is certainly bigger than the patch itself. Most of the time it involves reviewing some RFCs, the internal working structure of the browser in that matter, performance issues, impact, internal standards, future, an so on. IMHO, this is not my duty to do, but the patch sender's, and when I see it was done losely, certainly it discourages me from working on it. If it regards a matter with low priority, then I have one more reason... Now, considering that I have excellent patches in the queue to review (with versions, research, README, Documentation, explanations...), I feel really guilty for dedicating much time to other stuff, but I hope this explanation serves everyone.

Once more sorry.

I'm also sorry. Jorge.-