[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev dev.15 patch 2
From: |
Klaus Weide |
Subject: |
Re: lynx-dev dev.15 patch 2 |
Date: |
Fri, 26 Nov 1999 21:30:05 -0600 (CST) |
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.
> > * In LYNXMESSAGES: page, number recent statusline messages in historic
> > order,
> > starting with 1 for the oldest. This should make it more obvious that
> > they
> > are listed latest-first. Add "(No messages yet)" text if there are no
> ^^^^^^^^^^^^^^^^^^^
> This probably a rare case, is there an example?
There's the trivial case: start lynx as `lynx LYNXMESSAGES:'.
(Why not - LYNXMESSAGES: makes for a fine 'startfile', it's always
there if lynx is new enough - something you can't even say about `.'...)
There's the more normal case: start lynx as `lynx /path/to/a/file.html'
(with a local file, not a directory), then immediately see the
LYNXMESSAGES, they will be empty.
> > messages. Removed generation of invalid <pre>.
> > * Use a temporary file instead of the normal .lynxrc file for saving and
> > restoring current settings in reload_read_cfg(). This avoids unexpected
> > side effects of lynx.cfg reloading (LYNXCFG://reload action), i.e.
> thanks.
The need for saving user preferences *to a file* should probably avoided
in the first place. But that would be a more radical change of the
reloading logic than I was willing to make now.
> > silent modification or first-time generation of .lynxrc contents.
> > In principle this should make reloading of lynx.cfg usable for accounts
> > that don't allow saving of personal settings (i.e. option_save
> > restriction,
> > implied by -anonymous) if other restrictions don't forbid it; but
> > currently the option_save restriction is still obeyed for saving to
> > the temporary file (so that reloading of lynx.cfg is prevented).
>
> > * 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
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?
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.
Klaus