deg@druhi.UUCP (GillespieD) (09/27/85)
When using Gosling's emacs, i notice that column 80 never gets used. When i have long lines, the last character displayed is in column 78, and column 79 has the '\' or '$' in it. Does anyone know why?
ericksen@unc.UUCP (Jim Ericksen) (10/02/85)
> > When using Gosling's emacs, i notice that column 80 never gets used. When > i have long lines, the last character displayed is in column 78, and column > 79 has the '\' or '$' in it. > > Does anyone know why? If your terminal has the automatic margin feature ('am:' termcap entry) it normally moves the cursor to the beginning of the next line after printing in column 80. Gosling emacs apparently is unable to deal with this behavior, and so sidesteps the problem by never printing anything in column 80. -- Jim Ericksen UNC Chapel Hill
chris@umcp-cs.UUCP (Chris Torek) (10/02/85)
> When using Gosling's emacs, i notice that column 80 never gets used. > ... Does anyone know why? Yes. Consider what would happen if the terminal has auto-margins and you write in column 80 (assuming an 80 column screen) of the last line. There are ways around this, but Emacs does not use them. (Though my termcap driver does check the "am" flag before deciding not to use the last column.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
erez@rsch.wisc.edu (Erez Levav) (10/04/85)
Some terminals have irregular behaviour in the last column. The VT100, for
example, will leave the cursor on the 80 column instead of advancing to the
next line. To avoid dealing with problems of this kind, the last column was
left untouched...
--
~
{> <}
Erez Levav __ ^ __
U of Wisconsin Computer Systems Lab / \
| />
arpa: erez@rsch.wisc.edu \/
uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!erezjbuck@epicen.UUCP (Joe Buck) (10/05/85)
In article <70@druhi.UUCP> deg@druhi.UUCP (GillespieD) writes: > >When using Gosling's emacs, i notice that column 80 never gets used. When >i have long lines, the last character displayed is in column 78, and column >79 has the '\' or '$' in it. > >Does anyone know why? I suspect you have a VT-100 compatible terminal. On many of these terminals, wrapping when reaching the end of line is broken; the cursor wraps but the last typed character doesn't, or vice versa. Pretending that the terminal width is 79 avoids a lot of these problems. What's worse, behavior at the end of the line isn't consistent from one VT1xx clone to another. -- Joe Buck | Entropic Processing, Inc. UUCP: {ucbvax,ihnp4}!dual!epicen!jbuck | 10011 N. Foothill Blvd. ARPA: dual!epicen!jbuck@BERKELEY.ARPA | Cupertino, CA 95014
guy@sun.uucp (Guy Harris) (10/06/85)
> >When using Gosling's emacs, i notice that column 80 never gets used. When > >i have long lines, the last character displayed is in column 78, and column > >79 has the '\' or '$' in it. > > I suspect you have a VT-100 compatible terminal. On many of these terminals, > wrapping when reaching the end of line is broken; the cursor wraps but the > last typed character doesn't, or vice versa. It is arguable that the VT100 method for handling column 80 is *better* than the normal method. On normal terminals with end-of-line wrap, if you put something in column 80 the cursor goes to column 1 of the next line; if the cursor is already on the last line the screen scrolls up to accomodate this move. This means that a full-screen program *cannot* use column 80 on the bottom line of the screen, or at least has to do an annoying amount of repair to clean up after that scroll. If you put a character in column 80 on a VT100, and end-of-line wrap is enabled, the cursor's motion to line N+1 column 80 is deferred until the next character is to be displayed. The trouble with this is that some display code isn't prepared to handle this, and that it's not clear where the cursor "really" is under these circumstances. On the VT100, you can turn end-of-line wrap off, which is a more reasonable mode for all full-screen programs except those (like "vi" and EMACS) which handle wide lines by wrapping them rather than by having a window into the text which can be shifted horizontally (I did a screen editor which had such a shiftable window, and prefer it to the "vi"/EMACS style of wrapping). Guy Harris
barmar@mit-eddie.UUCP (Barry Margolin) (10/07/85)
One of the respondents mentioned that Emacs can't deal with :am:.
Whether or not Emacs understands this, it would still have to skip the
last column on terminals with "automatic margins". This is because most
terminals with this feature scroll the screen if a character is output
to the last column of the last line on the screen. Since only 79
columns can be used on that line, only 79 columns may be used on the
rest of the screen.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmarchris@umcp-cs.UUCP (Chris Torek) (10/08/85)
In article <17@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes: > ... [some terminals] scroll the screen if a character is output to the > last column of the last line on the screen. Since only 79 columns can > be used on that line, only 79 columns may be used on the rest of the > screen. The final conclusion here is not really true, and I have thought about `fixing' the problem in our local Emacs; it would be relatively trivial---simply set the number of characters to width - (autowrap && line == length ? 1 : 0) ---but there is no real incentive since most of our local terminals are automatically set to non-wrap mode while running Emacs. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
gnu@l5.uucp (John Gilmore) (10/08/85)
In my experience the "am" capability in termcap causes more hassles and screen glitches than it saves. Often (as on the VT100), whether or not the automatic wrap is enabled is set by a dipswitch -- which is NOT accessible to the computer -- so it requires TWO termcap entries and requires the user to pick which one (or diddle their dipswitches to match the termcap entry). And with other terminals many people who create termcap entries don't notice whether am should be off or on -- if indeed their terminal manual tells them. All this could be avoided if programmers would simply avoid assuming anything about the cursor position after writing in column 80. Avoiding that assumption means having to send a set-cursor-position after you write to column 80. In many cases you would have done that anyway; in the rest, the three or six bytes are worth it in lack of hassle to the user (no bad termcap entries or screen garbage). I fixed "vnews" to ignore "am". Please do it to YOUR software. (Note that writing in column 80 of the last line is hazardous. I like the trick of writing the char in column 79 and sliding it over with insert- character, but that takes work. It's easier to just avoid painting it.)
barmar@mit-eddie.UUCP (Barry Margolin) (10/09/85)
In article <1776@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >... I have thought >about `fixing' the problem in our local Emacs; it would be relatively >trivial---simply set the number of characters to > > width - (autowrap && line == length ? 1 : 0) Well, I am not familiar with the internals of Gosling Emacs, only Multics Emacs. Its redisplay-line routine is independent of the actual screen line, so it only has the global line length variable to deal width. I am not defending this (I didn't write it), just explaining my reason for assuming that Gosling Emacs assumes a rectangular screen. >---but there is no real incentive since most of our local terminals >are automatically set to non-wrap mode while running Emacs. How do you deal with the different ways that terminals handle the no-wrap case, with respect to relative cursor motion after entering a character in the 80th column? On the VT100, if you enter a character into column 70 then send a BS or CUL (CUrsor Left escape sequence) you end up in column 70, but if you do the same thing in column 80 you end up in column 79. On other terminals (e.g. Honeywell VIP7800 series), there is a "phantom" column 81, which can contain the cursor but not a real character, and that is where the cursor goes after a character is entered into column 80, so that relative motion works properly. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
chris@umcp-cs.UUCP (Chris Torek) (10/11/85)
In article <39@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes: >... I am not familiar with the internals of Gosling Emacs, only >Multics Emacs. Its redisplay-line routine is independent of the >actual screen line, so it only has the global line length variable >to deal width. The display code in Gosling Emacs is pretty similar: I was proposing that the line redisplay be made dependent on the actual screen line. Basically, there would be a per-terminal flag saying `I cannot handle the last character of the last line, so do not ask me to'; and making the display code honor that would not be hard. [me] >>---but there is no real incentive since most of our local terminals >>are automatically set to non-wrap mode while running Emacs. >How do you deal with the different ways that terminals handle the >no-wrap case, with respect to relative cursor motion after entering a >character in the 80th column? On a per-terminal basis, with hardwired drivers. I know, it is not wonderful. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
neal@weitek.UUCP (Neal Bedard) (10/11/85)
In article <2857@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > ... > and EMACS) which handle wide lines by wrapping them rather than by having a > window into the text which can be shifted horizontally (I did a screen > editor which had such a shiftable window, and prefer it to the "vi"/EMACS > style of wrapping). > > Guy Harris I can speak for Gosling EMACS here: the view window *can* be shifted horizontaly by setting wrap-long-lines off and diddling the left-offset value (setq left-offset.) -Neal -- "whaddya mean there were bullet-holes in his mirror..." UUCP: {turtlevax, resonex, cae780}!weitek!neal
matt@prism.UUCP (10/14/85)
/* Written 10:50 pm Oct 10, 1985 by neal@weitek in prism:net.emacs */ /* ---------- "Re: 79-character screen (horiz. scr" ---------- */ > > I can speak for Gosling EMACS here: the view window *can* be shifted > horizontaly by setting wrap-long-lines off and diddling the left-offset > value (setq left-offset.) > True, but this isn't the same as true horizontal scrolling, where the screen follows the cursor automatically. Granted, this is almost impossbile to arrange on dumb 9600 baud terminals, since the redisplay is much too slow to permit shifting the screen one character at a time with every (forward-character) that gets executed. One could potentially shift the screen by some percentage of its width when the cursor moves off either end. Or, one could take the Jove approach and only shift the current line. Either of these would be a big win over line wrapping or truncation. Mike Gallagher, are you listening? ------------------------------------------------------------------------------- Matt Landau ARPA: matt%mirror@cca Mirror Systems, Inc. UUCP: {decvax!cca, ima!inmet, mit-eddie, wjh12}... Cambridge, MA ...mirror!prism!matt ------------------------------------------------------------------------------- Blessed are they that run around in circles, for they shall be known as wheels.
neal@weitek.UUCP (Neal Bedard) (10/17/85)
In article <3300005@prism.UUCP>, matt@prism.UUCP writes: > > [Me:] > > > > I can speak for Gosling EMACS here: the view window *can* be shifted > > horizontaly by setting wrap-long-lines off and diddling the left-offset > > value (setq left-offset.) > > > > True, but this isn't the same as true horizontal scrolling, where the > screen follows the cursor automatically. .... > .... One could potentially shift > the screen by some percentage of its width when the cursor moves off > either end. Or, one could take the Jove approach and only shift the > current line. Either of these would be a big win over line wrapping or > truncation. > > Mike Gallagher, are you listening? Well, I actually use three macros called dot-to-left-margin, dot-to-centre, and dot-to-right-margin bound to three keypad keys. dot-to-centre seems to be the one I use the most. The redraw isn't too painful, as it happens in roughly 1 sec. at 9600 baud. I find this setup to be sufficient, even though I have to move the cursor to scroll the screen to where I want it. -Neal -- "whaddya mean there were bullet-holes in his mirror..." UUCP: {turtlevax, resonex, cae780}!weitek!neal
jdz@wucec2.UUCP (Jason D. Zions) (10/22/85)
In article <3300005@prism.UUCP>, matt@prism.UUCP writes: > True, but this isn't the same as true horizontal scrolling, where the > screen follows the cursor automatically. .... > .... One could potentially shift > the screen by some percentage of its width when the cursor moves off > either end. Or, one could take the Jove approach and only shift the > current line. Either of these would be a big win over line wrapping or > truncation. If you want real horizontal scrolling, get a terminal that does it in hardware; the HP2626 comes quickly to mind, there may be others. Failing that, I don't want to wait for a repaint, full or partial, of the screen. I'd rather live with wrap. (Actually, shifting only the current line has some appeal; would be useless for sets of lines requiring visual alignment, like tables or equations or character diagrams, though). -- Jason D. Zions jdz@wucec2 Center for Engineering Computing ...ihnp4!wucs!wucec2!jdz Washington University in St. Louis Guinness - the stout you can eat with a fork (but use a spoon; you'll want to get every drop...)
guy@sun.uucp (Guy Harris) (10/27/85)
> > True, but this isn't the same as true horizontal scrolling, where the > > screen follows the cursor automatically. .... > > If you want real horizontal scrolling, get a terminal that does it in > hardware; the HP2626 comes quickly to mind, there may be others. > > Failing that, I don't want to wait for a repaint, full or partial, of the > screen. I'd rather live with wrap. I'd rather wait for a repaint than live with wrap. Let's conclude that which is better or worse is a matter of taste and either 1) build editors for one or the other group of people or 2) make it an option that the user can select. Guy Harris