lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [PATCH 2.8.3.dev4] Make prettysrc available from lynx.cfg


From: Klaus Weide
Subject: Re: lynx-dev [PATCH 2.8.3.dev4] Make prettysrc available from lynx.cfg
Date: Fri, 6 Aug 1999 19:42:38 -0500 (CDT)

On Thu, 5 Aug 1999, Vlad Harchev wrote:
> On Fri, 6 Aug 1999, Klaus Weide wrote:
> > I always thought of -preparsed as something that no one would (or should)
> > enable on a permanent basis to replace regular SOURCE mode.  After all
> > it doesn't just give a different rendering of the same old source, it
> > tries to show the source after lynx has premasticated it.  The same may 
> > not be exactly true for the -prettysrc variety of source display.
> 
>  May be (but it would be useful if it was bound to special key so user will be
> able to see -preparsed view and either normal or pretty without restarting
> lynx). Providing the ability to chose one of 3 views in the 'O'ptions menu 
> can 
> compensate the things.

Some things are prehaps best left for commandline option only.  So far
I still think that applies to -preparsed.  Or possibly allow change in
'O'ptions screen for the current session only (not seaved), but that
would only complicate matters more.

Most users can invoke a separate lynx process.  Even arrange to do that
form within lynx (e.g. via EXTERN), if it's for some frequently used
purpose.  And in this case of more-or-less obscure -preparsed I am
not that much concerned about making the last bit of functionality also
available for anonymous users or others than cannot or will not use
command line options. They also can't do -force_html or -mime_headers, for
example.

> > Note that there is a different confirmation prompt for the 'P'rint menu,
> > at least for "Mail the file", if the 'P' is invoked from -preparsed
> > SOURCE.  The idea is that a user sending the putative source to himself
> > (or somewhere else) should be reminded that no, this isn't the original
> > source.
> 
>  I didn't find this (can you provide a sequence of keypresses and emphasis the
> difference in the texts) - may be I misunderstood.

Start lynx with -preparsed, view a HTML doc, do '\', 'p', activate "Mail the
file", you should get a prompt

   Viewing preparsed source.  Are you sure you want to mail it? (n)

(but only the first time when doing this in a session - since so far the
"preparsed" mode can only be turned on per session, it seemed to make
sense to limit the extra warining this way.)

> > An additional complication is that -preparsed also modifies the handling
> > of non-interactive -source.
> 
>  Is this intentional? If no, is this bad?

It was intentional.

[ ... ]
>  I gave the exact list of options that seems to me should have 'O'ptions
> equivialents (corresponding .lynxrc settings are under question).

your list was:
 -force-empty-hrefless-a
 -prettysrc
 -preparsed
 -justify
 -force-html
 -short-url
 -sticky-inputs
 -verbose

Of those, -verbose is already handled as someone else pointed out.
-force-html as implemented applies only to the first file, it doesn't
make much sense as anything else than a command line option. -preparsed
should be only a command line option, but you could convince me otherwise
(or just send a patch, I don't plan to resist endlessly [unless that
hypothetical patch introduces real problems...]).  About -prettysrc 
I don't know.  I'm not really opposed to making it a lynx.cfg setting
in some way, especially if it can be made more "real"-SOURCE-like,
if it is documented.  -sticky-inputs is still waiting for a name change
(and alternative code from me...), so hold it for a bit.
-force-empty-hrefless-a is ugly as hell :) [yes, I *do* think it's
uglier than -nonrestarting_sigwinch :)], and I think [if it's rally
a good thing to have...] it should be named -<something>-name-anchors,
for consistency with BOLD_NAME_ANCHORS.  Re -justify we were having
some discussion about making it more than a two-way switch, it's still
an open topic.

> > > > It is not as if we are running of bits for additional keyactions.  ;-)
> > > 
> > >  '|' is free for this (shift-\ - sounds very attractive) or Meta-\.
> > 
> > What, you want to take '|' away from LYK_PIPE? :)
> 
>  I'm so pessimistic about implementation of that functionality (I mean I
> afraid I won't have time to do it in the nead future - may be somebody else?)

Having two kinds of SOURCE view keys seems like overkill.  I think
most people will want to use either the one or the other of the
alternatives as "their" SOURCE view, normally.  And think of the
details: you have to give them different names.  Different statuslines
to distinguish them (may be a good idea anyway).  What does '|' do
when invoked from the '\' screen, or in which kind of view do you end
up after the sequence '|', '\', '|'.

And I *am* somewhat serious about reserving '|' for some pipe-like
functionality - even if nobody does it withing the next two years,
if anyone ever does implement some pipe functionality needing a key,
'|' will be a natuaral choice.

> > Meta-stuff isn't currently mappable for LYK_stuff in general.  I think.
> 
>  I didn't check it either.

Well I should know :).  But there were some patches from Ilya that I
haven't really looked at yet.  But the basic limitation of Meta-stuff
to be (mostly) for line-editing use must still be there.

> >[...] 
> 
>  Seems it's easy to add missing docs and document all possible drawbacks.

It's easier to ask for it when a relevant change occurs than at some
later point in time, hence my nagging.

   Klaus


reply via email to

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