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

[Klaus Weide]

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.
> 
> If you so much concerned about lost possibilities, make it
> configurable from Options page -

Why should *I* have to do so.  *I* tried to give you an answer to a
question you asked (although I don't claim it is the definitive
answer) - "what is the logic".  Now it seems you turn around and say
you didn't really care about the question after all.  It's up to
somebody else to deal with problems that may follow from your patch?

> and anyway, using "reload lynx.cfg"
> option, my patch makes -prettysrc changable at runtime.  Yet another
> reason *for* my patch.

As has been discussed recently, "reload lynx.cfg" is not in a finished
state.

I could take your patch in two ways: (1) You just want to share this
little change with others, who may want to apply it to their own code
if they wish. (2) You submit this as a change you want to see included
in the code by Tom.

In case (1), you'd have no argument from me.  My responses assume that
case (2) applies, and your arguing in terms of "reasons *for* my
patch" supports this assumption.  In that case, you *should* care a
bit more about effects of your patch on other users - including those
who are not savvy about "reload lynx.cfg" (or lynx.cfg at all).

> >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.
> 
> It is not as if we are running of bits for additional keyactions.  ;-)

If you think that is a good idea, then I suggest you make a patch for
that.  So far, the patch we are talking about is the one which you sent,
which - as it stands - does not address the concern.

> >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.
> 
> Whoever does *this* can recompile the code with my patch applied ;-).

This doesn't make any sense.  Why should someone affected by a
consequence of your patch have to recompile with your patch?

And no, many users who may suddenly find themselves surprised by '\'
suddenly not acting as expected can NOT just recompile lynx.  Nor
should they have to.

The text you added to lynx.cfg:

+# If PRETTYSRC is set to TRUE, Lynx will do syntax highlighting and hyperlink
+# handling in source view
+#PRETTYSRC:FALSE
+

gives no warning to the installing admin (or maybe packager) that
making this TRUE will make normal SOURCE display (and saving to disk,
forwarding by mail as described in UG) impossible for his users
(unless they override it with their own lynx.cfg - if they can).

> You propose a reason which looks pretty similar to security by
> obscurity.

Huh?

Your patch propagates behavior that has to be explicitly requested with
a command line option to behavior that may be always turned on.  (And
you didn't make -prettysrc into a toggle that could be used to override
the lynx.cfg setting.)  You don't care for documenting this.  It seems
to me you are the supporter of obscurity here.

Yes, it should have been documented in the UG how -prettysrc changes
SOURCE behavior now.  But users who invoke lynx with some special flag
should not be too surprised if that flag changes lynx's behavior (and,
as a command line option, -prettysrc is at least somewhat documented
in the places where these are listed.)  This is not the same as users
surprised by a change in a global lynx.cfg file which may not be under
their control.

You could try to address these questions in a new patch (e.g. add text
to the UG, extend comments in lynx.cfg).  You could say you don't have
the time and ask someone else to do it.  You could at least acknowledge
this as on open concern.  Those would all be reasonable responses IMO.
What irks me is that you seem to completely shrug it off instead, but
still - if my picking of (2) above was right - want to see your patch
included by Tom.

  Klaus