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

[Klaus Weide]

On Thu, 5 Aug 1999, Vlad Harchev wrote:
> On Thu, 5 Aug 1999, Ilya Zakharevich wrote:
> 
> > >> This makes prettysrc available from lynx.cfg
> > >> .
> > >> Btw, what is the logic?  Why some options cannot be set from lynx.cfg?
> > >
> > >Turning prettysrc on is more than "enabling" it.  It overrides
> > >the way '\' acts on text/html files, therefore it makes the normal
> > >SOURCE display unavailable.  If you 'P'rint from this 'source' view
> > >(e.g. to disk, to mail), you don't get in general valid text/html
> > >source.
> 
> Klaus, did you mean wrapping of tag names and attribute names here?

I meant
(1) wrapping of any source text lines that are longer than the display
    width minus 1.  I am not aware of any wrapping concerns that are
    specific to tag names and attribute names, for -prettysrc.
(2) Insertion of "[nn]" if "Links are numbered" is enabled, which makes
    all hrefs invalid.

> > If you so much concerned about lost possibilities, make it
> > configurable from Options page - and anyway, using "reload lynx.cfg"
> > option, my patch makes -prettysrc changable at runtime.  Yet another
> > reason *for* my patch.
> > 
> > >This is IMO a good reason for not making this configurable to be
> > >the default '\' behavior.  I was thinking along these lines when
> > >I implemented -preparsed, but only as a command line option.
> > 
> > I do not see this as a reason to make it not configurable.  If you
> > want the standard '\' behaviour *in addition* to fancy one, provide an
> > additional Lynx-keyaction, and bind some key to the action.
> 
>  As for me (as the author of prettysrc mode), IMO it would be better to be
> able to select from one of three source view modes via lynx.cfg settings (if 
> it existed):
> 
>  NORMAL
>  PREPARSED
>  PRETTY
> 
> ,rather than TRUE/FALSE (so the name of option can be SOURCE_MODE)
>  The reason for why there is no any configuration setting corresponding to it
> is the following:
>  when I was implementing it, -preparsed existed, and Klaus didn't add any
> configuration setting to lynx.cfg to control it, so I didn't add configuration
> of psrc mode too.

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.

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.

An additional complication is that -preparsed also modifies the handling
of non-interactive -source.

> To Klaus: If you think there are bugs in the implementation of psrc mode,
> please tell about them explicitly (rather than saying that it's almost
> broken).

Well, the (1) and (2) above were so obvious to me that I thought that you
must be aware of them, and that you obviously did not intend pretty source
view as a full replacement for regular source view.

>  And it would be good if someone added support for following switches in the 
> 'O'ption menu:
>  -force-empty-hrefless-a
>  -prettysrc
>  -preparsed
>  -justify
>  -force-html
>  -short-url
>  -sticky-inputs
>  -verbose
> 
> And to Klaus: 
>  As I understand you, you mean that it will be impossible to request 'old'
> source view if PRETTYSRC:TRUE is inserted in lynx.cfg (and seems this is your
> most valuable objection)? If yes, then type of -prettysrc should be changed to
> the one that allows such change (may be PARSE_SET)?

Actually, it seems I was wrong about one thing: using -prettysrc=off, it
should still be possible with Ilya's patch to turn it off from the command
line.  So no change of -prettysrc is necessary to make this possible.
(It could be turned into a toggle, but that would be more incompatible to
its previous meaning.)

So the major objection is missing documentation.  Apart from that,
I question whether it makes sense to make all those command line flags
into things that can be set also in lynx.cfg and the 'O'ptions screen.
Maybe it does for most, but not all.  I thing you would not want to make
-trace into a lyn.cfg-settable thing.  I think -preparsed is somewhat
similar.  And -prettysrc may or may not be similar.

> > 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 don't know whether it's a good idea to have to keys for two kinds
of source view.

Meta-stuff isn't currently mappable for LYK_stuff in general.  I think.

> > >If lynx can be configured to make prettysrc the default '\' behavior,
> > >then there is also a much stronger reason to fully document the
> > >variant behavior in the Users Guide.  Your patch makes it possible
> > >to configure lynx in a way that breaks normal '\' behavior for
> > >unsuspecting users, without any warning.
> 
>  This Klaus' note is correct only if packager set PRETTYSRC to TRUE. IMO
> packagers can make much more harm (by seting stupid defaults to lynx.cfg
> settings) - and the one we are discussing is not harmfull (provided the user
> is able to override settings in lynx.cfg with commandline).

Not just packagers, but also installers and system admins.  Multiuser
shell environments still exists, it's not like everyone runs lynx
on their own personal machine today.

With the patch as given, and admin installing a new version for his
users is easily tempted to turn it on - it says "Lynx will do highlighting
and hyperlink handling in source view", sounds like a good thing to
provide for his users.  There is no mention of any drawbacks or how to
override it.

   Klaus