koomen@rocheste.UUCP (09/04/83)
#R:sri-arpa:0:rocheste:-1:37777777600:2625
rocheste!koomen Jul 30 23:43:00 1983
From: Hans.Koomen
Yeah, I've often wondered about that wrap feature myself.
Here's my solution:
****************
(defun ; "HaKo 05-12-83"
(window-width 80) ; should be built-in a la (window-height) !@#$%!
(line-to-bottom-of-window curpos prevpos nextpos
lines2skip chars2skip physlines
(setq chars2skip (window-width))
(setq lines2skip (window-height))
(setq curpos (dot))
(line-to-top-of-window)
(beginning-of-line)
(setq nextpos (dot))
(setq physlines (+ 1 (/ (- curpos nextpos) chars2skip)))
(setq lines2skip (- lines2skip physlines))
(while (> lines2skip 0)
(previous-line)
(beginning-of-line)
(setq prevpos nextpos)
(setq nextpos (dot))
(setq physlines (+ 1 (/ (- prevpos nextpos) chars2skip)))
(setq lines2skip (- lines2skip physlines)))
(line-to-top-of-window)
(goto-character curpos)
(if (< lines2skip 0)
(scroll-one-line-up))))
****************
I use this function to force the last line in the shell buffer to stay
at the bottom of the window (simulating usual scrolling). Just in case
you wonder how: (process.ml)
****************
(defun
(pr-newline
(end-of-line)
(if (eobp)
(newline)
(progn com
(beginning-of-line)
(if (looking-at shell-prompt) (region-around-match 0)
(looking-at lisp-prompt) (region-around-match 0))
(set-mark)
(end-of-line)
(forward-character)
(setq com (region-to-string))
(end-of-file)
(set-mark)
(insert-string com)
)
)
(line-to-bottom-of-window) ; "HaKo 05-12-83"
(setq last-line (region-to-string))
(region-to-process (active-process))
(set-mark)
)
(shell
(pop-to-buffer "shell")
(setq needs-checkpointing 0)
(if (< (process-status "shell") 0)
(start-filtered-process "csh -i" "shell" "more-shell-stuff"))
; (start-process "csh -i" "shell")) ; "HaKo 05-12-83"
(local-bind-to-key "pr-newline" '^m')
(local-bind-to-key "send-eot" '')
(local-bind-to-key "send-int-signal" '')
(local-bind-to-key "send-quit-signal" '^\')
(local-bind-to-key "grab-last-line" "\e=")
; (local-bind-to-key "stop-shell" "\e\^Z")
(end-of-file)
(novalue)
)
(more-shell-stuff ; "HaKo 05-12-83"
(if (= (current-buffer-name) "shell")
(progn (end-of-file)
(insert-string (process-output))
(set-mark)
(line-to-bottom-of-window)
(sit-for 0))
(save-excursion
(temp-use-buffer "shell")
(end-of-file)
(insert-string (process-output))
(set-mark)))))
****************
I know, it's a crock. Enjoy, anyway!
-- Hans (Koomen@Rochester or ..!seismo!rochester!koomen)nrh@inmet.UUCP (02/10/84)
#R:dartvax:-65000:inmet:11400005:177600:454 inmet!nrh Feb 8 13:48:00 1984 We found the same problem -- the c-shell would log out when the terminal was in raw mode and you typed anything! The problem is in the c-shell code, which uses the parity bit as a "mark" that this character was "quoted". Unfortunately, the implementation bombs when the c-shell reads characters with the parity bit already on. I can't claim credit for finding the bug -- if it's not obvious to you from this, you could try sending mail to inmet!dwp.
tw@hpisla.UUCP (tw) (01/07/85)
I've used the Unipress EMACS on a PC-XT; it is pretty slow. Other problems
include:
(1) you can't edit a file bigger than 32k. They promised to fix this
"soon" a couple of months ago.
(2) for some reason the redisplay algorithm is really weird. When you
change the screen (say by paging down) it first draws all the new
characters, then deletes all the old characters. This wouldn't be
that annoying except that there is a noticable lag between the two
operations.
On the plus side, they did somehow get the "compile-it" function to
work, so you can do compiles and such and capture the output in a window.
Anyway, I find myself using mince for all but the most serious editing,
simply because of the speed. I understand it is much more reasonable on
a PC-AT. If I recall correctly it costs around $400 for binary, $1k for
source.
Tw Cook {hplabs, hp-pcd, hpfcla}!hpisla!tw or twc@hplabs.CSNET
(303) 667-5000x3724 HP Instrument Systems Lab, Loveland, COrs@mirror.UUCP (05/29/85)
we just brough V2.01 up yesterday. the only real problems so far seem to have been because of outdated .mo (MLisp Object) files. In particular, we're running both old and new emacs. Old emacs recompiles the new emacs mlisp files, because it knows they're out of date. New emacs doesn't seem to do this. What problems have you been having? we've got a fairly good local expert here -- he did a lot of hacking on V2 in a semi-official state. Maybe he can help you out. (I'd send you his name, and this whole thing privately, but I can't seem to get to you...) Overall, I'm impressed with this release. They did a great job on the conditional assembly (we're runnin on both the pyramid and the vax) and config.c. They also fixed a fair amount of bugs (e.g., the smail package). Then again, it's only been a day and a half... /rich$alz
matt@prism.UUCP (05/29/85)
/**** prism:net.emacs / mirror!rs / 11:40 am May 29, 1985 ****/
we just brough V2.01 up yesterday. the only real problems so far
seem to have been because of outdated .mo (MLisp Object) files.
In particular, we're running both old and new emacs. Old emacs
recompiles the new emacs mlisp files, because it knows they're
out of date. New emacs doesn't seem to do this. What problems have
you been having?
/* ---------- */
To clarify and expand on mirror!rs's comment, the .mo situation is
this: Gosling's v264 will look at .mo files produced by Unipress
2.01, realize they are out of date, and (silently) recompile the
mlisp sources to produce old format .mo files. When Unipress 2.01
tries to read the old format files, it does dump core.
This is actually a more subtle problem than it seems, if you have
users trying to use different versions of Emacs with overlapping
EPATHs. Periodically, someone here will try to invoke the old (264)
Emacs for some reason, trashing many of the .mo files in the maclib
directory. Then everyone else's new Emacs (Unipress) suddenly core
dumps the first time it tries to read a .mo that's been ambushed.
The situation is even worse if you have people using EACH OTHER's
private Emacs mlisp directories.
The moral is: don't even TRY for a smooth transition from one
version to another. Just have one or two people beta test Unipress
2.01, then dump it on people, with adequate guidance for them to
change over in one fell swoop.
There are some other circumstances that will crash Unipress Emacs:
in particular, typing "Meta-X line-number" will cause it to hang.
Also, I have found that typing "Meta-X set error-message-format %f %l
Error [0-9]*:.*" (the error message format the Lattice C
cross-compiler, also from Unipress, happens to produce) followed by a
"Meta-X parse-error-messages-in-region" will cause a core dump on a
Pyramid.
Another lesser gripe concerns the display code - Gosling's was smart
enough to use linefeed and reverse linefeed to scroll the screen up
or down by one line. Unipress, for some reason, changed the display
logic so that scrolling by even one line causes the entire screen to
be repainted from the top down. This is agonizingly slow and broken
behavior, but it seems possible to get around it by writing your own
compiled terminal description and linking it with Emacs. What you
do if you don't have source, I do not know.
Overall, though, Emacs 2.01 seems to have some real improvements
over Gosling's v264. The rewrite of process handling is especially
nice, as is the handling of error message formats. (No more piping
lint output through sed to make next-error grok the messages.)
-----------------------------------------------------------------------------
Matt Landau {cca, datacube, ihnp4, inmet, mit-eddie, wjh12}...
Mirror Systems, Inc. ...mirror!prism!matt
-----------------------------------------------------------------------------jrc@hpcnof.UUCP (08/31/85)
I have heard dreadful things about the PC/AT XENIX C compiler. Check in the net.micro postings (where I might have read them). Jim Conrad hplabs!hpfcla!hpcnoa!j_conrad
berger@datacube.UUCP (09/23/85)
/**** datacube:net.emacs / mit-eddie!rms / 8:51 pm Sep 16, 1985 ****/
From: Richard M. Stallman <rms@mit-prep>
/u2/emacs/dist now contains version 16.57, which differs from 16.56
in having fixes to all the significant bugs discovered since 16.56
came out. It is still a little experimental, and there may
possibly be a 16.58 in a couple of days. /u2/emacs/edist.tar is
also 16.57. I will prepare a set of diffs in a few hours.
/* ---------- */
And how, may I ask, do I access /u2/emacs/dist? It certainly is not
on my machine!
Bob Berger
Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644
ihnp4!datacube!berger
decvax!cca!mirror!datacube!berger
{mit-eddie,cyb0vax}!mirror!datacube!bergerrs@mirror.UUCP (10/14/85)
SINE: Sine Is Not Emacs
(MIT Architecture Machine Group)
EINE: Eine is Not Emacs
(MIT -> Symbolics Lisp Machine)
ZWEI: Zwei Was Eine Initially
(Symbolics "rev2" of EINE)
--
Rich $alz {mit-eddie, ihnp4!inmet, wjh12, cca, datacube} !mirror!rs
Mirror Systems 2067 Massachusetts Ave.
617-661-0777 Cambridge, MA, 02140figmo%atari@atari.UUCP (04/26/86)
In article <11600012@ccvaxa>, wombat@ccvaxa.UUCP writes: > > It looks like ^\ and ^^ (= ^~) are becoming the standard replacements for > ^s/^q. Unfortunately, ^^ is the magic cookie for the terminal concentrator > I'm connected to. Is a secondary standard emreging? (Are there any control > characters left?) > I've used ^XS and ^XQ even though they are defined as other things. One idea might be to allow ^\ to be another prefix. Another is to use ^CS and ^CQ; both are currently undefined, and both are similar to the commands you are trying to make up for. --Lynn -- Atari Corp. 1196 Borregas Ave. UUCP: vecpyr!atari!figmo Sunnyvale, CA ARPA: Lynn%PANDA@SUMEX-AIM (408) 745-2930 +---------------------------------------------------------------------+ | The opinions represented in this posting are mine. Any resemblance | | between these and my employer's opinions is purely coincidental. | +---------------------------------------------------------------------+
ron%brl-sem@brl-sem.UUCP (04/30/86)
> I've used ^XS and ^XQ even though they are defined as other things. > One idea might be to allow ^\ to be another prefix. Another is to use > ^CS and ^CQ; both are currently undefined, and both are similar to the > commands you are trying to make up for. The problem here is that there are ^X^S bindings, also, by just globally saying that whereever you would have used ^S use ^\ solves this problem as well. -Ron