Re: lynx-dev new command format (was transport)

[Klaus Weide]

On Wed, 7 Jul 1999, Philip Webb wrote:
> 990706 Klaus Weide responded: 
> > 990706 Philip Webb wrote:
> >> Lynx needs to adopt the system of Screen, Vi & other software,
> >> having a basic `command mode' introduced eg by `:',
> >> which then expects an explicit written-out lynxactioncode,
> >> with easier keymapping -- eg in  .lynxrc  -- by the user.
> >> then ALL commands would be accessible to everyone by using `:',
> >> but users could choose their own personal keybindings as they wished.
> > Once you introduce a `:', you're introducing a whole new language.
> 
> i don't believe so: see below.
> 
> > I assume allowing typing just one lynx action by name would be pointless.
> 
> i want to allow any lynxactioncode to be entered explicitly ...
> 
> > You want to combine several & pass parameters to them.
> > You want to control what happens in case of errors.
> > Then come conditional constructs and so on.
> 
> ... but no more than that on the Lynx interactive command-line.
> 
> > You may not want all of that now, but to some varying degree,
> > that seems to be what Screen, Vi & other software do,
> > they all have their own (not-so-little if we include emacs) mini-language.
>  
> that's not what Screen & Vi do; i DON'T want to imitate emacs ... (grin)

So are you saying Screen does *not* have a language for commands typed
ad the ':' prompt?   When I look at the man page, I see commands expressed
in a language, from
   acladd usernames
   aclchg usernames permbits list
to
   zombie [keys]
   defzombie [keys]
and there is also a description of the syntax rules:
       .....     A command's arguments are separated by  tabs  or
       spaces,  and may be surrounded by single or double quotes.
       A `#' turns the rest of the line into a comment, except in
       quotes.    Unintelligible   lines  are  warned  about  and
       ignored.  Commands may contain references  to  environment
       variables.  The  syntax  is  the  shell-like  "$VAR  "  or
       "${VAR}". Note that this causes incompatibility with  pre-
       vious  screen versions, as now the '$'-character has to be
       protected with '\' if no variable  substitution  shall  be
       performed.  A  string  in  single-quotes is also protected
       from variable substitution.
It just happens that this is the same language that is used in the
program's configuration (or initialization) files.  It also happens
that actions bound to keys are expressed in this language, and that
you even use the language to bind keys to actions expressed in the
language.

The commands you can give in that language are much more powerful than
what you can do with simple keys.  The same is true for Vi.

> at present, Lynx listens for a keystroke -- eg  a  or  m  -- ,
> which it then interprets as a lynxactioncode according to keybindings
> --  add_bookmark  or  main_menu  -- , which the user can vary in  lynx.cfg :
> you are more familiar with the source, so you can much more easily tell me
> where in the program it happens; Lynx then acts on the lynxactioncode.

(If you have a concrete question (where *what* happens?), I'll try to
answer.)

> generally, this works well enough, but problems arise from time to time
> about default keybindings & about possibly running out of keys to bind.
> 
> if Lynx were to imitate Screen (are you familiar with it?),
> it would continue to listen for keystrokes,
> but the bindings would be more accessible to users via  .lynxrc
> & hopefully thro' the Options Form (tho' that's not essential).

This is quite a different topic.

> there would also be a single special keystroke, probably `:',
> which would tell Lynx `the user is about to enter an explicit command';
> Lynx would then accept & parse the input line to get a lynxactioncode,
> eg `add_bookmark', spelled out just like that (without quotes).

You have actually designed a language here.  It's just so simple and
limited that it's practically useless in my opinion.  And you haven't
thought about making it extensible at all.

In your language, every command consists of exactly one verb.
If Screen and Vi were so limited, if the ':' prompt didn't offer
much more power than simple commands bound to keys, then the ':'
command mode would probably not exist at all.

Your language has the advantage that it is simple.  It's not
difficult to implement.  That's the only advantage I can think
of.  And it would be wasting the ':' key.  :)

> what actually needs coding is simply the new `:' keystroke
> & Lynx's ability to offer & parse the input line,
> parallel eg to the input line for URLs with `goto' now.
> this would allow new &/or minority-interest commands to be added
> without being forced to decide a default binding,
> obviously incl the recent issue you were debating about `t',

The 't' thing was made because it is more convenient to type 
than 'a' ... (confirm) ... 'r' (confirm).  Having to type it
as ':transport_bookmark' (return) makes it completely pointless
(even if the action verb were shorter).

There is noting inherent in making "new &/or minority-interest commands"
that forces the author of such to decide a default binding.  If someone
wants to use the command, it can be bound, whether there is a default
binding or not.

> tho' ALL lynxactioncodes would be accepted via this mechanism
> & they would be properly listed in Users Guide.

Yes, there is a possibility of running out of 'default' keys, if everyone
thinks that every new function has to have a default binding.  I doubt
that any individual user has a serious problem of finding keys for the
subset of keys he/she actually actively uses.  I think we can expect
that there will be more lynxactions that will not be mapped by default.
That makes it more pointless to list all bindings in the Users Guide.
(For some of those actions, it seem more useful to tell the user about
the binding on the statusline, as for textarea editing.)

Currently available lynxactioncodes are no necessarily all in the UG,
but they are listed in lynx.cfg.  (I hope none are implemented but not
mentioned in either lynx.cfg or the UG.)  I can see that it would be
somewhat 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,
and would be too inconvenient for serious use.  So just do the mapping
in lynx.cfg (as long as there is no other mechanism for settin key
mappings at runtime, at least.  Maybe Leonid's reloading-of-lynx.cfg
works for this (or will one day)).  If the user has no way to
access lynx.cfg, we should assume that he/she probably is not meant to
have access to it and use a modified copy, and in that situation he/she
would probably also be restricted from a ':' facility if one were
implemented.

> the 2nd part -- making it easier to alter keybindings -- can wait a while.

Maybe the second part is really the first.

> have i made it clearer?

Yes, it has become clearer that we disagree...

I though it would be obvious that Screen's, Vi's ':' is far different
from what you want.  Anyway, if you want to implement your minmal
language idea feel free (also to ask for pointers), but I hope you
would at least think about doing something more useful with ':'.

   Klaus