csrobe@ICASE.ARPA (Charles S. Roberson) (10/07/87)
For those who are interested i was able to compile and like MicroGnuEmacs v 1.b on a Atari 1040 ST using MWC. The only quirks were: 1) i had to convert getn.s from as68 (whateverthat is -- Alcyon?) to Mark Williams format using as68toas (sp?) and i just had to ignore the gem startup file (gems.s). 2) there were several unused variables (h,k,m,n,l,...) that the compiler protested about but still compiled. 3) make bombed when i tried to make a make file for mg. (i think the OBJ macro was too long.) Anyway, it seems to be in good shape. Now, a minor complaint. I had mg in split screen and when i scrolled the bottom screen the buffer information line (or whatever you call it) scrolled with the text then jumped back down to where it belongs. after about three or four pages this became a bit irksome. (by the way, this was on a color system). Is there a way to stop this? Now, a minor comment. A friend of mine gave me a two-minute run through of why he loved mg on his Amiga. I saw it and was impressed. I really like the fact that it had menus and the way the directories were shown through menus on the menu bar. Are there any plans to put an (optional) GEM interface around mg on the ST? I realize that emacs doesn't need a menu system to run (and shouldn't) but there are just some things (like the directory stuff) which would make working with mg that much nicer. Thanks for mg, -chip ------------------------------------------------------------------------- Chip Roberson ARPANET: csrobe@icase.arpa 1105 London Company Way BITNET: $csrobe@wmmvs.bitnet Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe ------------------------------------------------------------------------- *(*please note change in UUCP address ^^^^^^^^^^^ seismo is gone*)*
minow@decvax.UUCP (Martin Minow) (10/09/87)
Chip Robertson writes about MicroEmacs: > >Now, a minor complaint. I had mg in split screen and when i scrolled the >bottom screen the buffer information line (or whatever you call it) >scrolled with the text then jumped back down to where it belongs. after >about three or four pages this became a bit irksome. (by the way, this >was on a color system). Is there a way to stop this? Yes, but it's not trivial. You have to dig into the bottom layer of the screen handler, replacing the VT52-flavored scrolling code by code that calls vro_cpyfm() to scroll the screen directly. If you can do this, you have demonstrated a good understanding both of the internal structure of MicroEmacs and of Gem. Good luck. Martin Minow decvax!minow
nwd@j.cc.purdue.edu (Daniel Lawrence) (10/09/87)
Chip Robertson writes about MicroEmacs: > >Now, a minor complaint. I had mg in split screen and when i scrolled the >bottom screen the buffer information line (or whatever you call it) >scrolled with the text then jumped back down to where it belongs. after >about three or four pages this became a bit irksome. (by the way, this >was on a color system). Is there a way to stop this? What mg is attempting to do here is optimize its display update speed so that it is more efficient when used at low baud rates on serial terminals and slow machines. This is done by some clever and rather intricate code in the display driver update function (in display.c). While I am not certain, I believe there is probably a global variable set when mg opens up the terminal which tells the driver if it has "scrolling" capabilities. Find this, turn it off, and mg shouldn't scroll anymore. If this is not the case, the other thing to look for is something called a "cost" array or structure which lists the time cost for different operations. Turn the cost for scrolling very high and it will stop scrolling. Daniel Lawrence (317) 742-5153 UUCP: {ihnp4!pur-ee!}j.cc.purdue.edu!nwd ARPA: nwd@j.cc.purdue.edu FIDO: 201/2 The Programmer's Room (317) 742-5533
sandra@utah-cs.UUCP (Sandra J Loosemore) (10/10/87)
I've already replied to the author of this via e-mail but since there seems to be general misunderstanding as to what is going on, I will try to clear it up. MG's display code is based on Gosling's algorithm, which was really designed to work with terminals that support scrolling regions, like the VT100. The ST's Cconout() function doesn't support scrolling regions, but (like an H19 and several other terminals), it does have insert line and delete line functions. You can simulate scrolling regions with these functions, but it does give you that "bouncing mode line" problem. Making the cost of scrolling very high would probably make it act even dumber, like a real VT52 where you have to do a clear-to-end-of-page and redraw *everything* to get the same effect. The real solution is to fix MG to bypass Cconout () and manipulate the screen directly. I've been given some code to do just that and if I have time, I'll try to get it integrated into the next release. -Sandra Loosemore sandra@cs.utah.edu, sandra@utah-cs.uucp
trb@stag.UUCP ( Todd Burkey ) (10/10/87)
In article <168@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >calls vro_cpyfm() to scroll the screen directly. If you can do this, >you have demonstrated a good understanding both of the internal structure >of MicroEmacs and of Gem. Good luck. Also, if you do this, be sure to set_screen (logical) to an off screen buffer before doing the blit, then blit to it, write out the new line (top or bottom, depending on the scroll direction), rewrite the bottom status line, and finally set_screen (physical) to the offscreen buffer...sounds messy, but it eliminates the blur effect on color monitors. Take a look at the multi-lingual editor if you want to see what updating just the current screen will do to you (a demo version was floating around the bbs's recently). This method also makes paging look instantaneous (and a lot easier on the eyes...and yes, all that work can be done faster than using the vt52 calls (at least in MWC 2.0). Keep in mind that this operation will run faster with the blitter, so don't make paging or scrolling too fast :-). -Todd Burkey trb@stag.UUCP PS...one other thing I noticed when I was doing the scrolling manager on my editor...If you are shifting the page sideways by more than 4 characters (I use the shift left/right arrows to shift the page back and forth by 20 chars at a shot), just redraw the page one character at a time...it is much faster than blitting sideways (kind of makes sense because of the way the screen is layed out).
gsender@rmi.UUCP (Gerd Sender) (10/13/87)
Your idea sounds good, but will it run with the Mega ST and future versions of ROM tos? Will it use the features of the blitter? Will it be possible to redirekt the output when I use the MT-C-Shell? Gerd
a360ad@blake.acs.washington.edu (Gnurr) (04/10/89)
Anybody know where i can get the docs for GNU emacs editor? THanks. -kevin a360ad@blake.acs.washington.edu