Re: lynx-dev URLs with raw 8-bit chars (was: lynx: have bug)

[Leonid Pauzner]

> it works as advertised.  The current implementation doesn't do the
> to-UTF-8-then-to-hex in all cases (e.g it cannot if input is CJK),
> and it doesn't do the raw-hex in all cases (it cannot if the HREF
> attribute contains &entity; for character > U+0100 from arbitrary
iso-8859-1 is not the only charset ^^^^^^^^^^^^^^^^^
> character set).  So the new setting would either work unreliably (not
> in all cases), or it's explamation would have to have all sorts of
> disclaimers, or the whole mechanism would have to be substantially
> revised.

> 'Fixing' the behavior (in both senses of the word) also introduces
> yet another aspect that could easily be broken when modifying the
> way character translation works.  That could be an unwelcome
> limitation for making otherwise useful changes.

> So I wouldn't want to add a new Option for this, or make the behavior
> in any way more 'official'.  The benefits are limited, and arguably
> such links are broken and _should_ be broken if it costs us too much
> to attempt to 'fix' them.  But I may be biased, because I have never
> encountered such URLs in reality.

Seems you overestimate the cost of such changes -
we may add a flag and use a simple HTEscape() in HTML.c
instead of UCLYFullyTranslate() call
(and I have not seen character entities in HREF= in the reality).

> According to the CHANGES you quoted (thanks for refreshing my memory),
> 2.7.2 chose to always do the UTF-8 thing.  That would be more consistent
> and predictable (although it can't work for CJK etc.), but even less
That is what I want - UTF-8 when possible by default
with drawback to %xx raw bytes by a hot key.
> what you want.   With our current code, you have at least a workaround
> way (undocumented, and probably 'making the document unreadable' as you
> say) to get the link interpreted so that it works.


>    Klaus