Brian Gupta writes: > Draft 0.3 vim proposal. > > http://docs.google.com/Doc?id=df6hcjb2_10f934gh > > Please let me know if you need edit access.
Are you trying to write a full case or a fast-track? If it's the latter (integrating vim alone without name conflicts sounds like a fast-track to me), then there's one small problem with the text: it's too long. Brevity is the soul of a fast-track. Pare away the bits (such as historical notes) that are not needed. On the text itself: > Vim is currently considered the most modern and advanced version of vi > available. Because of this it has become the standard version of vi for > many of the Open Source Operating Systems that are shipping today. Does this mean just Linux? If so, say so. (I thought *BSD shipped with both 'standard' vi and vim ...) > The motivation behind this proposal is to bring Vim to the Solaris > operating system. Initially it will coexist with the original vi. Eventually > it is desirable to deprecate vi, and have vim replace vi as the bundled Indicating future direction is good, but the word "deprecate" is a problem. It has no formal meaning in the ARC. If the future direction is to replace 'vi' with 'vim' once compatibility is ensured, then just say that. > vi editor. Until such time as this is done, any vim files that conflict with > vi files, will not be included in this project. What files are these? I assume this means 'ex' and 'view,' as described (somewhat) in the next paragraph. This should be made more explicit. > The GUI version of vim can always be added later without risk > of breaking something. If they are added now, and we find a > need to change things up, we will be stuck. The only thing that "breaks" is the user expectation. Do users expect that a reasonably modern installation of vim includes the GUI version? If not, then this sounds fine. If they do, then does this project make Solaris a poor step-child? What does "change things up" mean here? > 3.1 Imported interfaces > > ????? (Language bindings?) This looks like a misunderstanding. ARC cases "import" interfaces that are defined by other ARC cases. You can't "import" something that isn't defined. If there's some sort of plug-in interface here or name space that is managed by the project, then that needs to be an exported interface. > SUNWvim Proposed Package name > > /usr/bin/vim Proposed Executable location "Proposed" isn't one of the possible stability levels. I'd suggest "Uncommitted" for the package name and "Committed" for the executable locations. I can't see much of a reason to go with any other stability level for the executables. There's more that's normally required here. I assume that vim reads from $HOME/.exrc. Are there other files involved? Are there help files (besides man pages) installed somewhere on the system? Those repositories are important private interfaces. Are there any architectural issues with the command set that need to be defined? Does vim extend the vi/ex command language in any interesting way? Are there any places in the command language where things are *less* than completely stable (such as a "debug mode")? How is the "restricted" mode defined? Do you have any prototype man pages? > 4. References None of these numbered items listed as "references" are actually referenced by the text. Are they intended to be informative or normative? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
