a218@mindlink.UUCP (Charlie Gibbs) (11/12/90)
In article <1990Nov12.224249.18759@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: >In an unrelated thread, someone (sorry, lost the attribution) writes: >[on integrating CEDPro instead of LSE into the SAS/C environment] >>I guess the problem with using other editors is that they may not have >>the same AREXX commands for moving to a specific line or whatever. > >Until developers get together and start standardizing their REXX interfaces, >this is an unfortunate fact of life. Off the top of my head, I can think of >at least 4 or 5 text editors with REXX support, and they all apparently use >different commands to do more or less the same thing. The situation is no >different for terminal programs, or for any other application where more than >one vendor includes REXX support. > >Of course, each program is unique, but there should be some standardization >of a common subset of commands for each application. Presently, every good >idea for a REXX program (like instant man pages in your editor, or automated >BIX access, or whatever) must be implemented four or five times. > >It would really be nice if I could just drop any editor conforming to an >"AREXX editor command set" into the SAS/C environment. It seems to me like >these standards should be just as important as data format standards like IFF. Actually, how does this differ from having to know what the editor's REXX port is called? Is there any standardization there either? As nice as standardization might be, I'm not holding my breath. However, a good alternative would be to allow each program to be configured as to what the REXX commands are. If a program can read from a configuration file or environment variable just what your favourite editor wants to hear to jump to a certain line or whatever, the problem disappears. (Actually, you still have to set up the configuration file, but I can see people exchanging popular ones via the net. For that matter, a considerate supplier could even provide several with a software package.) In time, standard commands might shake out and the problem will subside. But for now, the extra flexibility of configurable REXX commands sounds like the only way to go. Charlie_Gibbs@mindlink.UUCP The only things to survive a nuclear war will be cockroaches and IBM PCs. -- Larry Phillips Any radiation-induced quirks in those PCs will no doubt be defined by Microsoft as new features. -- me
jeh@sisd.kodak.com (Ed Hanway) (11/13/90)
In an unrelated thread, someone (sorry, lost the attribution) writes: [on integrating CEDPro instead of LSE into the SAS/C environment] >I guess the problem with using other editors is that they may not have >the same AREXX commands for moving to a specific line or whatever. Until developers get together and start standardizing their REXX interfaces, this is an unfortunate fact of life. Off the top of my head, I can think of at least 4 or 5 text editors with REXX support, and they all apparently use different commands to do more or less the same thing. The situation is no different for terminal programs, or for any other application where more than one vendor includes REXX support. Of course, each program is unique, but there should be some standardization of a common subset of commands for each application. Presently, every good idea for a REXX program (like instant man pages in your editor, or automated BIX access, or whatever) must be implemented four or five times. It would really be nice if I could just drop any editor conforming to an "AREXX editor command set" into the SAS/C environment. It seems to me like these standards should be just as important as data format standards like IFF. -- Ed Hanway uunet!sisd!jeh For off-road use only. Some equipment shown is optional. Contains a substantial amount of non-tobacco ingredients. At participating locations only.
giguere@csg.uwaterloo.ca (Eric Giguere) (11/14/90)
In article <1990Nov12.224249.18759@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: >Of course, each program is unique, but there should be some standardization >of a common subset of commands for each application. Actually, there is work going on right now to do just that... it should bear fruit in a few months, I think, but it will be a while before old programs will start adapting these standards. This is a problem across any system that uses something like ARexx as a general-purpose macro language... -- Eric Giguere giguere@csg.UWaterloo.CA Quoth the raven: "Eat my shorts!" --- Poe & Groening
hill@evax.arl.utexas.edu (Adam Hill) (11/14/90)
I would just like a set defined for CERTAIN things:
Editors - Open, Close, Move To Line, Move To Word, Query Word (Left|Right)
of Cursor, Cut, Paste, Copy, Search and Replace.
Paint Progs - Point, Line, Arc, Circle, FloodFill etc..
A VERY good place to design a set of standards might be with server SW for
Arc/EtherNet, FDDI, ParNet, SerNet :-) and even BETTER idea might be a standard
request/recieve for SQL frames/keys.
Heck ... I'd take a way to QUERY an app of all its functions it DOES under-
stand... I guess we will have to wait to see what flows from David Junod's
keyboard.
--
adam hill
hill@evax.arl.utexas.edu Make Up Your Own Mind.. AMIGA!
Amiga... Multimedia NOW
Most Common Phrase at DevCon '90 - "Shhhhhhh.." jerry@truevision.com (Jerry Thompson) (11/14/90)
Does anyone in the Amiga Developers Association know if there is anything being done to standardized AREXX commands? -- Jerry Thompson | // checks ___________ | "I'm into S&M, "What I want to know is, have | \\ // and | | | | Sarcasm and you ever seen Claude Rains?" | \X/ balances /_\ | /_\ | Mass Sarcasm."
giguere@csg.uwaterloo.ca (Eric Giguere) (11/15/90)
In article <533@epicb.com> jerry@truevision.com (Jerry Thompson) writes: >Does anyone in the Amiga Developers Association know if there is anything >being done to standardized AREXX commands? There is, there is... beyond that I'm not sure what I can reveal. Sorry, just give it a few months... -- Eric Giguere giguere@csg.UWaterloo.CA Quoth the raven: "Eat my shorts!" --- Poe & Groening
darren@cbmvax.commodore.com (Darren Greenwald) (11/15/90)
In article <533@epicb.com> jerry@truevision.com (Jerry Thompson) writes: >Does anyone in the Amiga Developers Association know if there is anything >being done to standardized AREXX commands? >-- >Jerry Thompson | // checks ___________ | "I'm into S&M, This is a good idea, and a number of us have thought the same at one time or another. Couple of things to keep in mind: 1.) Those that have supported ARexx would need to update their software, supplied scripts, and user created scripts to come up to spec. Kind of tough on those who supported ARexx, and its going to be hard to come up with much in the way of agreements (I suspect). 2.) When defining standards for commands, you also want to (or may want to) define how the command parser should behave (e.g., case vs non-case sensitivity, whole word vs partial word recognition, abbreviations, ARGUMENT types for standard commands, ARGUMENT types in general, etc.) Not to say this shouldn't be done - just some things to keep in mind. -------------------------------------------------------------- Darren M. Greenwald | Commodore-Amiga Software Engineering | USENET: uunet!cbmvax!darren -------------------------------------------------------------- Quote: "It would be impossible to discuss the subject without a common frame of reference." - Spock
amiga@ccwf.cc.utexas.edu (Paul) (11/15/90)
If there is to be a standard for AREXX it should come out now before everyone has a port in their program. At which time it would be hard to get people to conform. -- Amiga@ccwf.cc.utexas.edu .....Paul...... Listen to what I mean, not what I say.
jeh@sisd.kodak.com (Ed Hanway) (11/16/90)
darren@cbmvax.commodore.com (Darren Greenwald) writes: > 1.) Those that have supported ARexx would need to update > their software, supplied scripts, and user created > scripts to come up to spec. Not necessarily. You can always keep your old commands around for backward compatibility, in addition to the standard commands. The only problem would be if the same command word was already in use with a different syntax, and even then, it's usually possible to support either syntax. > Kind of tough on those > who supported ARexx, and its going to be hard to > come up with much in the way of agreements (I suspect). Yeah, if there's not active participation by all interested parties, someone could ram through a standard that would be close to their current implementation but would require a lot of work from anyone else. Ideally, the standards should be minimal, i.e. a set of commands large enough to be useful, but easily implemented by any program of the same general type. The problem is that both criteria are open to interpretation. For example, in a text editor, is regular expression search easy to implement? Would the lack of it make some useful REXX programs difficult to implement? -- Ed Hanway --- uunet!sisd!jeh This message is packed as full as practicable by modern automated equipment. Contents may settle during shipment.
davidm@uunet.UU.NET (David S. Masterson) (11/16/90)
>>>>> On 14 Nov 90 15:23:38 GMT, jerry@truevision.com (Jerry Thompson) said: > Does anyone in the Amiga Developers Association know if there is anything > being done to standardized AREXX commands? Could somebody enlighten a novice? What would standardizing the AREXX commands buy you? The basic AREXX commands (those that aren't sent out of AREXX) are already standard and the commands sent to application ports would have requirements based on the application. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/16/90)
In <CIMSHOP!DAVIDM.90Nov15112047@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 14 Nov 90 15:23:38 GMT, jerry@truevision.com (Jerry Thompson) said: > >> Does anyone in the Amiga Developers Association know if there is anything >> being done to standardized AREXX commands? > >Could somebody enlighten a novice? What would standardizing the AREXX >commands buy you? The basic AREXX commands (those that aren't sent out of >AREXX) are already standard and the commands sent to application ports would >have requirements based on the application. It would be nice to have standardized commands for basic functions of common types of programs. Any set of similar function programs will have a lot of functions in common. All editors need a command to place text on the screen, to position the cursor by line, column, and perhaps by character count from beginning of file. They all need to be able to read the contents of the line the curesor is on, the word it is on, perhaps the paragraph it is on, the contents of the 'cut' buffer, and so on. Deleting a character, word, sentence, paragraph, marked block are very nice to have, and most editors allow it. The advantage of having a 'common command set' for Arexx calls to the editor is that the user need not rewrite every script to fit the editor he is using. It means that I can write a script for one editor, give it to someone else using a different editor, and the other person can likely use it with little or no modification. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jeh@sisd.kodak.com (Ed Hanway) (11/16/90)
cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Could somebody enlighten a novice? What would standardizing the AREXX >commands buy you? The basic AREXX commands (those that aren't sent out of >AREXX) are already standard and the commands sent to application ports would >have requirements based on the application. Currently, commands sent to application ports are unique to each program, but many programs do much of the same thing. Let's say I wanted an AREXX program to run from an fkey in my editor that would get the current word under the cursor and use it look for a manual page in my man: directory, displaying it in a new window of my editor. The basic flow of the program is the same no matter what editor I use, and any editor worth using has the ability to do this with AREXX, but I'd need one version if I used CEDpro, another for LSE, another for TxEd, another for QED, ad nauseum. -- Ed Hanway --- uunet!sisd!jeh Use other side for additional listings. Some assembly required. Any resemblance to real persons, living or dead, is purely coincidental.
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (11/17/90)
In article <1990Nov14.033931.12883@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes:
I would just like a set defined for CERTAIN things:
Editors - Open, Close, Move To Line, Move To Word, Query Word (Left|Right)
of Cursor, Cut, Paste, Copy, Search and Replace.
Cut, Paste and Copy _what_?
Before you dive into designing a standard, you need to design a couple
of other things. I think, first and foremost, you need a standard as
to what are "acceptable" formats for the Rexx commands specified by a
standard. It has to be something that will fit into the existing
commands for most editors.
For example, choosing some subset of the mg3 command set just _won't_
cut it. Mg3 is a good example of how Rexx commands shouldn't look -
because the Rexx command set is largely the GNU Emacs command set,
which was designed for a different purpose. Other editors are also
good examples of what not to do.
The other thing you have to do before starting on a standard is
design the command set. Just throwing stuff in as needed is a good
way to create problems. The above set looks like it's in that
category.
<mike
--yorkw@stable.ecn.purdue.edu (Willis F York) (11/17/90)
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >The other thing you have to do before starting on a standard is >design the command set. Just throwing stuff in as needed is a good >way to create problems. The above set looks like it's in that >category. Ever see MFF+ (MicroFiche Filer +) I don't have the Manual handy but the Arexx commands are Annoying "Named" here are a few top'o my head suggestions to help smooth out commands/ports Have the port name in Lowercase letters. use all lowercase. (I spent an Hour figering oou why somthing wasen't working , Aress was upper casing the portname and i needed to ad some ' marks) Give Nice names to the commands but avoid LONG command names. Mff+ is a good bad example of this. To get WB to front (I think this is right) the command is . "MFF+_to_Back" . (Descripitive but annoying) All the other commands are equally weird. the Case is Mixed also, which has caused problems. (MFF uses a Weird way of Macros which are rexx scripts in single quotes and commands.mff which are normal rexx stuff. Well Just my .02$, CED2.0 has a very nice rexx port. basicially every menu item can be asecced from REXX. by saying the name of the menu item, or the menu command, ie menu(1,2,3) will select the 3 subitem of the 2 item on the first menu. C-ya -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
jeh@sisd.kodak.com (Ed Hanway) (11/17/90)
yorkw@stable.ecn.purdue.edu (Willis F York) writes: >Well Just my .02$, CED2.0 has a very nice rexx port. >basicially every menu item can be asecced from REXX. >by saying the name of the menu item, or the menu command, >ie >menu(1,2,3) >will select the 3 subitem of the 2 item on the first menu. Ugh. That's a quick&dirty way to include REXX support, and it may have advantages if all you want to do is automate sequences of things done from the menus, but obviously any standard should use real command names like cut, paste, move, etc. (This is not a criticism of CED; given ASDG's reputation for setting and following standards, I'm sure that when a standard does emerge, CED will follow it.) As Mike Meyer pointed out, simply taking every command that a program has and creating an AREXX equivalent for it isn't a good way to develop a standard. Simple things like port name and command syntax conventions should be relatively easy to agree on. The hard part will be agreeing on what commands should (and should not) be included in a standard. -- Ed Hanway --- uunet!sisd!jeh Use other side for additional listings. Some assembly required. Any resemblance to real persons, living or dead, is purely coincidental.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/18/90)
In <1990Nov17.151516.14252@sisd.kodak.com>, jeh@sisd.kodak.com (Ed Hanway) writes: >yorkw@stable.ecn.purdue.edu (Willis F York) writes: >>Well Just my .02$, CED2.0 has a very nice rexx port. >>basicially every menu item can be asecced from REXX. >>by saying the name of the menu item, or the menu command, >>ie >>menu(1,2,3) >>will select the 3 subitem of the 2 item on the first menu. > >Ugh. That's a quick&dirty way to include REXX support, and it may have >advantages if all you want to do is automate sequences of things done from >the menus, but obviously any standard should use real command names like >cut, paste, move, etc. The above mentioned methodology is only one way to invoke a function within CEDPro from ARexx. There are a lot of the more common commands implemented as text strings. The menu number method simply allows you to use ANY function available from the menu, and keeps down the overhead for parsing for things that are not used often (how many times have you wished for a ROT-13 function available from an ARexx->editor interface?) >(This is not a criticism of CED; given ASDG's reputation for setting and >following standards, I'm sure that when a standard does emerge, CED will >follow it.) CEDPro's ARexx interface isboth intuitive and complete. I hope that if a standard emerges for ARexx editor commands, that CEDPro's suite comprises the basis for it. >As Mike Meyer pointed out, simply taking every command that a program has >and creating an AREXX equivalent for it isn't a good way to develop a >standard. Simple things like port name and command syntax conventions >should be relatively easy to agree on. The hard part will be agreeing >on what commands should (and should not) be included in a standard. Port name? Never! Were we to have a standard port name for an editor, it would mean that I could only have one editor active at a time. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
david@starsoft.UUCP (Dave Lowrey) (11/18/90)
In article <1990Nov13.182755.12081@maytag.waterloo.edu>, Eric Giguere writes: > In article <1990Nov12.224249.18759@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: > >Of course, each program is unique, but there should be some standardization > >of a common subset of commands for each application. > > Actually, there is work going on right now to do just that... it should bear > fruit in a few months, I think, but it will be a while before old programs > will start adapting these standards. This is a problem across any system > that uses something like ARexx as a general-purpose macro language... > Could you be a bit more specific on this? I am in the process of developing an AREXX compatable program. I would like to use this "standard", it it appears to be useable. Where can I get info on it? Dave ---------------------------------------------------------------------------- These words be mine. The company doesn't care, because I am the company! :-) Dave Lowrey | david@starsoft or {uhnix1,lobster}!starsoft!david Starbound Software Group | Houston, TX | "Dare to be stupid!" -- Weird Al Yankovic
bj@cbmvax.commodore.com (Brian Jackson) (11/18/90)
In article <1990Nov17.151516.14252@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: > >As Mike Meyer pointed out, simply taking every command that a program has >and creating an AREXX equivalent for it isn't a good way to develop a >standard. Simple things like port name and command syntax conventions >should be relatively easy to agree on. The hard part will be agreeing >on what commands should (and should not) be included in a standard. Among the many interesting problems that must be solved in with these standards is the problem of dealing with multiple instances of the same program running at the same time. What port name do I use in my rexx programs to be sure that I am addressing the right instance of the editor? What 'standard' bit of information do you have the editor return so that you can tell where you are and what happened with the last command? Etc, etc. There is a lot more detail involved than initially meets the eye. Effective (read 'useful') macros require a fairly complex set of things to be communicated between the rexx program and the application. If these things aren't also addressed (at least to some degree) then it seems to me to be of minimal value to just set a few "basic" definitions as you will spend almost as much time fiddling with custom Arexx code as you would have without the standards. No? I think it's a good idea, mind you, but it needs to be considered thoroughly. bj >Ed Hanway --- uunet!sisd!jeh ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "Now there's a look in your eyes, like black holes in the sky" | -----------------------------------------------------------------------
davewt@NCoast.ORG (David Wright) (11/18/90)
I have a small utility I've been working on for my own use, but I might be usefull to other people as well. If there WAS an agreed upon ARexx command list, it would be even more usefull to other people. What I've been working on is a small program that knows how to talk to various types of UPS systems (battery backup systems or standby power systems), and will notify a list of programs when line power goes out or when battery power is at a critical level. This way you can have programs that stay running all the time exit properly, and close all the files they have open so you don't get a corrupted file system when the battery power finally goes out. The problem with doing this is that there is no good way to tella program to shutdown properly (just sending a break signal might cause the program to exit without flushing buffers etc.). If there were a standard set of commands that programs that would have need of this (network controllers, BBS systems, ray tracers, etc.), it would make your machine much safer. If only the following were supported, this would work well: LinePowerOut - Utility power is out LinePowerBack - Utility power is back online BattPowLow - Battery power is low, and the program should exit immediately. A program could see the line power our message, and choose to remain running if someone was using the program, but would exit and save data if the battery power went out. That way, should the power only go out for a few minutes, it would receive the line power back message, and could keep on running as if the power never went out at all. Would anyone be interested in putting support for something like this in their code besides me? Dave
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/18/90)
Dumb question I suppose, but could the problem of having M edit command providers talk to N editors be ameliorated by writing an intermediate AREXX module that accepted a common stripped down consensual editing command set and emitted commands translated for editor n of N? I.e, this one maintained piece of software would have to be kept current with the superset of editor commands, but all the programs using it to control editors could remain oblivious to just which editor was out there, while the intermediary put up a requestor or grabbed an ENV: entry to learn which editor/port it should address. Just a thought. It worked with graphics standards, that's why there's a CGM. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peter@sugar.hackercorp.com (Peter da Silva) (11/18/90)
In article <18391aac.ARN2504@starsoft.UUCP> david@starsoft.UUCP writes: > Could you be a bit more specific on this? > I am in the process of developing an AREXX compatable program. I would > like to use this "standard", it it appears to be useable. > Where can I get info on it? Ditto. Plus, I need to make the TCL IPC mechanism compatible with AREXX, so I need to make sure that there are no conflicts between AREXX commands and TCL commands. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
giguere@csg.uwaterloo.ca (Eric Giguere) (11/19/90)
Actually, I said too much already. If you really need info, I would talk to
your CATS rep. If you're not a certified developer then you'll have to wait.
Sorry.
--
Eric Giguere giguere@csg.UWaterloo.CA
Quoth the raven: "Eat my shorts!" --- Poe & Groeningdavidm@uunet.UU.NET (David S. Masterson) (11/19/90)
>>>>> 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.
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. Scripts
desiring to be standard would work indirectly off this list whereas people not
up to standardization yet would use the program's internal commands directly
(because those are the one's they would most like learn first).
This is a neophyte suggestion, so does this make sense?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"nj@magnolia.Berkeley.EDU (...) (11/20/90)
cimshop!davidm@uunet.UU.NET (David S. Masterson) said: >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. Not necessarily. You could have both a GNU-style and a standard-style set of commands around, the former for scripts that you write to work only with MG and the latter for compatibility with "standardized" ARexx scripts. Presumably the functionality required by the standard-style commands would be a subset of the functionality of MG, so this wouldn't involve adding anything to MG besides mappings between the standard-style commands and MG's usual commands. nj
jeh@sisd.kodak.com (Ed Hanway) (11/20/90)
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.
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (11/20/90)
In article <yorkw.658814848@stable.ecn.purdue.edu> yorkw@stable.ecn.purdue.edu (Willis F York) writes:
Ever see MFF+ (MicroFiche Filer +) I don't have the Manual handy but the
Arexx commands are Annoying "Named" here are a few top'o my head
suggestions to help smooth out commands/ports
Huh? I use MFF+ on a regular basis. Off the top of my head, it's the
BEST example of how to do an ARexx interface I've run into. I _think_
you're complaining about case sensitivity - and MFF+ isn't case
sensitive. Commands can be issued in any case. Please provide more
details if this isn't the case.
Have the port name in Lowercase letters.
use all lowercase. (I spent an Hour figering oou why somthing wasen't working
, Aress was upper casing the portname and i needed to ad some ' marks)
Actually, to solve your problem, the port name needs to be in UPPER
case, not lower. That way, you don't need to quote the port name.
Give Nice names to the commands but avoid LONG command names.
Mff+ is a good bad example of this.
And LSE is a good example of going to far the other way (all the
commands are two-character sequences, with possible two-character
arguments).
To get WB to front (I think this is right) the command is .
"MFF+_to_Back"
. (Descripitive but annoying)
All the other commands are equally weird.
the Case is Mixed also, which has caused problems.
The commands are listed in mixed case; MFF+ is quite happy swallowing
them in whatever case you wish to use.
(MFF uses a Weird way of Macros which are rexx scripts in single quotes
and commands.mff which are normal rexx stuff.
That's not wierd, that's normal. Looks just like wshell (or mg3, for
that matter). It's what ARexx provides by default when you send a
macro to ARexx from the application.
<mike
--mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (11/20/90)
In article <CIMSHOP!DAVIDM.90Nov18152138@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
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. Scripts
desiring to be standard would work indirectly off this list whereas people not
up to standardization yet would use the program's internal commands directly
(because those are the one's they would most like learn first).
This is a neophyte suggestion, so does this make sense?
Yes, it does make sense. For sufficiently simple commands.
Remember, commands are the _easy_ half of doing an ARexx design for an
application. You have to decide what objects you're going to let the
user manipulate, and how those objects are going to be represented to
the Rexx script. After all, it's tweaking the text in the editor
that's what makes Rexx scripts entertaining.
Let's take simple example: copying a region of text from one place to
another. What's involved?
Selecting the source region. How does your editor select a single
point in the text? Line/offset pairs? Offset into the entire text? By
searching for it? How is the region represented? Two points? Point +
length? Does length include newlines?
Repeat much of this for selecting the insertion point.
Now, creating a copy of the text to be copied. Do we need to store an
intermediate somewhere? Does the editor provide a place for it? Does
using that place destroy what was in it before? Can we use the system
clipboard? Does the Rexx script have to copy the data?
Now, insert the text. Can I just do a single command to insert the
text in place, or do I need a loop of some kind? Do I need to position
the cursor first? Does where the cursor is afterwards matter?
Finally, delete the text you started with. Assuming you have to.
You don't want to use only "incredibly simple" commands. That will
leave the script writers doing everything in ARexx, which will be a
performance hit when the editor can do it all at once. With that in
mind, I suspect the correct thing to do is define a hi-level language
for doing things that avoids things hard to do from a Rexx script, and
then let editor authors provide a macro package to deal with this.
Of course, if part of the command interface is that "macros can be
invoked as commands", mg will never support it well.
<mike
--set@phobos.cis.ksu.edu (Steve E Tietze ) (11/21/90)
I pose a question. I want to bu a A3000 buy my dealer said that i couldn't play games on it. But in comp.sys.amiga.games people talk about playing games on them? Or should i get the A2500/3000 ????? Could someone open my mind on why i need to buy a 3000 or should i just get a 2500/3000 Please email set@phobos.cis.ksu.edu
davidm@uunet.UU.NET (David S. Masterson) (11/22/90)
>>>>> On 19 Nov 90 19:57:07 GMT, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) said: Mike> In article <CIMSHOP!DAVIDM.90Nov18152138@uunet.UU.NET> Mike> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: David> Perhaps an alternative suggestion to an AREXX command standard would David> be a single command by which AREXX could ask the program in question David> what its command equivalents for the AREXX standard would be. The David> result of such a command would be a list that's indexed by the standard David> commands. Scripts desiring to be standard would work indirectly off David> this list whereas people not up to standardization yet would use the David> program's internal commands directly (because those are the one's they David> would most like learn first). Mike> Remember, commands are the _easy_ half of doing an ARexx design for an Mike> application. You have to decide what objects you're going to let the Mike> user manipulate, and how those objects are going to be represented to Mike> the Rexx script. After all, it's tweaking the text in the editor that's Mike> what makes Rexx scripts entertaining. Or tweaking the drawing in the CAD program. Or tweaking the painting in the paint program. Or tweaking the animation in the ray-tracing program. Point being, sounds like there could be one h*** of a lot of objects to talk about in an AREXX standard if you start talking at too high or too complex a level. True, its an easy starting place, but all these programs have one thing in common -- they work with commands (in the AREXX context). Attempting to build a standard that incorporates all the possibilities of even just one of these types of programs would effectively make all programs that incorporates these standards the same, wouldn't it? So, wouldn't that tend to reduce distinguishing features between programs making for less incentive to develop new programs of a particular type? (the first one there is the standard?) Mike> Of course, if part of the command interface is that "macros can be Mike> invoked as commands", mg will never support it well. Yet another problem with building a standard that's too high level (standard *commands* equating to *many* program internal manipulations)? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
jap@convex.cl.msu.edu (Joe Porkka) (11/27/90)
cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 19 Nov 90 19:57:07 GMT, mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) said: >Mike> In article <CIMSHOP!DAVIDM.90Nov18152138@uunet.UU.NET> >Mike> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >David> Perhaps an alternative suggestion to an AREXX command standard would >Attempting to build a standard that incorporates all the possibilities of even >just one of these types of programs would effectively make all programs that >incorporates these standards the same, wouldn't it? So, wouldn't that tend to >reduce distinguishing features between programs making for less incentive to >develop new programs of a particular type? (the first one there is the >standard?) It would make for a standard _minimum_ level of functionality. There are still many bells and whistles nobodies thought of yet, new levels of performane and bugfreeness, andy hasst important USER interface design (as oppsed to rexx interface). In any case making programs more similar is GOOD. If I want to do some CAD, or write a book why should I care if I use XYZCAD v.s. ABCCAD ?? I just wanna do some CAD man... The standard AREXX interface does not need to be all encompassing, just a beginning. FOr example, all applications should support a certain set of commands, like LOAD, SAVE, etc... Then all text oriented program should support a few more standard cmds.