[no subject]

[Philip E. Agre <AGRE at MIT-AI>]

    Date: Friday, 7 May 1982, 11:05-EDT
    From: Daniel L. Weinreb <dlw at SCRC-TENEX>
    To: AGRE at MIT-AI
    Cc: BUG-ZWEI at MIT-AI

    It sounds as if you are asking for a new, complex behavior in the
    already rather complex algorithm for completion, in which you can type
    in the pathname with the components in either of the two orders and have
    completion somehow work anyway.  On the whole, I think we're better off
    as we are.

1. It's not two, it's n, for all the possible ways to type a pathname.
2. It's not more complex, it's just the proper behavior. The distinction
   between buffer names and pathnames is an unnecessary pain, since 90%
   of all buffer names are just petrified path names.
3. More precisely, it is a crock that buffer names are usually petrified 
   pathnames for (at least) these reasons: 
   (a) When a buffer contains a file, your mental pointer to it is a 
       pathname, and you should never be forced to point at something
       in some way different from the way you point at it in your mind.
       Presently C-X K (for example) does just this.
   (b) Pathnames behave differently from strings.  In particular their 
       printed forms have a much coarser equivalence relation.
   (c) Strings don't have sticky components, but pathnames do (when
       C-X K asks you where to go next and offers the default 
       SCCODE > AI: AGRE; try responding MC: or AGRE0;).
   (d) It ought to be an error to have two buffers that point to the
       same file.  This would be impossible if buffer names could be pathnames 
       but happens regularly now.  (We've talked about this one before.)
4. Specifically, the proper behavior is the following: a buffer name can
   be either a string or a pathname.  Some buffers' names really ARE pathnames
   and some others' really ARE strings.  Completion operates over the space
   of buffer names, just like it should and does now.  This is a perfectly
   simple behavior.

Implementation.  I assume we both distinguish between the complexity of the
behavior and the complexity of the implementation.  I don't know how
completion works; I hope that the space of completion is more or less a
parameter.  A possible problem is that completion might only know about
strings and so completion over pathnames would not be directly implementable.
The solution would be to have completion defined over different subspaces
(like the subspace of string buffer names in string format and the subspace of
pathname buffer names in pathname format) separately, and then poll all
possible subspace completions, winning if exactly one wins and losing
otherwise.  Completion over pathnames is to a first approximation the filling
in of pathname defaults.  It is possible that it's just pathname defaulting,
but you might also want to include (recursive?) completion of pathname
elements -- the string AGR could pathname-complete to AI:AGRE;SCCODE >,
FS:BATALI;AGROCK NOTES, or even I suppose AGR:<871.FOO>FILE.EXT if that name
were in the completion space -- defined by the pathnames which currently
define buffer names.  There is a definition problem when a complete component
is given, as in AGRE;.  In this case pathname defaults should be filled in
even if there are many AGRE; pathnames in the completion space.  It is quite
possible, though, that the only sensible definition of pathname completion is
simple pathname defaulting (so that you can't type in partial directory names,
say, and expect to have them complete in the pathname space.  This would make
me perfectly happy, and would also greatly simplify the implementation of
completion over (my definition of) buffer names.

It's not necessary to go around changing every function in Zwei to make them
know about the new implementation of buffer names.  All you need to do to make
completion work right is to try to parse the buffer name as the printed
representation of some format of pathname to define the pathname subspace of
the buffer name completion space.  Other things could work similarly I
suppose; perhaps you want to define a function EQUIVALENT-ZWEI-BUFFER-NAMES-P
of two buffer-name arguments and use this instead of EQUAL when, say,
searching through the list of buffer names looking for something, but on the
other hand perhaps every buffer name goes through buffer name completion
before being looked up, in which case it's easy.  Pant.