[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: RMS at MIT-AI, dlw at SCRC-TENEX
- From: Philip E. Agre <AGRE at MIT-AI>
- Date: Fri ,7 May 82 13:28:00 EDT
- Cc: AGRE-X at MIT-AI, BUG-ZWEI 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
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.