Re: trivial patch 3

[Bill_Chiles@CHILES.SLISP.CS.CMU.EDU]

Note, I agree with Miles's proposed behavior, and I think it would be
better and more consistent as he suggests; however, his proposal is desired
behavior only, but some of us seem to think he has proposed a patch or
implementation that works with our current pathname conventions.

I thought I should clear up any misunderstandings that I'm not
bucking something Miles proposed in terms of implementation, but I'm
waiting to see this or design one myself.  I'm not taking the time to do
this design thinking myself today.

In case it helps, I thought I'd send out the proposal for the current state
of affairs:
   This message proposes the changes to the pathname representation,
   NAMESTRING, and PARSE-NAMESTRING.  File specs whose names contain "dots"
   (or periods) but not types will be represented by a pathname with a name
   field containing the entire name and a type field containing the empty
   string.  NAMESTRING will be changed to forego outputting a trailing dot
   when its pathname argument has an empty string type field.
   PARSE-NAMESTRING will be modified to favor dot file specs over type
   specs; that is, ".lisp" will be parsed as the name ".lisp" and the type
   "".  Furthermore, PARSE-NAMESTRING when given ".foo." will produce a
   pathname with a name field of ".foo." and a type field of "".  Whenever
   a trailing dot in a file spec is not followed by anything else, it is
   consumed by the name field, and the type field is the empty string.  As
   one last example, "foo." would be parsed to produce a pathname with a
   name field of "foo." and a type field of "".

   This provides a better understanding of Unix-oid dot files, and it has
   additional benefits of knowing a pathname does not have missing fields
   which means that merging with your prefectly valid dot file spec will
   not pick up defaults from some pathname with a non-nil name field.

Possibly, we only need to change our original idea/confusion about the
disadvantage/advantage of merging type information into pathnames whose
name was ".foo".  We could possibly only change the parsing to set the type
field to nil instead of the empty string.

I HAVE NOT YET THOUGHT ABOUT WHETHER THIS WORKS WITH THE DIRED STUFF OR
WHETHER IT BREAKS THE CURRENT WIN IN HEMLOCK.

Bill