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: 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


reply via email to

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