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

[Leonid Pauzner]

5-Aug-99 06:03 Vlad Harchev wrote:
>> >
>> >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 am not Klaus, but I see wrapping of long lines in -prettysrc mode,
which will corrupt "print to email/file/etc." output currently
(there is no feature associated with LY_SOFT_NEWLINE logic in prettysrc mode).
It would be nice if "pretty" source being printed to a file will give
exactly the same output as "normal" mode. (well, upper/lower caseing of tags
may be assumed as advantage so not a problem).

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

>  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

-verbose already implemented in options menu.

Seems "SOURCE_OUTPUT" may be another welcome item
(with the values NORMAL, PRETTYSRC, PREPARSED
not saved into .lynxrc at the moment).

As of more new options under "Document Layout" section
we may want to add a separate page with a number of other options
(historical_comments, etc) - anyone bother about expanding options menu
for several pages in length?

> 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)?

>> It is not as if we are running of bits for additional keyactions.  ;-)

>  '|' is free for this (shift-\ - sounds very attractive) or Meta-\.

perhaps (but then "\" should give a NORMAL layout in this case,
for consistency).