Classic_-_Concepts@cup.portal.com (03/05/89)
I have the problem of too many ideas (3 games in my head right now) and
too little time to implement even 1/4 of them. Since there might be people
out there with more time and fewer ideas, I thought I'd propose this one on
the net.
I tend to type fast (83+ on a broken-down Selectric, 90++ on a word-
processor), but even that isn't fast enough to keep up with thought processes
(I get frustrated trying to write stories, journals, etc. because I lose the
thought by the time my fingers catch up). It occurred to me that probably
everyone would like to be able to type/write faster, especially hunt-and-
peckers and that the computer offers an unprecedented opportunity to provide
a way to do this within an editor or wordprocessor. Here is the idea:
Remember speed-writing? The alternative to cryptic shorthand languages?
Well, why not implement a form of speed-writing within a word-processor?
you could have a dictionary of short forms of words similar to speed-writing
abbreviations which would be then parsed out, either:
1. as you type
2. when you hit a return (I'd prefer this, less intrusive)
(this should also be 'disablable' <- forgive the awful word)
3. at the end of paragraphs or ....
It should definately have a configurable dictionary. That way if the
user is not comfortable with some of the abbreviations or wants to add some
for proper names, etc. s/he would have that option. If the parser were based
on current speed-writing languages, then those who already know it could
learn it quickly and those who don't would be using a system which at least
has some trial and error and research behind it. However, something to
think about is that abbreviations which are appropriate for hand-written
speed, might not be the best for keyboard (qwerty) speed, so perhaps there
is a graduate project here to develop 'keyboard speedwriting' recommendations
and paramaters.
Anyway, the reason I posted this on the Amiga.tech is because I'd like
see it implemented on the Amiga, of course. I'd like to see it on the Amiga
first! I don't know if anyone else has thought of this idea. I haven't
seen anything else on it, but then I haven't actively researched it. These
musings usually pop into my head just before I fall asleep and half of them
disappear by morning.
Well, the goal would be to type 150-250 words per minute. Why not?!
That's what computers are for. Actually, the goal is to improve anyone's
typing by 50%-300% or more. Anyone interested in pursuing this?? The actual
implementation seems to me to be very straightforward. The difficult part
would be deciding on whether to use current speedwriting forms or to develop
or find ones appropriate to keyboard input.
\_
)\_ _/
`/)\_ __ //
__ _____________________________________________ `\\)\_ / '~//
/// Julie Petersen (LadyHawke@cup.portal.com `\\//\\/|'//'
/// Classic_-_Concepts@cup.portal.com) (\/Yyyy/'
__ /// "There are days when spelling Tuesday simply /Yyyy/'
\\\ /// doesn't count."- Rabbit in Winnie the Pooh //\\ LadyHawke
\\/// _______________________________________________ ///\\\ mp1u+@andrew.cmu.edu (Michael Portuesi) (03/06/89)
Classic_-_Concepts@cup.portal.com writes: > Well, why not implement a form of speed-writing within a word-processor? > you could have a dictionary of short forms of words similar to speed-writing > abbreviations which would be then parsed out, either: > 1. as you type > 2. when you hit a return (I'd prefer this, less intrusive) > (this should also be 'disablable' <- forgive the awful word) > 3. at the end of paragraphs or .... GNU Emacs already has this, in two modes. One is abbrev mode, which expands abbreviations from a configurable dictionary. The second is dabbrev (dynamic abbrev) mode, which expands abbreviations by searching backwards through the current buffer until it finds the first word containing the abbreviation as an initial substring, then using the found word as the expansion. Now all you have to do is port GNU Emacs to the Amiga. -- Michael Portuesi / Information Technology Center / Carnegie Mellon University INET: mp1u+@andrew.cmu.edu / BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ "You just don't get off a spaceship and run." --Avon
ejkst@cisunx.UUCP (Eric J. Kennedy) (03/06/89)
In article <15381@cup.portal.com> Classic_-_Concepts@cup.portal.com writes: > I tend to type fast (83+ on a broken-down Selectric, 90++ on a word- >processor), but even that isn't fast enough to keep up with thought processes >(I get frustrated trying to write stories, journals, etc. because I lose the >thought by the time my fingers catch up). It occurred to me that probably >everyone would like to be able to type/write faster, especially hunt-and- >peckers and that the computer offers an unprecedented opportunity to provide >a way to do this within an editor or wordprocessor. Here is the idea: > > Remember speed-writing? The alternative to cryptic shorthand languages? > > Well, why not implement a form of speed-writing within a word-processor? >you could have a dictionary of short forms of words similar to speed-writing >abbreviations which would be then parsed out, either: Some interesting ideas, here. UN*X vi does some of this, with its abbreviation capability. I've added this capability to Uedit as part of my vi emulator. It's done with Uedit's "preKey" command. The "preKey" command is executed every time you press a key (or a mouse button or select a menu item), *before* the command bound to the key is executed. It's not difficult to test for the end of a word, copy the word into a buffer, look for the word in a list of abbreviations, and make the substitution if its found. I also use Uedit's spelling checker on the word for real time spell checking, while I'm at it. I think Uedit would be an excellent test bed for ideas like yours, if not for a final system. You can remap the keyboard at will; use the ideas below to make templates, abbreviations, whatever; you can even use an internal timer to execute commands after certain periods of delay. The preKey command below is straight from my custom configuration. It looks for a list of abbreviations and expansions in buffer 32 of the form abv abbreviation csa comp.sys.amiga cats Commorodore Amiga Technical Support etc. It obviously doesn't do all of what you're asking for, but it's a step in the right direction. To experiment with this, you either need to be using the spell-checking version of Uedit, or modify the command to skip the spell-checking stuff. ---------------- <preKey: .. Uncomment the next two lines when debugging a preKey command! .. if (eqNum(macroNum,shftAltCtl-esc)) killKey(preKey) .. ESCAPE HATCH! .. if (eqNum(macroNum,shftAltCtl-esc)) killKey(virtual-kp2) .. ESCAPE HATCH! if (not spellerUp) if(isEmpty(buf32)) return if (eqNum(inputChar,0)) return .. do not mess up scrolling etc! if (eqNum(macroNum,65)) return .. do not test when backspacing! or(n50,inputchar,32) if(geNum(n50,97)) if(geNum(122,n50)) return ..return if alpha if(eqNum(inputChar,"'")) return if(is(curFile,alpha)) return equateLoc(curFile,locA,atCursor) .. save cursor loc .. is not alpha, check preceding word clearRgn(buf54,all) .. erase last word from buffer moveCursor(curFile,sWord) .. move cursor to start of word to chk if(moveCursor(curFile,sChar)) ..Do not flag words that begin if(is(curfile,"\\")) ..with \, for tex commands. { equateLoc(curFile,atCursor,locA) .. put cursor back where it was return } else moveCursor(curFile,eChar) insertRgn(buf54,sFile,curfile,word) .. store just that 1 word insertChar(buf54," ") ..add space at end of word moveCursor(buf54,sFile) .. so speller sees the word insertChar(buf54,eLine) ..add return before word .. Now word is bracketed by a carriage return and a space. .. This is for matching abbreviations in buf32, and it does not .. effect spell checking. if(isEmpty(buf32)) goto label(1) if(not getFlag(curFile,userLocalB)) goto label(1) moveCursor(buf32,sFile) setSearch(buf54) if(search(buf32,locA,locB,1)) { moveCursor(buf32,eWord) moveCursor(buf32,eChar) equateLoc(buf32,locA,atCursor) moveCursor(buf32,eLine) equateLoc(buf32,locB,atCursor) clearRgn(curFile,word) insertRgn(curFile,atCursor,buf32,loc) goto label(99) ..do not spell check replacements } label(1) if(spellerup) if (not spell(buf54)) .. bad word { beepDisplay putMsg(buf54) } label(99) equateLoc(curFile,atCursor,locA) .. put cursor back where it was > -- Eric Kennedy ejkst@cisunx.UUCP
peter@sugar.hackercorp.com (Peter da Silva) (03/06/89)
In article <15381@cup.portal.com>, Classic_-_Concepts@cup.portal.com writes: > Well, why not implement a form of speed-writing within a word-processor? > you could have a dictionary of short forms of words similar to speed-writing > abbreviations which would be then parsed out... The 'vi' editor on UNIX already does this. Type ':abbr csa comp.sys.amiga' Then when you type 'csa ' You get 'comp.sys.amiga '. Any whitespace keys it off... -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
451061@UOTTAWA.BITNET (Valentin Pepelea) (03/06/89)
Michael Portuesi <mp1u+@andrew.cmu.edu> writes in Message-ID: <sY4O6Qy00VsfA0U45y@andrew.cmu.edu> > Now all you have to do is port GNU Emacs to the Amiga. It's been done already. An entire Fish disk has been devoted to it, and I'm talking about the real thing, not MicroEmacs 3.9e. > Michael Portuesi / Information Technology Center / Carnegie Mellon University Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phone: (613) 233-1821 system without virtue." Bitnet: 451061@uottawa.bitnet Usenet: cunyvm.cuny.edu!451061@uo... - Ancient Inca Proverb Planet: Um, the second one from the...
UH2@PSUVM.BITNET (Lee Sailer) (03/06/89)
In article <15381@cup.portal.com>, Classic_-_Concepts@cup.portal.com says: > > Remember speed-writing? The alternative to cryptic shorthand languages? > > Well, why not implement a form of speed-writing within a word-processor? >you could have a dictionary of short forms of words similar to speed-writing >abbreviations which would be then parsed out, either: This was done rather well back in the early 70s for mainframes. I believe the creator's name was Stuart Lamb, who was a Berkeley or Stanford linguist. I saw it demoed, and it worked great. It never caught on I guess, perhaps because tho it is a good technical hack, it turned out to be useless to 99% of the typing world.
scotth@harlie.SGI.COM (Scott Henry) (03/07/89)
From article <8903061529.AA11042@jade.berkeley.edu>, by 451061@UOTTAWA.BITNET (Valentin Pepelea): > >> Now all you have to do is port GNU Emacs to the Amiga. > > It's been done already. An entire Fish disk has been devoted to it, and I'm ^^^^^^ Not bloody likely on only ONE disk, just the elisp directory is over 3MB, the on-line help (info) directory in > 1MB, and I would be surprised if the executable could be shrunk much below 500KB. GNU Emacs is a memory hog when its running! You may be thinking about mg[1a|1b|2a|2b], which DO fit on one disk, but is most emphatically NOT GNU Emacs! Its piggishness is the main reason I stopped working on the port, as much as I would like to have it at home, also. If someone has done the port, though, I am very interested! Could you tell me more info? > >> Michael Portuesi / Information Technology Center / Carnegie Mellon University > > Valentin -- --------------------- Scott Henry <scotth@sgi.com> #include <std_disclaimer.h>
mp1u+@andrew.cmu.edu (Michael Portuesi) (03/07/89)
451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > Michael Portuesi <mp1u+@andrew.cmu.edu> writes in > Message-ID: <sY4O6Qy00VsfA0U45y@andrew.cmu.edu> > > > Now all you have to do is port GNU Emacs to the Amiga. > > It's been done already. An entire Fish disk has been devoted to it, and I'm > talking about the real thing, not MicroEmacs 3.9e. > The editor to which you are referring is MG, which is a variant of MicroEmacs that has the "look and feel" of GNU Emacs. It lacks the Lisp language that miracles like abbrev and dabbrev mode are written in. A real port of GNU Emacs would occupy much more than just one disk in Fred Fish's collection. One disk would barely be enough to hold the executable binary. -- Michael Portuesi / Information Technology Center / Carnegie Mellon University INET: mp1u+@andrew.cmu.edu / BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ "You just don't get off a spaceship and run." --Avon
Classic_-_Concepts@cup.portal.com (03/09/89)
I've had some thoughts since the original post re: speedwriting implemen-
tations within wordprocessors:
a. In a sense, if the abbreviations are switchable to/from abbrevia-
ted state, then it would also, secondarily, work as a type of
simple compression algorithm. If words are truncated by an average
of 50% while being typed, then file size, also, is reduced by half.
b. Learning the abbreviations is not restrictive, since you could begin
to use them as you became familiar with them; there would be no
necessity of learning the whole system at once.
c. Rob Peck suggested that a character-sequence or hot-key or some
keystroke other than the RETURN character might be a better way to
cause parsing out of the short forms. I agree.
d. Abbreviations which might be appropriate for speedwriting are not
always great for speedtyping. Most people don't know their numbers
too well, so using '2' as an abbreviation for two or too might not
be easier to type (long stretch, look at the keyboard, slow, slow).
e. Abbreviating short words would be less useful than long ones, so you
wouldn't want to 'waste' an abbreviation on 'at' or 'and', although
some words, like 'the' are so commonly used, that perhaps a 't' would
be suitable.
I'm excited to see there's some interest and prior work on this. Is
there more forthcoming? Good sources for a dictionary?