On Thu, 30 Mar 2000, Vlad Harchev wrote:
> --- lynx2-8-3-was/src/LYMainLoop.c Mon Mar 27 08:14:00 2000
> +++ lynx2-8-3/src/LYMainLoop.c Thu Mar 30 18:19:35 2000
> @@ -4333,6 +4333,7 @@
>
> if (HTisDocumentSource()) {
> srcmode_for_next_retrieval(-1);
> + LYUCPushAssumed(HTMainAnchor);
> } else {
> if (HText_getOwner())
> StrAllocCopy(*ownerS_address_p, HText_getOwner());
>
>
LYUCPushAssumed(HTMainAnchor) shouldn't be used other than for going *to*
source mode. Its use without careful consideration may lead to
charset info for a file being kept longer than it should.
This doesn't look like the right solution.
> On Wed, 29 Mar 2000, Vlad Harchev wrote:
>
> > There is one more bug wrt prettysrc and charset handling (not checked
> > dev23, but it's present in dev16 and seems no fixes for it were posted). If
> > charset of page was specified in the HTTP header, and that charset is not assumed
> > document charset, then switching to psrc and back will rerender document with
> > assumed charset rather than the one specified by http header. This loss of
> > charset information makes documents in russian completely unreadable. Sorry
> > for reporting this so late - I hoped to fix this problem myself (but if anyone
> > knows solution right now - please do this). As I understand - the something in
> > LYMainLoop.c should be tweaked (and I predict the patch will change only one
> > line in LYMainLoop.c).
>
> I researched the problem, it turned out that this is not only psrcview
> problem (but any source view), and it looks it appears only if
> SOURCE_CACEH:MEMORY is used (no problem if SOURCE_CACHE:FILE is used).
Then it's a SOURCE_CACHE problem, and the fix should probably be
in HTreparse_document. It should treat both MEMORY and FILE in
a more equivalent manner.
Your fix is LYK_SOURCE specific. But what happens if you leave source
mode by some other key than '\', for example as a side effect of
^V, '*', '@', etc.? (I expect the problem is still there.)
> Here is the patch to fix that (more correctly - if the same logic is used to
> correct dev14, then the problem will be solved; it's impossible to test
> whether the problem will be solved with the patch I'm sending for dev23 in
> dev23 since SOURCE_CACHE doesn't work in dev23 at all; but I think the same
> logic applies to dev23).
(I haven't yet tested the dev.23 problem - but do others see the
same?)
Klaus
