lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev dev.15 patch 2


From: Leonid Pauzner
Subject: Re: lynx-dev dev.15 patch 2
Date: Sat, 27 Nov 1999 16:44:50 +0300 (MSK)

26-Nov-99 21:30 Klaus Weide wrote:
> On Sat, 23 Nov 1996, Leonid Pauzner wrote:

>> 25-Nov-99 10:48 Klaus Weide wrote:
>> > * Reset the edit_mode flag (indication of Dired mode) in various places,
>> >   so the flag doesn't stat TRUE after a new page has been loaded.  For
>> >   example, invoking the forms based 'O'ptions page from a Dired directory
>> >   view would leave the Dired key bindings enabled within the Options page.
>>
>> IMHO a better approach: always set edit_mode to FALSE in getfile(),
>> and change to edit_mode = TRUE in print_local_dir()

> Yes, what I did (scattering 'lynx_edit_mode = FALSE' over the place) isn't
> the most elegant solution.  Actually, quite ugly.

> Probably just setting it to FALSE in getfile() much earlier (than the
> place where it already *did* occur) would be all that's needed.
> I wasn't completely sure this wouldn't have some undesired consequence
> (turning Dired off when it should stay on - like after a file access
> failure maybe).  So I did the more laborious (and more ugly) thing.

> If you think there are no ill effects of doing it the simpler way,
> feel free to send a patch (or to keep reminding me...).

>> [hmm, not sure if
>> VMS using that code or not...] and (probably) in mainllop when 'f' key
>> (or equivalent) is pressed.

> the variable lynx_edit_mode should only be TRUE while viewing the
> directory listing itself.  That's how I understand its function.  So 'f'
> will actually turn it off.  Well not 'f' itself (or direct_options()
> called as a direct result), but the sucessful loading of the temp file
> created by direct_options() will.

>> Does your changes fix reloading of directory listing when
>> switching show_dot_files from forms-based options menu?

> No.  I wasn't aware of such a problem.
And this fix may not be possible with lynx_edit_mode=TRUE in getfile
described above (we lost a history taht way), perhaps that should be set
in HTLoadAbsolute() when the document loaded OK (the function returns
TRUE). This also cover partial display case (which will be lost if we
set flag explicitely in mainloop case NORMAL).

In HTLoadAbsolute() an address will already be resolved so we could
find whether this is a directory listing or not. Hmm, seems the present
code does not add "/" separator when local file URL happes to be a
proved directory - this will simplify things with lynx_edit_mode a lot.

Perhaps, we could introduce yet another flag, lynx_edit_mode2, which
will be initialized to false early in HTLoadAbsolute(), than (probably)
changed to true in print_local_dir(), and then set
lynx_edit_mode=lynx_edit_mode2 if HTLoadAbsolute() will return true.

[this could be done faster than writing the above text, but I have not
recovered my system from hard disk crash early this week:((



>> > * Tweaks for LYNXCFG: and LYNXCOMPILEOPTS: pages: [...]
>> >   Recover if the tempfile has
>> >   unexpectedly disappeared, by regenerating it.  Also regenerate tempfile
>> >   if NOCACHE key ('x') is used. [...]
>>
>> I read your comments in the code, in LYReadCFG.c ...
>>
>> There was another reason why I made LYNXCFG:/ page cached in more cases
>> than any other page: you can edit your lynx.cfg file(s) during lynx
>> session but LYNXCFG:/ output will not be changed unless you activate
>> changes with LYNXCFG://reload  - e.g. this is not a filtered lynx.cfg
>> (and includes) but options that are currently active.

> Ok, I didn't really take that intention into account.  But it seems
> that already without my changes, LYNXCFG:/ is not guaranteed to show
> exactly the settings *in effect*: Not if you edited lynx.cfg after
> starting lynx and *then* visit LYNXCFG: for the first time.  OTOH
correct. But that would be a rare case in general.

> my changes don't change things that much: only if something unusual
> (file disappearance) happened or if 'x' is used on one of the
> LYNXCFG: or LYNXCOMPILEOPTS: links.  Do you agree that it's OK?
Agree (more or less).

> Apropos, this reminds me that IF people go to LYNXCFG: or LYNXCOMPILEOPTS:
> with 'g'oto (not via a link from some known place), THEN there is no
> way to aplly the 'x' key.

At least you can go History Page and then press 'x' on the dedicated link.

>   Klaus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]