Mail Archives: djgpp/1996/10/07/21:31:54
From: | mschulter AT mach1 DOT mpu DOT com ()
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Emacs and MSDOS graphics
|
Date: | 7 Oct 1996 23:02:48 GMT
|
Organization: | MP Unlimited, Inc.
|
Lines: | 32
|
Message-ID: | <53c26o$5on@news.mpu.com>
|
NNTP-Posting-Host: | mach1.mpu.com
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Here's a curious "anti-bug" report of a situation where Emacs 19.31
appears to outperform its own documentation by successfully running
a shell command requiring user input in the course of the command.
Basically what I'm doing is editing a PostScript file in Emacs and from
time to time running a macro for a shell command invoking an MS-DOG
batch file which:
(1) Calls Image Alchemy PS, a 32-bit DOS PostScript interpreter, which
renders the PostScript file as a 200 dpi .GIF image; and
(2) Calls PICEM, a graphics viewer which displays the file, using the
arrow keys to scroll (no redraws required) and ESC to exit back to Emacs.
For some reason, the arrow keys work fine within PICEM, and ESC gets
me back to Emacs -- even though this involves user input during a
shell command.
Normally, of course, Emacs behaves as advertised: I can't successfully
run my own C programs as shell commands if they require scanf input,
for example, or run a different graphics viewer that starts out with
a text-mode screen (the result, as expected, is the equivalent of a
system lockup). For these tasks, I use the normal C-z.
Anyway, being able to toggle between editing and graphics mode
previewing within Emacs is a great bonus. If the quirk that makes
this work can somehow be helpful for other applications, or for
future development, I would be even more delighted.
Most appreciatively,
Margo Schulter
- Raw text -