pa1343@sdcc15.ucsd.edu (pa1343) (02/03/89)
Beware! Emacs 3.9 is dangerous. If you don't name a file it can't save it until a name is given. Worse yet, in mess-dos if a disk is write protected, the program can't write to it and bombs with Abort, Retry, Just Give it up. These bugs need to be fixed. Suggestion: if file does not have a name, ASK for one. Second, check for write protect in mess- dos and for permission in UNIX and allow alternate save paths. -- +------------------------------------------------------------------------------+ | John J. Marco -- pa1343@sdcc15.ucsd.edu | |uunet!altnet!vsi1!ubvax!ames!pasteur!helios.ee.lbl.gov!nosc!ucsd!sdcc15!pa1343| +------------------------------------------------------------------------------+
nwd@j.cc.purdue.edu (Daniel Lawrence) (02/03/89)
In article <1028@sdcc15.ucsd.edu> pa1343@sdcc15.ucsd.edu (pa1343) writes: >Beware! Emacs 3.9 is dangerous. If you don't name a file it can't >save it until a name is given. Perhaps reading the manual would help here. First off if you would have stated your edit session by typing: emacs <newfilename> Then uEMACS would have supplied you with a named buffer and had been ready to write your file out. Second, the command ^X-^W (wriite-file) would have prompted you for a file name. >Worse yet, in mess-dos if a disk is write >protected, the program can't write to it and bombs with Abort, Retry, Just >Give it up. First, intercepting the DOS critical error handler is generally not done with MSDOS programs and can cause some very serious problems if anything goes wrong. Second, MSDOS 3.0 and above has another option on this prompt, (F)ail. If you type this, MSDOS will return a failure on the open and EMACS will report "[Can not write file]" on the command line. > These bugs need to be fixed. Suggestion: if file does >not have a name, ASK for one. Second, check for write protect in mess- >dos and for permission in UNIX and allow alternate save paths. > Write protect problems in MSDOS? Did you consider pulling out the disk, unwrite-protecting it, re-inserting it and hitting "R" for retry? Under UNIX MicroEMACS does check for protections and will return proper error messeges for that. Also, as always, macroes can be used to do anything you care to like this: 23 store-macro !if &seq $cfname "" set $cfname @"File name to save to: " !endif save-file !endm bind-to-key execute-macro-23 ^X^S bind-to-key execute-macro-23 FND (or bind-to-key execute-macro-23 FN0 under the new 3.10 bindings) >-- >+------------------------------------------------------------------------------+ >| John J. Marco -- pa1343@sdcc15.ucsd.edu | >|uunet!altnet!vsi1!ubvax!ames!pasteur!helios.ee.lbl.gov!nosc!ucsd!sdcc15!pa1343| >+------------------------------------------------------------------------------+ I am unhappy that someone would post a note to usenet decrying the dangers of a program of which they have probably not opened the manual to. Any tool or program can be mis-used if you do not attempt to learn how to use it. If the place you recieved MicroEMACS from did not supply a manual, tell me and I will mail you one. Daniel Lawrence (317) 742-5153 nwd@j.cc.purdue.edu The Programmer's Room Fido 1:201/10 (317) 742-5533
usenet@cps3xx.UUCP (Usenet file owner) (02/03/89)
in article <1028@sdcc15.ucsd.edu>, pa1343@sdcc15.ucsd.edu (pa1343) says:
$ Keywords: File naminig and write protect.
$
$ Beware! Emacs 3.9 is dangerous. If you don't name a file it can't
$ save it until a name is given.
Of course, if a name isn't given it can't open it. Personally I've
had no problem typing ^X^W to write out the file instead of ^X^S
$ Worse yet, in mess-dos if a disk is write
$ protected, the program can't write to it and bombs with Abort, Retry, Just
$ Give it up. These bugs need to be fixed. Suggestion: if file does
$ not have a name, ASK for one. Second, check for write protect in mess-
$ dos and for permission in UNIX and allow alternate save paths.
Since my hard disk isn't write protected I haven't run into that one.
I don't think it is that hard to realize that you have just put in a
write-protected floppy and are trying to edit on it. I suspect you
should be able to say "ABort" and use ^L to restore your screen. Then
use ^X^W.
I wouldn't call either one of these bugs. If either of them bothers you
so much and you think it should be fixed, hack the source code and
submit the patches to Dan Lawrence. The Microemacs code isn't that
complex to modify.
I've been using MicroEmacs under both MS-DOS and UNIX for a couple of
years now and have never found anything in it I would call dangerous.
John H. Lawitzke UUCP: ...rutgers!mailrus!frith!fciiho!jhl
Michigan Farm Bureau ...decvax!purdue!mailrus!frith!fciiho!jhl
Insurance Group ...uunet!frith!jhl
"My other computer is an IBM RT Model 135"pa1343@sdcc15.ucsd.edu (pa1343) (02/04/89)
Thanks for the suggestions. What I think happened is that I forked a Shell do Mess-Dos and cd'ed to the b: drive. Then when I was back in emacs, I thought I was in c:/work/john and was instead on b:/. I shouldn't have this problem on UNIX because I wouldn't edit a no-permission file in the first place, and if I forked a shell in UNIX, it would not alter theEmacs directory location. As to the file name problem. Maybe it's not a bug, but it would be nice if the program were to ask for a filename if none existed instead of giving an error message. Then again, I am relatively new to emacs and there may be a different write comand which does this. If I find time between classes and uEmacs 3.9 compiles on Turbo C 1.5, I will think about adding the two changes I suggested. This is not certain though. By the way, I have uEmacs 3.8 running on UNIX V.1.2 and I was wondering if somebody may have ported the DOS .emacsrc to vt100 format. Thanks again. -- +------------------------------------------------------------------------------+ | John J. Marco -- pa1343@sdcc15.ucsd.edu | | ...!uunet!ucsd!sdcc15!pa1343 | +------------------------------------------------------------------------------+