Buffer naming

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

    dlw at SCRC-TENEX

[Btw, note that AGRE-X is just where I send my self-CC's.]
    Date: Saturday, 8 May 1982, 00:43-EDT
    From: Robert W. Kerns <RWK at SCRC-TENEX>
    In-reply-to: The message of 7 May 82 13:28-EDT from Philip E. Agre <AGRE at MIT-AI>

    . . .

    1) Return doing completion (as happens now for buffer names), pathname
    completion, and pathname defaulting are incompatible when taken
    together.  Eliminating return doing completion would eliminate the
    problem, and although I would find that somewhat irritating, such an
    inconsistancy causes several other problems as well, so maybe it should go.

To be clear what we're talking about, let me state my proposal again.
All I am proposing is a way that Zwei should pretend that it works.  If it can
be made to pretend to work that way using a patch or kludge or some other
underlying theory, then fine.  So I'll talk about "how it works" when I mean
"how it pretends to work".  The way I want Zwei buffer names to work is that
they should be able to be either pathnames or arbitrary strings.  The user
should have a model in his/her head according to which buffer names are either
pathnames or arbitrary strings; otherwise s/he will become confused.

I'll be more precise by proposing a specific algorithm that buffer name
completion should (pretend to) use.  For the sake of argument, let us identify
"pathname completion" with "pathname defaulting".  The proposal then is that
(so far as the user sees) a buffer name is either a pathname or an arbitrary
string.  So define completion over strings in the existing manner (to a first
approximation) and define completion over pathnames as pathname defaulting
(without any aspect of string completion).  Then, given completion spaces A
and B, define completion of a string S over A+B in the following manner:
 (1) if S completes uniquely in A according to the completion method for A, 
     then let X be S's completion in A, otherwise let X be the token FAIL.
 (2) if S completes uniquely in B according to the completion method for B,
     then let Y be S's completion in A, otherwise let Y be the token FAIL.
 (3) to compute S's completion Z in A+B,
     let Z = case <A=FAIL?,B=FAIL?> of <Y,Y>: FAIL, <N,N>: FAIL, <Y,N>: B,
                                       <N,Y>: A.

Note that this algorithm for complete(S,A+B) is associative and commutative,
and that, most importantly, it will never provide a completion unless there
really is exactly one available.  This avoids surprises.

[Footnote: What it means for there to be exactly one completion in a
particular "atomic" subspace (one which has a completion algorithm primitively
defined) might be a little hairy.  For example, LONG-H might have completions
LONG-HAIRY-FUNCTION and LONG-HAIRY-FUNCTION1, but you'd probably want to say
that the first is the proper "unique" completion.  What if those two things
were in different subspaces?  I claim that my algorithm's behavior (which is
to fail) is the correct one, since different subspaces should refer to
cognitively different universes, in which the two candidates are not related.
However, the alternative behavior, that of checking whether the algorithm's X
and Y bear some sort of substring relation, is probably easy enough to define
properly.]

[Footnote: The following conditions on completion algorithms ought to hold:
 (1) A is a subset of B => (complete(S,B)=FAIL => complete(S,A)=FAIL)
 (2) A = set-union(B,C) => (complete(S,A+B)=complete(S,C))
I believe that my suggested algorithms satisfy these.]

I am rather fond of Return completing, or, rather, I don't like having to hit
Altmode to make completion happen, since I usually use completion to be able
to enter a command whose completion I know very quickly, and the Altmode key
is out of the way and hard to hit quickly and reliably.  Given that completion
will fail unless there is exactly one legal completion in the entire
completion space (which, again, is composed of two subspaces) I don't see why
Return completing causes any problems or why getting rid of it would solve any.
Maybe there are problems I don't know about.

    2) What you propose really is too complex.  In part this is due to your
    explanation, but let's look for the essential features you're looking
    for and see what the simplest way to get them is.

OK.

    2a)  Would a scheme where user input is first parsed to see if it is a
    pathname, and then converted to a buffer name do the trick?  Maybe the
    other way around?

If that's an implementation issue, then I don't care particularly.  One way of
taking (2a) is that the completion(S,strings+pathnames) algorithm I described
is implemented indirectly, with buffer names all being stored internally as
strings.  If this gives the desired behavior then fine.  Various problems
might arise with other interpretations though.  If you have a buffer BUFFER-2
and and pathname AI:AGRE;BUFRAN >, then BUF should probably fail to complete
(by the principle of surprise avoidance).  In general, it's probably not a
good idea to give priority to one of the completion subspaces.  A much less
worrisome problem is that the information about whether a given buffer name is
"really" a string or a pathname might get lost.  Although any algorithm should
handle this correctly (the current method of assuming its a pathname if it can
be parsed as a pathname is not quite right), the screw cases (buffer names
that look like pathnames but really are strings) are rare.

    3)  What should M-X Rename Buffer do?

My first-pass answer is that I don't think that Rename Buffer is a an
operation you should ever have to do, so I don't use it.  Why would you ever
want to rename a buffer?  One reason might be that you want the effect of C-X
C-W without actually writing the buffer out or creating a real file out in the
world.  I can't think of any cases in which one would want to rename a buffer
to a buffer name that is a string and not a pathname, but then there might be
some and in any event one does't want to make an operation illegal just
because one can't make up a theory for it.  I assume that Rename Buffer's
prompt has buffer name completion.  The problem (ah I see) comes from the fact
that you might want to enter a buffer name that is a pathname that is not yet
known to the system.  Notice though that completion where you're explicitly
entering something that the machine doesn't know about yet (like Rename
Buffer) is conceptually quite a different thing from completion where you're
explicitly entering something that it does know about (like C-X B).  This
indicates that a different notion of completion is called for.  Perhaps the
best thing is to say (Default Completion) or some such thing instead of
(Completion), the only difference being that you must type Altmode to get
completion -- and the only sort of completion you get is pathname defaulting.
I don't know for sure.

    4) How many different representations of a pathname are there?  This
    relates to logical pathnames, pathnames with different equivalent
    namings, etc.  Is it reasonable to just give buffers n different names,
    where n is a reasonably small number like 2 or 3?

Again, if this is an implementation issue then I don't much care.  If it's
done by enumerating printed representations of pathnames, all of them should
be included, not just the 2 or 3 most likely or something.  Of course, the
fact that an enumeration is happening shouldn't be visible.  Also, the
distinction between the buffer name "really" being a string and "really" being
a pathname should be made, but under this implementation the reason is (so far
as I can see) only the remote screw case I mentioned.

    5) How about a minibuffer command called Buffer as Pathname, which when
    you wanted to pick a buffer name with pathname completion, or with
    defaulting, you'd do S-F or something?  Remember the distinction between
    ^X^F and ^XB (when the file is already loaded) is which space it
    operates over.  Is it a good thing to mix these two things into a single
    method of input, or can we SAY what method of naming we're using?

If the separation can be made naturally and each method is roughly equally
easy to get at (as with C-X C-F and C-X B) then I say fine.  But there are
cases in which the user is just asked "which buffer pal?" without being
offered a choice of format.  What one might do is say that (say) Line gives
pathname buffer name completion where Altmode gives string buffer name
completion (or string-representation-of-buffer-name completion, in which the
canonical printed representations of the pathnames are included in the
completion space).

Hope this helps.     - phIl