Re: lynx-dev new command format

[Klaus Weide]

[ quotes snipped throughout ]
On Thu, 8 Jul 1999, Philip Webb wrote:
> 990707 Klaus Weide wrote: 
> > 990706 Philip Webb wrote:
> >> Lynx needs to adopt the system of Screen, Vi & other software,
> >> having a basic `command mode' introduced eg by `:',
> > are you saying Screen does *not* have a language for commands
> 
> no, i'm wasn't saying Screen/Vi don't do that,
> but while it might be useful later to add such capability to Lynx,
> it isn't needed as part of getting started with a command mode.

And I wasn't saying any of the more complex stuff has to be *done* now
if you add a command mode.  But it needs to be thought about.  You
acknowledge that "it might be useful later to add such capability", it
should be obvious then that the 'getting stated' should not be done in
a way that prevents that.  Well, no code change can absolutely prevent
another one, one can in theory always backtrack, but that should be
avoided if it is avoidable.

> > You have actually designed a language here.
> > It's just so simple and limited it's practically useless.
> > In your language, every command consists of exactly one verb.
> > If Screen and Vi were so limited,
> > the ':' command mode would probably not exist at all.
> 
> perhaps it's a question of working style:
> mine is to divide tasks into simple steps
> & get each one right before tackling the next one.

I don't disagree with that style!
But if a 'step' is to be part of a bigger 'task' in a meaningful
way, one has to think at least a few steps ahead.  At least check
whether the first step lands you right in front of a wall, with
no next step possible (except back- or sideways (and sideways only
if it's not a dead-end)).

Perhaps you have already concluded, or are just assuming, that
extenting your simple one-verb language to a more useful one would be
no problem.  In that case I'd like you to make that thought process
explicit.

I put more emphasis on this (extensibility), because IMO, without
being extended, your prompt-with-minimal-language is practically
useless.  It doesn't make sense to me *except* as a step to a more
useful command prompt.  But even if one disagrees with that (as you
obviously do so far), the concerns about dead-ends should still be
valid.

> > Your language has the advantage it is simple & not difficult to implement.
> 
> excellent!  so at worst, it adds a few lines to the source.

Uhmm, I didn't say it is *that* simple.  It certainly isn't only a
'few lines' if you want anything more than just entering a string,
if you want TAB completion or recall.

But go ahead, I'll try to help you locate the pieces you'd have to put
together. :)

> > it would be wasting the ':' key.
> 
> no: `:' isn't bound to a lac (at least, by default).

Making ':' invoke a command prompt would mean (1) implementing
the function, (2) assign it to a new lynxactioncode LYK_SIMPLECOMMANDPROMPT
(or whatever), and (3) binding the lynxkeycode ':' to it.  Or how
else would you do it?

> > there is a possibility of running out of 'default' keys,
> > if everyone thinks every new function has to have a default binding.
> > there will be more lynxactions that will not be mapped by default.
> > I doubt any individual user has a serious problem of finding keys
> > for the subset s/he actually actively uses.
> 
> we are getting closer to running out of default keys for all lac's
> & not all users want -- or are able -- to alter bindings in  lynx.cfg .

If they just don't *want to*, then obviously they don't really want to
use the new/alternative/"minority-use" functions.

If they are not able to, that may be for several reasons:
- They are restricted intentionally.
   - that's between them and their sysadmin.
- It's too difficult to figure out.
   - So explain it more clearly.
- It's too bothersome.
   - So make it simpler.
- Don't want to use / copy / read through lynx.cfg because it's too
  big.
   - Use new INCLUDE facility to separate out the KEYMAP part in an
     extra file.
- Any other reason?
   - can be addresses in some way that's more effective and useful than
     a minimal ':' prompt.

> > If the user has no way to access lynx.cfg,
> > s/he would probably also be restricted from a ':' facility.
> 
> that doesn't follow: there is no security problem with `:' itself,
> provided Lynx continues to restrict access to dangerous lacs;

Maybe.  Let's see whether Henry has something to say.

> moreover, many ordinary users may have access to  lynx.cfg
> without having the time/skill to learn how to change key-bindings there.
(see above)

> > I can see it would be convenient to test a new command
> > in your minimal ':' prompt, but that doesn't really test the command
> > as it was meant to be used & would be too inconvenient for serious use.
> 
> it has arisen as a problem more than once recently (as i pointed out)
> that the innovator has needed to assign a key to his/her new lac,
> creating a kerfuffle as chickens find their favorite perches threatened.

I don't recall any event where the innovator needed to assign a key
by default.  Some did that, but it was never *necessary* for the
programmer to make that decision for the user.

I don't think you have 'pointed out' any cases that are different.
If you think so, please point again.

> having a basic command mode via `:' would avoid that problem,
> leaving only the simpler need for consensus
> whether to give the new lac a default binding & if so what.

Having the KEYMAP feature in lynx.cfg avoids that problem,
leaving only the simpler(? :)) need for consensus
whether to give the new lac a default binding & if so what.

Your proposed minimal command prompt doesn't solve any problem that
isn't already solved in a better way.

> >> the 2nd part -- making it easier to alter keybindings -- can wait a while.
> > Maybe the second part is really the first.
>  
> surely, it's a more complex job to add this to Options, tho' feasible;
> it would be more obviously useful, but would also require a list of lacs
> so that users would know what they could choose to bind & at that point
> some users may start asking: "how can i use an unbound lac?"

"Make it easier to alter keybindings" doesn't necessarily mean "add it
to the Options Screen".  It could mean instead "make it easier to edit
KEYMAP lines" in lynx.cfg or a lynx.cfg-like file (possibly INCLUDEd?).

Of course there should be a list of implemented lacs ('key commands' to
the user) somewhere, whether with or without your command prompt.

The answer to that hypothertical question would of course be
"you cannot, but you can easily bind it as follows:...".

> turning to the question of terminology & lac listings: [...]
> it's time documentation was cleaned up to use KW's terms (dropping `lynx').
> no, don't look at me: i've done my share previously,
> but grew tired of the eggs & tomatoes which seemed to be the reward.

Since you have dished out "eggs & tomatoes" yourself on occasion, 
you shouldn't go into martyr mode so easily.

> >> so is there anywhere a complete non-repeating listing of `functions'?
> > [...]
> yes, thanx: there are  72  regular lacs +  7  for directory editing,
> more than enough to start thinking about revising the way they are used.
> the simple list should be included in Users Guide, eg
> 
>   SOURCE      toggle source/presentation for current document
>   RELOAD      reload the current document
>   PIPE                pipe the current document to an external command
>   QUIT                quit the browser
>   ABORT               quit the browser unconditionally

Including them in the UG would be a Good Thing, glad you're thinking
about it. :)

> BTW is there any reason for this order rather than eg alphabetical?
> yes, i KNOW the  2  lists have to correspond ...

Not in principle, it "just growed".  LYK_UNKNOWN should stay at the
beginning though.  The numbers "1" .. "2" may need to stay where they
are, or at least stay consecutive and in the same order, something
somewhere may depend on it.  Before the list changed from #define
to an enum, there was a good reason to keep the stuff that is only
used conditionally (esp. dired keys) near the end, that reason doesn't
apply any more.  But it still makes sense to keep things together
that belong together, so they can be ifdef'd out en bloc.

   Klaus