Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!mit-eddie!bbn!jr@bbn.com
From: jr@bbn.com (John Robinson)
Newsgroups: comp.emacs
Subject: Re: Bugs or features?
Summary: both
Message-ID: <35202@bbn.COM>
Date: 27 Jan 89 14:59:58 GMT
References: <TALE.89Jan26180715@consult1.its.rpi.edu>
Sender: news@bbn.COM
Reply-To: jr@bbn.com (John Robinson)
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 75
In-reply-to: tale@its.rpi.edu (David C Lawrence)

In article <TALE.89Jan26180715@consult1.its.rpi.edu>, tale@its (David C Lawrence) writes:
>bug:
>        shell.el does not check for su.  This I noticed when the
>following occured:
>/pawl_c/tale/src (3) su jwan
>Password:
>
>/pawl_c/tale/src (1) cd
>/pawl_c/jwan (2) [at this point, the echo area informs me that my
>directory is /pawl_c/tale, which it is not]
>
>It will correctly set itself if given a full pathname, but relative
>pathnames get corrupted.

This is a Unix bug [feature], basically.  There is no way for a parent
process to see the environment of its children.  Shell mode does a
half-baked attempt at tracking cd, pushd and popd commands, but it
really can't follow where the shell is connected other than by
completely emulating the shell (really!  Suppose you define a csh
alias for cd...  Try a cd to a place that you get to via a symbolic
link, then going back up with 'cd ..' a few times.  It will be lost.)

Now, in your example, there is a way for shell to do better.  It could
pick up the echoed pwd from your prompt line.  Perhaps you would like
to undertake the change to shell.el (shell-set-directory) to allow
shell to be "smart" under these circumstances?

>Bug(or feature?):
>        If you find-file for a filename ending in a . that does not
>exist, emacs creates the buffer, echos that it is a (New file) and
>displays Mark set.  This is pretty much normal behaviour except for
>a) the buffer is buried and b) Emacs seems to hang.

I don't have this problem.  You don't say what your version is, but
mine is 18.52 on a Sun 3/50, SunOS 3.4.

>  I've noted this everytime I use
>completion to find a file and I didn't hit space enough.  For example,
>I am used to hitting space twice for completion and the extension, so
>if I forgot and did sml[spc][spc] to get sml-mode.el, the above
>scenario would happen.

I don't have this problem either, because I use a souped-up minibuffer
completion function which, instead of executing find-file on the
incomplete filename, will pop up a window of completions when there is
more than one acceptable completion.  I also have a more complete
version of this package from David Gudeman <gudeman@ARIZONA.EDU>,
based on earlier work of Bruce Israel <israel@tove.umd.edu>, which I
haven't tried but would be willing to send you (but contact the author
first).  Here's my version (in my .emacs, probably from Bruce Israel
originZ ally):

(defun minibuffer-complete-exit-backup nil
   "Minibuffer completion, exiting on unique completion with backup."
   (interactive)
   (let (comp (complete t))
     (while (null (setq comp (all-completions
			      (buffer-substring (point-min) (point))
			      minibuffer-completion-table
			      minibuffer-completion-predicate)))
       (setq complete nil)
       (delete-backward-char 1 nil))
     (and complete (if (null (cdr comp)) (minibuffer-complete-and-exit)
			(minibuffer-complete)))))
;
(define-key minibuffer-local-must-match-map " "
     (define-key minibuffer-local-completion-map " "
	  'minibuffer-complete-exit-backup))

>Just food for thought.

Munch munch munch burp!
--
/jr
jr@bbn.com or bbn!jr