[Top][All Lists]

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

lynx-dev Reloading after Options page, LYNXCFG: (was: dev.15 patch 2)

From: Klaus Weide
Subject: lynx-dev Reloading after Options page, LYNXCFG: (was: dev.15 patch 2)
Date: Sat, 27 Nov 1999 15:12:35 -0600 (CST)

On Sat, 27 Nov 1999, Leonid Pauzner wrote:

> 26-Nov-99 21:30 Klaus Weide wrote:
> > On Sat, 23 Nov 1996, Leonid Pauzner wrote:
> >> 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).

But (now that I have looked more closely), why should lynx_edit_mode
play any role for this anyway?  It doesn't come into play for the Key-based
Options either.  For that, the conditions for filelist-related changes
used to be:

                (((HTfileSortMethod_flag != HTfileSortMethod) ||
                  (c != dir_list_style) ||
#endif /* DIRED_SUPPORT */
                  (show_dotfiles_flag != show_dotfiles)) &&
                 (!strncmp(curdoc.address, "file:", 5) ||
                  !strncmp(curdoc.address, "ftp:", 4))) ||

I notice now that the test for a changed dir_list_style has disappeared.
Was this intentional??  It seems it got lost in the big LYMainLoop
reorganization, somewhere between 2.8.3dev.10 and 2.8.3dev.12.  Tom,
was this an oversight?

Anyway, you can see reloading (but not end-to-end) was and is done when
show_dotfiles has changed and the URL starts with "file:" or "ftp:".
You seem to want a narrower check.  Good idea, but it wasn't part of
the old-style code either.

Also lynx_edit_mode was never the right flag for checking whether a doc
is a directory listing - it is only defined for DIRED_SUPPORT (therefore
not available at all for example on VMS, if I understand right).  Which
*is* the right flag?  There is none AFAIK.

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

Why should it mess up a given URL just because it is a directory?  It
shouldn't.  Actually, there is an intentional distinction between the
URLs "file://localhost/some/dir" and "file://localhost/some/dir/".
In the first case, an "Up to .." link is generated (may look different),
in the second it isn't.  (This may further depend on other things -
certainly NO_PARENT_DIR_REFERENCE - checked only with dired mode.)
This also affects the form relative URLs have to take in order to resolve
to the same absolute file URL - compare the SOURCE view of both forms
for the same directory.

I don't know why you talk about HTLoadAbsolute() - lynx_edit_mode is
generally set in HTFile.c (print_local_dir() as you mentioned).
(The 'lynx_edit_mode = TRUE' in HTAccess.c is for the case where a
directory listing is taken from cache.)

HTFile.c would also be the right place to set some kind of new flag
that isn't meant only for Dired, which would just signal 'this is a
directory listing'.  Also this could be handled in HTAccess.c in a
parellel way to what is done now for DIRED_SUPPORT (this probably means
inventing some new pseudo MIME type to use for HTAnchor_format(anchor)).

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

For the DIRED_SUPPORT case there already is a prev_lynx_edit_mode, set
in LYMainLoop.c for getting the lynx_edit_mode state (i.e. whether Dired is
in effect) across to LYNXKEYMAP generating code.  This could be reused
if desired (but would only work for Dired mode).

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

No, what shows up on the History Page is the "file:" URL, not a "LYNXCFG:"
URL.  'x'ing that would just reload the same contents from the file, not
regenerate it.


reply via email to

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