[MUD-Dev] Clients

[Shawn Halpenny]

On Wed, 14 Jan 1998, Caliban Tiresias Darklock wrote:

> Sometime at or around 03:52 PM 1/13/98 +0000, I personally witnessed
> Matt Chatterley jumping up to shout:
> >On Tue, 13 Jan 1998, Shawn Halpenny wrote:
> >> 
> >> I would consider a toggleable vi-mode for the command line
> >> practically a necessity.  Actually, a number of useful features
> >> from shells would be nice:  
> >
> >Hmm. I'm not sure exactly what you mean by 'vi' mode (one which
> >responds instantly to keypresses in a char-by-char mode rather
> >than typical line based approach?).  
> 
> I think what he's saying is he wants command mode and input mode --
> sort of like in vi, you're either inputting to the file (the MUD in
> this case) or controlling the editor (the client). I don't know that
> I'd completely agree with this idea, as it seems sort of backward;
> after all, you could probably do just as well with a separate command
> line altogether for the client. There's also the possibility that he
> wants the command line to have the same *syntax* as vi. If that's what
> he's asking for, then I have to kind of wonder what good the majority
> of vi's commands would be in a MUD client.

Anyone who has used bash or ksh in vi mode knows exactly what I'm referring
to.  Essentially, take the majority of the single-line editing and movement
commands from vi and stick them into the command-line editing facilities of
the client.

> But here's my two cents. I think one of the biggest mistakes people
> make in saying 'this is what I want in a client' is to say they want
> this specific feature like this specific program, instead of saying
> what they want in terms of ability. Nobody wants a 'macro feature like
> EMACS' -- they want the ability to define and execute their own
> commands.

For the most part, I think you're correct.  But in this case, I _do_ want
command line editing "like vi".  I have progressed past (or just plain
bypassed?) the point of saying "I want a convenient way of entering commands."

>           In a character-mode environment like UNIX or DOS, then yes,
> that probably means a macro feature, and may mean something very like
> EMACS. But in modern windowing environments like the Mac or Windows or
> X, that macro facility would likely bear *no* resemblance to EMACS,
> probably taking the form of a user-defined button bar with a 'command
> wizard' behind it. I think we get too bogged down in what we know and
> what we're used to, rather than letting the programmer take our needs
> and build them into a useful product...

That is to say, if you know how to use your favorite editor 'vi'
inside and out and there's nothing you can't do with it, wouldn't you
benefit from putting that same interface on the front of something
whose innards accomplish the same thing, but doesn't necessarily look
like what you're accustomed to?  There's a learning curve whenever
you change the interface and if I don't have to learn what keys I
need to use to edit a command line, I can get into the game much more
quickly (perhaps that should read "conveniently") than if I have to
figure out that pressing "Ctrl-End" clears to the end-of-line instead
of "D".  Sure, it's probably documented somewhere, but if I fire up that
client and discover off the bat that all my vi knowledge just magically
works, I don't even need to bother reading the dox.

Yes, we get bogged down in what we know and what we're used to.  I am
perfectly content to let the programmer take my needs and build me a
useful product.  If I told him "I want to create macros" and he comes
back with a GUI and a bunch of buttons, fine.  But if I said "I want
vi command line editing" and he comes back with a GUI and buttons,
I'll never use the product.

>                                         it's pretty common in my day
> job to go in to build a program for a customer, then see them point to
> some program and say "...and that's what we want it to do". If that's
> what you want it to do, then what are *we* here for? Go buy that.
> Obviously, that's NOT what you want it to do, so what is it missing? 
> 
> I think if we all just went 'I want to have this ability', it would go
> a lot better than 'I want the client to do this, this, and this'.

But what of the people who _do_ know precisely what they want?  Are you
going to force them to throw out their old interface knowledge and make
them learn the new one?

>                                                                    If
> you want the client to have a dual-mode command line, the question to
> be asked is *why* you want that. I think it's pretty clear that you
> want to be able to control the client itself from the same interface
> where you're controlling the MUD.

Nope.  I don't give a whit if I can control the client from the same
command line I control the MUD.  The dual mode is _only_ for editing the
line.  I'm either in edit mode where what I type is inserted into the line,
or in command mode where I can move about the line, delete words,
sentences, or what not.  I am perfectly content to have to move the mouse
if I need to select some menu, but I want my chief interface to the MUD to
be through that command line.  All the GUI gives me is client control
options.  That's what _I_ want.  That's probably not what some newbie
player to that MUD wants.

>                                    You don't want to switch windows or
> futz with a mouse or anything, you want to enter your commands right
> there on the command line where you type the MUD commands, and you
> don't want the client intercepting your MUD commands or your client
> commands getting sent to the MUD. There are a lot of ways to handle
> that, and a dual mode command line is only one of them. My immediate
> thought is to use the / key, as in you type '/client-command' to
> execute one client command in a series of MUD commands, or just '/' to
> enter a sort of client command shell -- everything is a client command
> until this shell is exited or turned off. This could be done by
> several
> methods; '//' is sensible, as is another '/', a '\', '/exit' or just
> 'exit', or 'quit', 'end', a period on a line all by itself, a
> control-D, etc. I selected the '/' because that's what TinyFugue uses,
> and that's what most of the really serious MUD players I run into are
> using, but it's quite simple to make this a configurable parameter.
> The
> mechanics themselves are irrelevant, provided when you hand it to
> someone for testing they find that it's easy to work with and doesn't
> take a year to adjust to. But I think Shawn's saying he wants a robust
> command set in the client more than anything.

That is almost entirely correct (or at least I want to be given the
primitives to script my own commands) except you left out the all-important
vi-mode editing bit.  Would that be a make-or-break,
do-I-use-or-scrap-this-client sort of thing?  Probably not.  But every day
I sit down in front of my terminal at work, the nominal 5 shells I
have open are all in vi mode.  If I don't have to do a mental context
switch when I decide to MUD, all the better.

--
Shawn Halpenny