Re: lynx-dev new command format

[Philip Webb]

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 `:',
>> which then expects an explicit written-out lynxactioncode,
>> with easier keymapping -- eg in  .lynxrc  -- by the user.
> are you saying Screen does *not* have a language for commands
> typed ad the ':' prompt?  When I look at the man page, I see
>    aclchg usernames permbits list
> to
>    zombie [keys]
> and there is also a description of the syntax rules:
> 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.

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.

> 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.
 
> Your language has the advantage it is simple & not difficult to implement.

excellent!  so at worst, it adds a few lines to the source.

> it would be wasting the ':' key.

no: `:' isn't bound to a lac (at least, by default).
 
> 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 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;
moreover, many ordinary users may have access to  lynx.cfg
without having the time/skill to learn how to change key-bindings there.

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

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

turning to the question of terminology & lac listings:

> I invented the terminology 'lynxactioncode' and 'lynxkeycode' 9902
> in the thread "Keys, an attempt to understand", see there for gory details.
> I've stuck with the terms since then, at least in code comments
> and some lynx-dev messages.  Some others seem to have picked them up.

no problem with your terminology, which is an improvement.

> other terms in various places were too ambiguous or used inconsistently.
> 'function' (in lynx.cfg)  == 'lynxactioncode', more or less.
> Sometimes also called a 'keyboard command' or a 'keystroke command'
> or just 'command', all these terms can be found in the UG.
LV> what we need to do is update the user's guide, man page, lynx.cfg

clearly, like so much in Lynx, this terminology "just growed"
due to rapid expansion beyond all expectations in the Age of Heroes.
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.

>> so is there anywhere a complete non-repeating listing of `functions'?
> 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.
> LYKeymapCode enum in the second half of LYKeymap.h is non-repeating
> for any given compilation.  Ignore the conditional #define lines.

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

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

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto