danl@cbnewsc.ATT.COM (daniel.r.levy) (04/07/89)
Please skip this message if you have already seen it. It appears that this didn't get out on my first try. I am looking for a way in vi on the sun (sun3, sun4) to do what the System V vi ":set showmode" command does, i.e., when a user is in a text modifica- tion mode, display this fact in the lower right hand corner of the screen. ":set all" shows the seemingly promising "nomodeline", but when I ":set modeline" that doesn't seem to do anything (I still don't see anything different when entering a text modification mode), although ":set" verifies that I have "modeline" set. I could not find anything in the manual that comes with the sun (either the vi manpage or the vi reference) about the "modeline" option, so I don't know if I am using it correctly or not, or what it is really supposed to do. I want this feature to assist novice "vi" users. Thanks greatly in advance for any help or advice on the matter; please send me email. -- Dan'l Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!danl AT&T Bell Laboratories 5555 West Touhy Avenue Any opinions expressed in the message above are Skokie, Illinois 60077 mine, and not necessarily AT&T's.
danl@cbnewsc.ATT.COM (daniel.r.levy) (04/07/89)
In article <441@cbnewsc.ATT.COM>, I wrote: > I am looking for a way in vi on the sun (sun3, sun4) to do what the System V > vi ":set showmode" command does, i.e., when a user is in a text modifica- > tion mode, display this fact in the lower right hand corner of the screen. > [:set modeline doesn't do the same thing] I have just been told that ":set modeline" enables a behavior in vi whereby if the first or last five lines of a file being edited contains a space or tab followed by "vi:" or "ex:" everything after that in the line is treated as an editor command. This is very different from ":set showmode", which I was also told was not implemented in Berkeley vi. Okay, the next thing I tried was to port the System V vi to the Sun4 (SUNOS 4.0.1). It quickly began to look like a major hacking headache. Simple compilation under the so-called "System V universe" won't fly: there are things which are not #defined that are supposed to be #defined, things which are not declared that are supposed to be declared, etc., etc., arrrrrrrgh!!!! Has anyone out there ported the System V vi onto the Sun4 running SUNOS 4.0.1? (Has anyone out there been crazy enough to TRY?!?) If so could you please tell me how you did it ?!? Thankx...... -- Dan'l Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!danl AT&T Bell Laboratories 5555 West Touhy Avenue Any opinions expressed in the message above are Skokie, Illinois 60077 mine, and not necessarily AT&T's.
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>Okay, the next thing I tried was to port the System V vi to the Sun4 (SUNOS >4.0.1). It quickly began to look like a major hacking headache. Simple >compilation under the so-called "System V universe" won't fly: there are >things which are not #defined that are supposed to be #defined, things which >are not declared that are supposed to be declared, etc., etc., arrrrrrrgh!!!! The crux of the problem is that the System V implementation has changed at various times, and "vi" depends on characteristics of the implementation. The SunOS System V environment is based on recent versions of the SVID; it doesn't promise that everything will look *exactly* as it does on your 3B. For example, the S5R3 "vi" assumes that you have the *UNDOCUMENTED* "-lgen" library. One is tempted to ask why, if this library is so bloody wonderful, it's not documented? It's sure not in the SVID. It also assumes you have the "-lcrypt" library. The main reason for this library is to isolate the encryption code, so as to make it easier to make "domestic" and "international" releases of S5. It turns out that, for various reasons, that doesn't help for SunOS, so that particular bit of technology wasn't adopted. It's not in the SVID either.... It also includes "term.h" but not "curses.h". Unfortunately, while the S5R3 "term.h" doesn't require you to include "curses.h", the S5R3.1 one *does* - and the S5 "curses" in SunOS 4.0 is based on the S5R3.1 one. The S5R3.1 "vi" handles this by independently defining a few items from "curses.h" (and solemnly informing you in a comment that you have to keep those definitions in sync with the ones in "curses"); however, the S5R3.1 "vi" depends on S5R3.1's rather, umm, *idiosyncratic* internationalization support - SunOS 4.0 doesn't have that, and SunOS 4.1's internationalization support matches that from the draft ANSI C standard, rather than S5R3.1's. On top of that, the S5R3 "vi" assumes that you can't have job control in a "System V" system; this is, of course, not true - the SunOS S5 environment has it, as do, I think, recent versions of HP-UX, and the S5 environment of Ultrix - and, of course, S5R4.... There is also a bug in the Sun-4 version of the S5 C library - one of the routines in it appears to be a Sun-2 version. This may be fixed in 4.0.1; we haven't installed it yet. Had "vi" been written solely to the SVID, had it more carefully #ifdeffed the job control support, it should have built, modulo bugs such as the one listed. There's a reason why things such as the SVID, and POSIX, and the forthcoming ANSI C standard, exist; they exist to give implementation-independent promises about the environment. Said promises stand a better chance of being honored in multiple environments than promises from one particular vendor's manual pages - or, worse, one particular vendor's *source code*....