silvert@cs.dal.ca (Bill Silvert) (10/20/90)
I'd appreciate it if anyone could clarify a confusing dialogue I've been
having with a local HP salesman about the way some software works in
windows.
I'm in the market for a Unix workstation and have been looking at the HP
400 series machines. Working with VUE I discovered that programs like
vi and more assume a 24x80 window and won't adjust to work with any
other size (for example, with a longer window they use only the top 24
lines). I commented that this seemed like a pretty serious shortcoming.
The salesman just contacted me and said that he spoke to HP's software
engineers, and they claim that by doing this HP is maintaining some kind
of standard. Software that adjusts to the actual window size is in
their opinion "non-standard".
Can anyone explain this to me? Since vi and more get the screen size
from termcap or terminfo when they load, what is nonstandard about
getting the size of a window as well, which is after all a virtual
terminal? I can understand not adjusting to a resized window, but when
you load a program it seems to me it should use the window you are in.
--
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577
UUCP=..!{uunet|watmath}!dalcs!biomel!bill
BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.carjn@hpfcso.HP.COM (Bob Niland) (10/21/90)
re: > Working with VUE I discovered that programs like vi and more assume a > 24x80 window and won't adjust to work with any other size (for > example, with a longer window they use only the top 24 lines). > Since vi and more get the screen size from termcap or terminfo when they > load, what is nonstandard about getting the size of a window as well, > which is after all a virtual terminal? I can understand not adjusting to > a resized window, but when you load a program it seems to me it should use > the window you are in. 1. 'untic hp > silvert' 2. edit the "lines#24" to whatever you like (I use 35). 3. have your admin perform a 'tic silvert' 4. edit your .profile or .login to set TERM=silvert 5. for vi specifically, you can also use the -w command option and the LINES and COLUMNS environment variables. 99. If you set COLUMNS higher than 80, don't use that window to post to netnews :-) It causes wrapping and/truncating on the 80 column windows used by 91.4% of the readership. Regards, Hewlett-Packard Bob Niland Internet: rjn@hpfcrjn.FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599 This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.
silvert@cs.dal.ca (Bill Silvert) (10/22/90)
In article <7370237@hpfcso.HP.COM> rjn@hpfcso.HP.COM (Bob Niland) writes: >1. 'untic hp > silvert' >2. edit the "lines#24" to whatever you like (I use 35). >3. have your admin perform a 'tic silvert' >4. edit your .profile or .login to set TERM=silvert >5. for vi specifically, you can also use the -w command option > and the LINES and COLUMNS environment variables. This is how HP expects us to use their systems? Unless I am missing something, Bob will let me open one specific window size at a time. What I want to do (and what most systems support) is that I open a window WITHOUT carefully counting the lines and columns, invoke vi or more, and and it finds out what the window size is and uses that. Why do I have to laboriously go through steps 1 to 5? Isn't that the sort of job a computer can do? -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
evgabb@sdrc.UUCP (Rob Gabbard) (10/22/90)
From article <1990Oct22.012158.13288@cs.dal.ca>, by silvert@cs.dal.ca (Bill Silvert): > What I want to do (and what most systems support) is that I open a > window WITHOUT carefully counting the lines and columns, invoke vi or > more, and and it finds out what the window size is and uses that. The resize program supplied with HP-UX is intended to allow you to do that. It queries via curses the current width and height of the window and outputs the following lines (appropriate for use in eval): LINES=xx; COLUMNS=yy; export LINES COLUMNS; where xx and yy equal the number of lines and colummns respectively in the pseudo terminal. Thus, after resizing your window you could execute the following (assuming /usr/bin/X11 is in your path): eval `resize` I set up the following Korn Shell alias for vi so I don't have to worry about doing this every time I resize my window. You could do the same for more if it queries LINES and COLUMNS. You could also do this via a shell function in the Bourne Shell or via and alias in the C Shell: vr=eval $( /usr/bin/X11/resize );vi -- Rob Gabbard (uunet!sdrc!evgabb) Technical Development Engineer Structural Dynamics Research Corp
aaronf@hpfcbig.SDE.HP.COM (Aaron Friesen) (10/22/90)
From: silvert@cs.dal.ca (Bill Silvert) > I'd appreciate it if anyone could clarify a confusing dialogue I've been > having with a local HP salesman about the way some software works in > windows. > Working with VUE I discovered that programs like > vi and more assume a 24x80 window and won't adjust to work with any > other size (for example, with a longer window they use only the top 24 > lines). I commented that this seemed like a pretty serious shortcoming. > The salesman just contacted me and said that he spoke to HP's software > engineers, and they claim that by doing this HP is maintaining some kind > of standard. Software that adjusts to the actual window size is in > their opinion "non-standard". > Can anyone explain this to me? Since vi and more get the screen size > from termcap or terminfo when they load, what is nonstandard about > getting the size of a window as well, which is after all a virtual > terminal? I can understand not adjusting to a resized window, but when > you load a program it seems to me it should use the window you are in. Actually, I believe that vi and more get the screen size from the current environment. Specifically, the LINES and COLUMNS variables. When vi and more start executing, these two variables are used to determine the size of the screen (if they are not set, I believe it will default to 80x24). However, when you change the size of the screen, these variables are not updated. Therefore, they must be reset to the proper values. This can be accomplished by using an aliased command similar to the following (using ksh): alias rsize="eval `resize`" This must be executed after changing the size of a window. Both vi and more should work as expected. I would guess that what was being represented as being "non-standard" would be if vi and more were able to adjust dynamically. I hope this helps (it works for me!). Aaron Friesen aaronf@hpfcsup.hp.com -------------- standard disclaimer...
chan@hpfcmgw.HP.COM (Chan Benson) (10/23/90)
> I'm in the market for a Unix workstation and have been looking at the HP > 400 series machines. Working with VUE I discovered that programs like > vi and more assume a 24x80 window and won't adjust to work with any > other size (for example, with a longer window they use only the top 24 > lines). I commented that this seemed like a pretty serious shortcoming. hpterm should set the LINES and COLUMNS variable to the initial size of the hpterm window, so if you bring up the window at 80x35, everything will be hunky-dory. If you later change the size of the window, executing eval `resize` will reset LINES and COLUMNS to the new dimensions. > The salesman just contacted me and said that he spoke to HP's software > engineers, and they claim that by doing this HP is maintaining some kind > of standard. Software that adjusts to the actual window size is in > their opinion "non-standard". Hmmmmm. No comment. -- Chan
bcripe@hpcvlx.cv.hp.com (Brian E. Cripe) (10/23/90)
> I'm in the market for a Unix workstation and have been looking at the HP > 400 series machines. Working with VUE I discovered that programs like > vi and more assume a 24x80 window and won't adjust to work with any > other size (for example, with a longer window they use only the top 24 > lines). I commented that this seemed like a pretty serious shortcoming. If the software you are running understands the LINES and COLUMNS environment variable (I believe both vi and more do), then it is simple. After altering the size of your hpterm window you need to use the "resize" command to reset LINES and COLUMNS to their new values. Do a "man resize" for details on how to use resize. Brian Cripe
darrylo@hpnmdla.HP.COM (Darryl Okahata) (10/23/90)
In comp.sys.hp, rjn@hpfcso.HP.COM (Bob Niland) writes: > 1. 'untic hp > silvert' > 2. edit the "lines#24" to whatever you like (I use 35). > 3. have your admin perform a 'tic silvert' > 4. edit your .profile or .login to set TERM=silvert > 5. for vi specifically, you can also use the -w command option > and the LINES and COLUMNS environment variables. If you are using hpterm (X-windows), you can use the following, which is much more painless: eval `/usr/bin/X11/resize` ; vi <filename> NOTE THE BACKQUOTES; they are NOT single forward-quotes! This also assumes that TERM has previously been set to "hp". > 99. If you set COLUMNS higher than 80, don't use that window to post to > netnews :-) It causes wrapping and/truncating on the 80 column > windows used by 91.4% of the readership. This cannot be repeated often enough. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hp-sde.sde.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
jack@hpindda.cup.hp.com (Jack Repenning) (10/23/90)
In comp.sys.hp, rjn@hpfcso.HP.COM (Bob Niland) writes: > 1. 'untic hp > silvert' I can't believe this! Did I actually *catch* Bob Niland? It *can't* be - he knows *all* the right answers! Maybe I'm missing some context here or something (which is possible, since I don't have the base note).... Anyway, assuming I understand what's going on here, the procedure Bob specifies is perfectly correct (of course!), but a great deal more trouble than necessary, and a great deal less flexible than desirable. As he points out, sort of, there are environment variables defined to let vi or more (or pretty much any other program) know how big your window is at start up. If they're set, they override the entry in the termcap database, which means you don't need to play around with untic. So, how do you get them set? Well, the termulators (hpterm and xterm) set them when they start up, to whatever size the window starts at. But, if you change the window size after start up, they can't help you - environment variables are inherited on start-up, and your login shell is already running, and not listening to any new inputs of this sort. For this kind of situation, there's a command, resize(1) (/usr/bin/X11/resize), that prints out the commands needed by your login shell (taken from $SHELL) to set them. So the following works for most users ($SHELL==/bin/sh, /bin/csh, or /bin/ksh): eval `/usr/bin/X11/resize` Alias it to something easy to type, like 'rs', and do it whenever you resize a window, and your vi's and more's and everything else will be fine. Regards, Hewlett-Packard Jack Repenning Internet: jack@cup.hp.com 19420 Homesetead Road UUCP: [hplabs|hpfcse]!hptnjar!jack Cupertino, CA 95014 This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.
wunder@orac.HP.COM (Walter Underwood) (10/23/90)
On HP-UX, "vi" will read the LINES and COLUMNS env variables, but it can't react to window changes after it has started. The reason is pretty straight-forward -- HP-UX uses the AT&T tty interface, which doesn't have any way to query for the window size. The Sun tty driver does have that information (struct winsize) and also has SIGWINCH, to notify the application that something has changed. Just run this after resizing a window, and before starting "vi": eval `resize` That is the best I can offer right now. I don't like the situation, either. wunder PS: Working for, but not speaking for, HP.
rjn@hpfcso.HP.COM (Bob Niland) (10/23/90)
re: > This is how HP expects us to use their systems? No. You forgot to quote my disclaimer. > This response does not represent the official position of, or statement by, > the Hewlett-Packard Company. The above data is provided for informational > purposes only. It is supplied without warranty of any kind. I am not a windows expert. I just pitch in on comp.sys.hp whenever I have an answer, or part of an answer. In fact, I'm personally still using "Windex" instead of X-11, due to inertia. I have a variety of constant window sizes that I use, and years ago hacked out the procedure I posted. I haven't had to think about it since. > Why do I have to laboriously go through steps 1 to 5? Isn't that the > sort of job a computer can do? There probably are more elegant solutions, and perhaps someone else will post one. Indeed, I was thinking about how to do a size readback just a few days ago, but haven't refined it to code. Bob Niland Internet:rjn@hpfcrjn.FC.HP.COM UUCP:[hpfcse|hplabs]!hpfcrjn!rjn Since your question concerns use of supported products, here's my other standard postscript. By the way, although an excellent medium for customer-to-customer exchange, netnews is a very slow and capricious way to get questions answered by HP. If you have either HP TeamLine or HP ResponseLine software support services, you can direct questions about supported HP products to your regional HP Response Center. HP people who respond to netnews questions are donating our time. We do not have the full resources of a Response Center at our disposal, and the person who knows the answer to any given question may not be reading news this week, or month, or...
paul@eye.com (Paul B. Booth) (10/23/90)
In article <101950150@hpcvlx.cv.hp.com> bcripe@hpcvlx.cv.hp.com (Brian E. Cripe) writes: >> I'm in the market for a Unix workstation and have been looking at the HP >> 400 series machines. Working with VUE I discovered that programs like >> vi and more assume a 24x80 window and won't adjust to work with any >> other size (for example, with a longer window they use only the top 24 >> lines). I commented that this seemed like a pretty serious shortcoming. > >If the software you are running understands the LINES and COLUMNS environment >variable (I believe both vi and more do), then it is simple. After >altering the size of your hpterm window you need to use the "resize" >command to reset LINES and COLUMNS to their new values. Do a "man resize" >for details on how to use resize. > Resizing can also be done semi-automatically with something like this in each user's .kshrc file (modify as needed for /bin/sh, /bin/csh): function vi { eval `/usr/bin/X11/resize -u 2>/dev/null`; /usr/bin/vi "$@" } Hardly perfect (takes a little longer to startup & you need a function for each command or variant (vi,view,more, etc) ), but it does ensure that the window and vi are in sync whenever you start vi. -- Paul B. Booth (paul@eye.com) (...!hplabs!hpfcla!eye!paul) ------------------------------------------------------------------------------- 3D/EYE, Inc., 2359 N. Triphammer Rd., Ithaca, NY 14850 voice: (607)257-1381 fax: (607)257-7335
scpinker@pikes.Colorado.EDU (Scott C. Pinkerton) (10/24/90)
We have used the following method to get programs to work in a window that has been re-sized. Once you have re-sized the window type the following commands: eval `resize` tset This has seemed to work for those people who have wanted to re-size their windows. I agree that there should be a more seamless/transparent way for the applications to determine that re-sizing has occured without the user having to do anything. scott pinkerton scpinker@pikes.colorado.edu
jaa@hutcs.hut.fi (Jari Alasuvanto) (10/24/90)
In article <4310144@hpindda.cup.hp.com> jack@hpindda.cup.hp.com (Jack Repenning) writes: <Stuff deleted about resizing term windows> > > eval `/usr/bin/X11/resize` > >Alias it to something easy to type, like 'rs', and do it whenever you >resize a window, and your vi's and more's and everything else will be >fine. Or to go further, alias (or write a script in sh) which doesd the trick for you EACH TIME you start vi/emacs/whatever-term-size-dependent For csh this is: alias xs 'set noglob; eval `resize`' alias vi 'xs ; /usr/bin/vi !*' This works Ok; besides, this way you do not have to do anything extra each time you change the size of a window. -- Jari Alasuvanto, Lab. of Info Proc. Sci, Helsinki Univ. of Techology, Finland Internet: jaa@hutcs.hut.fi tel: +358-0-451 3236 fax: +358-0-465 077 <All the statements are my own -- HUT can make its own>>
taylor@limbo.Intuitive.Com (Dave Taylor) (10/25/90)
Bill Silvert wrote: > Working with VUE I discovered that programs like vi and more assume a > 24x80 window and won't adjust to work with any other size (for example, > with a longer window they use only the top 24 lines). Lots of people since have talked about how to use the X11 "resize" command before invoking the editor windows, et. al. but I think they've missed the original problem that Bill was talking about; editor windows *launched from VUE* are too small. Vi cannot resize dynamically once it's started up (as far as I know), so once the window is there, he's stuck with it at the wrong size. He can have Vi pop up as a generic shell window (e.g. a solution like: set EDITOR to "csh", then when the editor is launched from the VUE environment immediately go into the (interactive) window, drag it to the size you desire, then use "resize" and "vi" commands to get it to what you want (actually, "resize ; exec vi $*" or similar)). The problem with that is that he doesn't then have editor windows from VUE, really, and has then lost out on one of the important features of the VUE environment itself. Another solution that might be interesting to try would be to fiddle with the EDITOR value to see if you couldn't get something like "EDITOR='=80x40 vi'" to work (that is, exploit how VUE is invoking the editor in an Xterm window by spoofing some additional command line parameters) (retrospectively that probably wouldn't be very easy because VUE probably calls something like "xterm -e $EDITOR") Ultimately, there should be some easily user-accessible script or command mapping scheme that has an entry like: EDIT_WINDOW ICON = EDIT_WINDOW_ICON CMD = xterm -e $EDITOR #1 END where "#1" is expanded to the name of the file in question, and EDITOR is expanded to the environment variable as appropriate (or "vi" as a default). If that were present, then users could easily go into the file (or have a locally, user specific, modified version of their own) and change it, say, to: EDIT_WINDOW ICON = EDIT_WINDOW_ICON CMD = xterm =80x40 -e $EDITOR #1 END It's worth noting that both of major the third party graphical user environments, X.desktop and Looking Glass, offer features of this nature (and both are more sophisticated than VUE too, in my view) (uh, pardon that pun!). In fact, in Looking Glass, for example, one could have an editor icon that actually had a default window size, but, with a CONTROL-button sequence, would actually pop up a list of different size windows that the user could then choose from with a script similar to: DEFINE TYPE EDIT_ICON ICON EDIT_WINDOW_ICON COMMAND "xterm =80x40 -e $EDITOR #f" COMMAND_DESCRIPTION "Edit the file, use an 80x40 window" COMMAND "xterm =80x50 -e $EDITOR #f" COMMAND_DESCRIPTION "Edit the file, use an 80x50 window" COMMAND "xterm =80x25 -e $EDITOR #f" COMMAND_DESCRIPTION "Edit the file, use an 80x25 window" END Users would then see a menu of choices: Edit the file, use an 80x40 window Edit the file, use an 80x50 window Edit the file, use an 80x25 window which they could -- each time -- choose from. * * * * * I strongly believe that HP-UX should include the transmission and interception of the SIGWINCH command, which indicates to the programs that receive it that the window has been resized. They then simply query the system about the new size and reconfig themselves. Not massively difficult. * * * * * -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
bb@reef.cis.ufl.edu (Brian Bartholomew) (10/26/90)
In article <1990Oct20.123109.7287@cs.dal.ca> you write: >engineers, and they claim that by doing this HP is maintaining some kind >of standard. Software that adjusts to the actual window size is in >their opinion "non-standard". > >Can anyone explain this to me? Since vi and more get the screen size >from termcap or terminfo when they load, what is nonstandard about >getting the size of a window as well, which is after all a virtual >terminal? I can understand not adjusting to a resized window, but when >you load a program it seems to me it should use the window you are in. It's very simple - you are being screwed by HP. The salesman is making up ridiculous things, to get you to buy. Imagine, a window system that didn't let you window things! Save your sanity, buy a Sun SPARC or a NeXT. There are far more applications available for a SPARC, anyway. Actually, the technical excuse for this behavior is as follows: On Suns, when the window size changes, it is stored in the same area that other terminal-related things like baud rate, kill characters, and in/output processing are stored. (The same data structure that stty manipulates, i.e. the tty driver data area, i.e. the termio struct). All applications may get to this information with a minimum of hassle - and when the window size changes, a SIGWINCH signal is passed to all applications using that window. Apps that choose to pay attention to window size may choose to define an action for that signal. For instance, the EMACS editor, even when running in a terminal (instead of the more usual case of its own X Window), will adapt to the changed size window. Under SunOS, vi will not adapt to a window size change while it is running - but it reads the window size upon startup, so running it fresh in a size changed window works like you would want. This behavior is not perfect, but useful, as it will let you run vi with more than 24 lines displayed. On the other hand, HP's have a more SysV idea of the termio struct. The /etc/termcap file is considered unchanging system-wide information; and, how would you modify one terminal type entry ("hpterm", say), to reflect the sizes of all umpty-zillion windows on the screen? I believe that there are two environmental variables that termcap applications respect - ROWS and COLUMNS. However, they aren't used. In fact, there are no provisions made for recording of the window size, in anyplace that termcap applications can get to. In conclusion, with termcap applications on HP 3xx/8xx computers, even while running a modern, network-cooperative window system like X, you are stuck with 80x24 windows. Ridiculous, isn't it? "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu
bb@reef.cis.ufl.edu (Brian Bartholomew) (10/26/90)
In article <7370237@hpfcso.HP.COM> rjn@hpfcso.HP.COM (Bob Niland) writes: >1. 'untic hp > silvert' >2. edit the "lines#24" to whatever you like (I use 35). >3. have your admin perform a 'tic silvert' >4. edit your .profile or .login to set TERM=silvert >5. for vi specifically, you can also use the -w command option > and the LINES and COLUMNS environment variables. What if I want to use more than one size window on my workstation, *at the same time*? Now let's see, I create my own termcap entry for each type of session I want to use? I wonder how many that I will need to create? Multiplied by however many people use the machine? So that's resize the window, exit the app, setenv TERM, restart the app... Kinda makes that resize widget on the window frame useless, doesn't it? You better get another disk drive to hold that /etc/termcap. >Regards, Hewlett-Packard >Bob Niland Internet: rjn@hpfcrjn.FC.HP.COM 3404 East Harmony Road > UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599 "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu
jad@hpcndnm.cnd.hp.com (John Dilley) (10/29/90)
In article <25121@uflorida.cis.ufl.EDU> bb@reef.cis.ufl.edu (Brian Bartholomew) writes: Brian, Thank you for your glowing review of HP-UX. While you had some valid points regarding the use of SIGWINCH on Sun (and other Berkeley based systems), I would like to point out a flaw in your assessment of HP's terminfo behavior (which has already been brought up in this string but perhaps you missed it). BTW, I was interested to hear that Sun's vi did not obey the SIGWINCH signal ... I always assumed they had fixed vi since they had SIGWINCH... > On the other hand, HP's have a more SysV idea of the termio struct. > The /etc/termcap file is considered unchanging system-wide > information; and, how would you modify one terminal type entry > ("hpterm", say), to reflect the sizes of all umpty-zillion windows on > the screen? I believe that there are two environmental variables that > termcap applications respect - ROWS and COLUMNS. However, they aren't > used. In fact, there are no provisions made for recording of the > window size, in anyplace that termcap applications can get to. > > In conclusion, with termcap applications on HP 3xx/8xx computers, even > while running a modern, network-cooperative window system like X, you > are stuck with 80x24 windows. Ridiculous, isn't it? It would be ridiculous if it were true. But, in fact, HP-UX vi (and other curses-based terminal window applications) *DO* make use of ROWS and COLUMNS. The easiest way to get vi to scale to a non-80x24 terminal window on HP-UX systems, prior to starting vi (just like on your favorite system) is: $ eval `resize` This command places the variables ROWS and COLUMNS into your environment and vi then behaves properly. If you resize the hpterm window while using vi, vi will misbehave (just like you say that Sun does ...). So, in summary, HP-UX terminal windows *can* handle sizes different from the standard 80x24. Gnu emacs running in an X11 window, and other window-smart applications, can handle resizing while running. Hope this helps clear up the confusion, -- jad -- John Dilley Hewlett-Packard Colorado Networks Division UX-mail: jad@cnd.hp.com Phone: (303) 229-2787 -- This is not an official statement from Hewlett-Packard Corp., and does not necessarily reflect the official position of HP. The information above is provided in good faith but completely without warranty of any kind.
guy@auspex.auspex.com (Guy Harris) (10/31/90)
> Thank you for your glowing review of HP-UX. While you had some >valid points regarding the use of SIGWINCH on Sun (and other Berkeley >based systems), Including System V Release 4.... >BTW, I was interested to hear that Sun's vi did not obey the SIGWINCH >signal ... I always assumed they had fixed vi since they had SIGWINCH... Yes, Sun *did* fix "vi" - they did so by *removing* the violently broken 4.3BSD handling of SIGWINCH. The 4.3BSD version, when it gets a SIGWINCH, does a big "longjmp()" back to the initialization code, which gets the new window size, blah blah blah. Unfortunately, if the SIGWINCH is delivered while "vi" is in the middle of, say, reading in a file, you lose big - the read-in is aborted. SunView delivers SIGWINCH to a window-system program not only when a window's size is changed, but also when the window is opened or closed or part of it is uncovered. The SunView tty subwindow code passes SIGWINCH through in all those cases, so if you move a tty subwindow to the front when "vi" is reading in a file, you'd lose. Delivering a SIGWINCH through to the tty in that case really isn't useful, although it *is* useful to deliver it when a window is opened or closed. Ideally, "vi" should be fixed to handle SIGWINCH sanely - and to do so even when in insert mode, instead of just blocking SIGWINCH when in insert mode, as the 4.3BSD "vi" does - but "vi" is a mess internally and it didn't look easy to fix. > It would be ridiculous if it were true. But, in fact, HP-UX vi >(and other curses-based terminal window applications) *DO* make use of >ROWS and COLUMNS. It should also use TIOCGWINSZ, as S5R4's "curses" and SunOS's "curses" and 4.3BSD's "curses" and various other systems "curses" do. (I.e., do a TIOCGWINSZ; if that succeeds and returns non-zero sizes, use them, otherwise get LINES and COLUMNS; if they exist, use their values, otherwise fall back on the "terminfo" entry.)
bcripe@hpcvlx.cv.hp.com (Brian E. Cripe) (11/01/90)
>> Working with VUE I discovered that programs like vi and more assume a >> 24x80 window and won't adjust to work with any other size (for example, >> with a longer window they use only the top 24 lines). > > Lots of people since have talked about how to use the X11 "resize" > command before invoking the editor windows, et. al. but I think they've > missed the original problem that Bill was talking about; editor windows > *launched from VUE* are too small. Vi cannot resize dynamically once > it's started up (as far as I know), so once the window is there, he's > stuck with it at the wrong size. Good point Dave. I know I missed this aspect of the problem and it appears that others did as well. Fortunately there are a few solutions to this problem also. Before diving into how to configure VUE to give you the size terminals you want, I will explain a little about how VUE handles terminal windows. For faster start-up, VUE prestarts and caches a number of hpterm windows. When VUE wants to invoke a command that requires a terminal window it grabs one of its cached windows and ties the command to it. VUE actions that use a cached terminal are all of the COMMAND actions with a window type of TERMINAL, PERM-TERMINAL, or OUTPUT-ONLY. It is possible to also create actions that don't use cached terminals by defining them as NO-STDIO with an exec string of the form "hpterm -e <command>". This gives you a great deal of flexibility in the terminal characteristics (e.g. you can use xterm instead of hpterm) at the expense of start-up performance. Now for the question, how to make your VI windows in VUE bigger? One thing to understand is that you can control the characteristics of the cached terminals using the normal resource mechanisms. Therfore if you want all of your hpterm windows to be 80x40 instead of the default 80x24, then set the resource "hpterm*geometry: 80x40". [Some early versions of VUE have a bug where if you set the geometry using the class HPterm instead of the name hpterm, LINES and COLUMNS don't get picked up correctly.] This will make all of your terminal windows bigger, including the ones VUE caches. Alternatively if you want to change only the size of the Vi windows without changing the size of any other hpterm windows, then you need to define a new VI action that specifies the desired terminal size. For example, put the following entries in the file "$HOME/.vue/types/mine.ad" and then restart VUE. [The next version of VUE has dynamic database loading so you don't have to restart VUE after changing actions, but it isn't out yet.] ----------------------------------------------------------------- # The following entry causes all EDIT_TEXT requests to use my # BIG_VI action instead of the default VI action. EDIT_TEXT * action.l.bm action.s.bm MAP BIG_VI # The BIG_VI action runs vi in an 80x40 window. BIG_VI \ * \ action.l.bm \ action.s.bm \ COMMAND \ NO-STDIO \ %LocalHost% \ /usr/bin/X11/hpterm -geometry 80x40 \ -e "/usr/bin/vi %(File)Arg_1"Edit what file?"% ---------------------------------------------------------------- > He can have Vi pop up as a generic shell window (e.g. a solution like: > set EDITOR to "csh", then when the editor is launched from the VUE > ... This won't work because VUE does not used environment variables for customizing actions, mainly because environment variables don't carry enough information. Does your EDITOR need a terminal window (e.g. vi) or does it do its own windowing (e.g. xedit)? What host do you want to run your editor on? > Ultimately, there should be some easily user-accessible script or > command mapping scheme that has an entry like: > > EDIT_WINDOW > ICON = EDIT_WINDOW_ICON > CMD = xterm -e $EDITOR #1 > END I think you have described VUE's actions using a different syntax. For a full description of the action database, read Chapter 12 of the VUE System Administrator's Manual. Another place to get information is the header of /usr/lib/X11/vue/types/vue.ad (the default actions). [NOTE: Don't customize the standard vue.ad file! Copy it to either /usr/local/lib/X11/vue/types for system-wide customization or $HOME/.vue/types for personal customizations. Otherwise you will lose your customizations the next time you install VUE.] > It's worth noting that both of major the third party graphical user > environments, X.desktop and Looking Glass, offer features of this > nature (and both are more sophisticated than VUE too, in my view) What sophistication is VUE lacking? > In fact, in Looking Glass, for example, > one could have an editor icon that actually had a default window > size, but, with a CONTROL-button sequence, would actually pop up > a list of different size windows that the user could then choose > from ... You could do something similar in VUE by defining a set of actions like EDIT_80_20, EDIT_80_40, EDIT_80_60 ... then add these actions to the list of standard actions for the filetype. The first action in the list is the default that will be invoked when you double-click the file, the other actions are available under the Action menu when a file is selected. Brian Cripe Hewlett-Packard