lynx-dev LYNX: options screen, .cfg, vs emacs' "edit options"

[David Combs]

That "show dot files" or whatever it is called.

Or anything else that is enabled/controlled via the .cfg file.

So here I am, running lynx, and either I want to just TRY
some feature to see what it does,

or I really NEED some feature for a minute or two.


What do I have to do?  
.  unless I have unix and job-control (^Z, fg), I must
     exit lynx.

.  edit the .cfg  (oh, better backup the prior copy --
    after all, just is just for a minute or two)

.  run lynx

.  use the feature.

.  exit lynx

.  cp -p backupfile lynx.cfg

.  run lynx

.  try to recreate the situation (history stack) I was in
    before.

What a pain!

And, it makes LEARNING lynx FAR more difficult -- makes it
really HARD to TRY things!

---

Now, look at Emacs.  Virtually ALL of the options that can
be set can be reset AT RUN TIME.

ITS option table is 3896 lines long!  (for 19.34)  (Newly, they
have a "custom" feature that breaks this up into subjects).

(That 3896 includes comments explaining the options -- each
explanation right there "at" the option)

---

Now, lynx doesn't have a really fancy built-in editor, which,
I guess I could say, Emacs does (what is the editor, and what
is everything else INCLUDING the kitchen sink -- not simple
to distinguish).

But lynx COULD enable reading in the .cfg file AGAIN, DURING
run time.  Would just override current settings.

That way, one could TRY a feature with almost no effort.
Just create another .cfg file -- or PORTION of one -- under
some other name, eg "enabledots.cfg", and there'd be
a command to read it in.

Also a "negative" command to read it in, but do the REVERSE
of what it says -- as easy way to turn OFF the tried feature.

(For safety, maybe this negative cmd would "wc" the file
first, or look it up and get its size, and ask for
confirmation if it was anything big)

---

For those items in the .cfg that for some reason cannot or
must not be resettable at run time, a simple one-line message
"foo-feature:  cannot reset this at run time"
would suffice.

----


The use of this rereading the .cfg or cfg-like file would
typically be via using ones favorite editor to collect-together
the things he wants to change THIS time into a SMALL .cfg-like
file, and then play with that.

For editors that don't have "append this stuff to this outside
file", like vi, you could just COPY ("Tuplicate") various ranges
of lines to the end of the file (a copy of the big .cfg), and
the delete everything before that duplicated stuff.  Easy, very
fast.

---

Anyway, we already have the code that reads the .cfg.  Seems like
all that needs be done is to call it again from somewhere else...

David