Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!rochester!kodak!sisd!jeh From: jeh@sisd.kodak.com (Ed Hanway) Newsgroups: comp.sys.amiga.tech Subject: Re: REXX command standards Message-ID: <1990Nov19.190709.20914@sisd.kodak.com> Date: 19 Nov 90 19:07:09 GMT References: <1990Nov17.151516.14252@sisd.kodak.com> Sender: news@sisd.kodak.com Organization: Printer Products Division Eastman Kodak Lines: 63 cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 17 Nov 90 15:15:16 GMT, jeh@sisd.kodak.com (Ed Hanway) said: > >Ed> As Mike Meyer pointed out, simply taking every command that a program has >Ed> and creating an AREXX equivalent for it isn't a good way to develop a >Ed> standard. Simple things like port name and command syntax conventions >Ed> should be relatively easy to agree on. The hard part will be agreeing on >Ed> what commands should (and should not) be included in a standard. > >On the other hand, you don't want to make programs more complex by possibly >having to support two significantly different standards for command interface. >For instance, (as Mike Meyer made mention of) MG3 already has a command >standard based on the GNU Emacs command standard. This is useful for those >people already very familiar with GNU Emacs. If the AREXX command standard >forced MG3 to support things like 'CUT = KILL-REGION', then new users to MG3 >would have to learn the Emacs language for interactive use followed by the >AREXX standard for scripting. Programs with existing command interfaces could continue to support them as well as any new standard without significant complications. For simple(*) things like naming conventions, it should be trivial to allow both "cut" and "kill-region" as synonyms of the same command. Current users can continue to use the old commands, while developers of add-ins or other products that interface to the program should follow the standard. What I'm saying is that an AREXX command set standard shouldn't just be a one-to-one correspondence between AREXX commands and a program's existing commands or menu entries and the standard. To use some contrived examples, "delete-line" is used commonly enough to bind it to a single keystroke, but it may not be necessary as a separate AREXX command, when the AREXX equivalent of "goto-line-start; mark; goto-line-end; delete-to-mark" will work. (This is probably a bad example.) On the other hand, "copy-current-line-to-buffer-nondestructively" may not be useful interactively, but might be very useful to REXX programs that want to do something special to the characters around the cursor. >Perhaps an alternative suggestion to an AREXX command standard would be a >single command by which AREXX could ask the program in question what its >command equivalents for the AREXX standard would be. The result of such a >command would be a list that's indexed by the standard commands. Sounds like more work for the AREXX program without really simplifying the application program. If you're saying the program should send some kind of dictionary saying "'cut' = 'kill-region foo bar bletch'" why not just let the program do the conversion internally then execute the equivalent private command(s) normally. (*) By using words like "easy" and "simple," I don't mean to imply that developing a standard AREXX interface is trivial. From my viewpoint as an idealistic technical person, technical issues like port naming, returning values, etc., are "easy" compared to the political issues that could come up if Vendor X insists that their way is "The Way To Do It," either by insisting that their unique features should be included in the standard (e.g. "all text editors must have 'M-x psychoanalyze-pinhead'") or that they shouldn't correct any deficiencies (e.g. "text editors don't need to support long lines"). Real issues along these lines will be more subtle (What should you use for the end of a line? CR? LF? CRLF? NUL? Do you even allow working with text that spans lines?). -- Ed Hanway --- uunet!sisd!jeh Must be 18 or older to play. Prerecorded for this time zone. Do not read while operating a motor vehicle or heavy equipment.