tale@its.rpi.edu (David C Lawrence) (01/27/89)
Three things lately; two are clearly bugs, but one might be a feature.
I'm not reporting them to the bug list because they're not major as
far as I can tell, and one of them isn't even in the std distribution.
Here they are:
bug:
free-space-checker hopelessly corrupts the modeline if
(suspend-emacs) is executed and the job is not brought quickly back to
the foreground.
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.
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. If the file does
exist, there are no problems. 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.
Just food for thought.
Dave
--
tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edutale@its.rpi.edu (David C Lawrence) (01/27/89)
By the way, one more ...
If I do "M-x man" followed by "5 netrc" (or any similar section
request), GNU Emacs will dutifully inform me that it is "invoking man
5 netrc". It then responds with the fact that there is no manual
entry for 5 netrc. This is falicious, as
(shell-command "man 5 netrc" nil)
will show, at least on my machine.
This is probably because the arguments to the process are being passed
as one string rather than seperate ones.
The details:
GNU Emacs 18.50.2 of Sun Oct 30 1988 on imagine.pawl.rpi.edu
(berkeley-unix)
Dave
--
tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edujr@bbn.com (John Robinson) (01/27/89)
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
jr@bbn.com (John Robinson) (01/27/89)
In article <TALE.89Jan26222711@consult1.its.rpi.edu>, tale@its (David C Lawrence) writes: >If I do "M-x man" followed by "5 netrc" (or any similar section >request), GNU Emacs will dutifully inform me that it is "invoking man >5 netrc". It then responds with the fact that there is no manual >entry for 5 netrc. This is falicious, as >(shell-command "man 5 netrc" nil) >will show, at least on my machine. > >This is probably because the arguments to the process are being passed >as one string rather than seperate ones. But you asked the question wrong. ^H f man <SPC> tells us: manual-entry: Display the Unix manual entry for TOPIC. TOPIC is either the title of the entry, or has the form TITLE(SECTION) where SECTION is the desired section of the manual, as in `tty(4)'. So you should have said M-x man <SPC> netrc(5) <RET> >The details: >GNU Emacs 18.50.2 of Sun Oct 30 1988 on imagine.pawl.rpi.edu >(berkeley-unix) That's better. Maybe the find-file bug was fixed by 18.52. Feel like getting the new distribution? 18.52 was out before yours was built :-] -- /jr jr@bbn.com or bbn!jr
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (01/31/89)
> From: tale@pawl.rpi.edu > > GNU Emacs 18.50.2 of Sun Oct 30 1988 on imagine.pawl.rpi.edu (berkeley-unix) > > What happens is that when I resume emacs, the string to display > free space has mutated from a nice "97%" to > "97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J97%^J" > (ad nauseum) > > Now it might eventually wind itself all the way back down, but it > hasn't in my experience. Then again, I don't sit around waiting for > it to happen. Ok, I tried it on a Unix machine which supports suspend-emacs (18.52.22, berkeley-unix). When I fg the job again, I do get "97%^J97%^J97%^J97%^J..." in the mode-line (actually, in my case it's "55%^J55%^J55%^J55%^J..." instead, thankfully :-)). However, this does not happen with the display-time string. The free-space-checker-string corrects itself when it is next updated (see free-space-checker-interval). Now, free-space-checker is modelled after display-time, so I don't understand why this should happen with one and not the other. However, looking at the code for the display-time-filter, I notice the curious comment: ;; Desired data can't need more than the last 30 chars, ;; so save time by flushing the rest. ;; This way, if we have many different times all collected at once, ;; we can discard all but the last few very fast. (if (> (length string) 30) (setq string (substring string -30))) ... (setq display-time-string string) I suspect what is happening is that while Emacs is suspended, the output from the process is collected up into one large string, to be processed when Emacs resumes as if the output was that one string (instead of several individual strings, each waiting to be processed). This looks like an Emacs bug to me. A workaround for this would be to change free-space-checker-filter to nullify the free-space-checker-string if its length is > 9 (thus producing no output in the mode line). The correct free space will be displayed when the free-space-checker-string is next updated. (defun free-space-checker-filter (proc string) "Filter for free-space-checker-process. Removes trailing newline, if any, and puts the string into the modeline." (setq free-space-checker-string (if (> (length string) 9) "" (concat " " (if (char-equal (string-to-char (substring string -1 nil)) ?\^J) (substring string 0 -1) string)))) (force-mode-line-update)) One could use a trick like display-time-filter uses to search down the string for the last piece of output, but it doesn't seem like it's worth the effort unless you really need to know the free space right that instant. -- Ashwin. ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin BITNET: Ram@yalecs