TIP: Click on subject to list as thread! ANSI
echo: public_domain
to: Rod Speed
from: Bill Grimsley
date: 1995-04-24 22:38:40
subject: Msged suggestion

Rod, at 07:17 on Sun, Apr 23 1995, you wrote to Bill Grimsley ...

RS> Yes, but as you validly pointed out, the number of keystrokes can be more 
RS> than is desirable. The answer is to add a decent keyboard oriented task 
RS> switcher to the OS to allow you to go to the task you want in one 
RS> keystroke.

BG> That wasn't at all clear to me from your earlier messages on this subject, 
BG> but now that I know what you meant, I thoroughly agree. However, I'm not 
BG> currently aware of any easy way to accomplish this in OS/2 itself.

RS> Sure, you really need to use a decent addon to do that.

I suspect that if I could get a handle on Rexx programming, it may well be
possible to trap certain key combinations in the WPS.  In fact, the
Watchcat archive even supplies a user-alterable DLL for this very purpose,
but that's too high level for me, I'm afraid.

RS> Sure, but thats STILL the wrong way to use say List in that app.

BG> Rubbish.

RS> Fraid not. Its certainly possible to do it that route, but its MUCH worse 
RS> than doing it with a decent keyboard oriented OS level task switcher, worse 
RS> in quite a few ways.

A bit later you point out one particular area where it may well be more
desirable to task switch via individual hot-keys, but for the most part, it
ain't necessary.  However, Msged itself can actually have hot-keys
programmed which will do almost the same thing.

BG> I now have Msged set up to shell to List with a single keystroke,
BG> and if I need to Edit, Move, Copy, or otherwise act upon a specific
BG> file, that is also performed via a single keystroke in List itself,
BG> then eXiting takes me right back to where I started.

RS> Yes, there is no argument with the keystrokes required. *BUT* that
RS> approach has a number of other disadvantages. It takes time to 
RS> invoke the external as it has to start that task.

The load time is immeasurable Rod.  0.5 of a second maximum to load List,
or to shell out to the external Qedit.  Virtually instantaneous.

RS> Sure you can fart around with caches and ramdisks to minimise that time, 

No need.  How can you improve upon 0.5 of a second?  And why bother?

RS> but its FAR better speed wise to have that List task just loaded already, 
RS> ready for a very quick keyboard oriented task switch at the OS level.

Nope, the time is the same, be it a Msged hot-key, or a task-switch.

RS> The other problem with an external is that the original task isnt
RS> available except by a full return from the external.

Yep, and AFA I'm concerned, that's the ONLY advantage (if it can be called
that), but I have NEVER had occasion to run more than one copy of Msged
here.  Not once.  If I need to C&P, I can use either the OS/2
clipboard, or Msged's own internal routines.  No big deal at all.

Later...  It just occurred to me that another Msged session can be started
via a hotkey as well if necessary (which IMO it's not), so eat shit Rod. 
|-)

RS> With the decent task switch, you can switch back and forward between the 
RS> two at will, as often as you like, instantly once you have pressed the 
RS> keys. Say you jump out of the message to look something up with List, need 
RS> a bit more info from the original message, you have to fart around, exit 
RS> the external invocation of List, back in the message, reread the message, 
RS> reload List wait for that, and you've lost your place in the file you were 
RS> looking at with List too.

Not really, that scenario is covered by just three keystrokes -- F8, X, and
F8 again.  Switching time?  About 1.5 seconds _in total_.

RS> Completely fucked compared with a decent keyboard oriented task switch.

BG> It's by far the most economical use of the keyboard IN MY SITUATION.

RS> Nope, thats crap Bill. There is nothing special about YOUR SITUATION.

Bullshit Rod, at least please show me the courtesy of allowing me to use my
own system the most productive way I know.  Why waste time learning a whole
new series of keystrokes?  Why do you think I still use Shez?  Sure, it's
an abortion key-wise, but I KNOW the keys backwards.  To me, it's a piece
of piss to use, initial steep learning curve or not.

BG> Ergo, there's no "right" or "wrong" way about it.

RS> Bullshit Bill, if one way of doing its is significantly worse, it 
RS> makes no sense to do it that way. 

Show me a faster, more intuitive method, and I'll use it.  I already know
Msged's capabilities, and they are perfect for my use of that app.

RS> Just look at that other argument we had with Paul about the use of an XT by 
RS> a highschool kid for projects. Sure, it is indeed possible to use a single 
RS> tasking system where you have to exit the wp to go and look something up on 
RS> say a CDROM, but its quite fucked compared with doing it the sensible way 
RS> with a decent tasks switcher.

That's a totally different matter Rod.  We were discussing the difference
between a single-tasking XT and a 32-bit MTing system, which has absolutely
nothing to do with this particular discussion at all.

RS> There is indeed a right and wrong way and its only if you cant 
RS> afford the right way etc that it makes any sense to go that route. 

And you call ME a zealot!  Fuck me dead Rod, have a look at some of the
stuff you've posted already on this subject, then tell me who the zealot
is.  |-)

RS> The only sensible way is a better keyboard oriented OS level task
RS> switcher.

BG> Nope, it's not the "only sensible way" at all,

RS> Fraid so, even if you are so locked in the past you cant see it.

That's right, when logic fails, resort to insults and condescension.  |-)

BG> certainly not for the specific purpose I have in mind

RS> The specific situation is just those you listed. The OS level keyboard 
RS> oriented task switch is better IN EVERY WAY, every single one.

Nope.

BG> (and am using now quite successfully),

RS> No one is saying that the external wont work, just that its fucked
RS> compared with doing it properly.

Properly?  What an interesting word that is.  You'd do well to use it
correctly next time too.  |-)

BG> and if I wanted to run my messages through a spelling-checker for example, 
BG> there ain't no easier way to do it than with a Msged macro (as Chris does 
BG> now).

RS> Well, spelling checkers are different, mainly coz they cant be as easily 
RS> invoked with a simple OS level task switch.

No, the app has to export the text somehow.

RS> In this case the problem is that its the integration of the spelling 
RS> checking into the mail reader which is fucked, so you have to kludge it up 
RS> with an external, 

Unlike OLX, Msged was never designed to use an integrated spelling checker,
although I don't doubt that it could be done.  The fact that it's possible
at all though is still an advantage.

RS> with a level of knowledge which is well above what the average user can 
RS> managed. THATs totally fucked.

Not any more.  If using an external editor the problem doesn't exist.  For
example, Qedit/2 now has an integrated spelling checker supplied, and it
works exceptionally well, although it does check quoted text as supplied,
but a Qedit macro can easily overcome that minor niggle.

RS> And even a fully integrated spelling checker should be invoking a
RS> full task switch at the OS level when the app is designed for a 
RS> proper modern multithreaded OS. Because again, otherwise you just 
RS> have to fart around with dinosaury stuff like caches and ram drives 
RS> for decent performance. 

Not on a DX2/66 with 16Mb, you don't.

RS> Again, dinosaury kludgy abortion. The world has moved on.

Suit yourself.  You can sit on your arse and let others do all the hard
work if you wish, it's fine by me.  OTOH, some of us like to experiment
with certain things.  Stops the world from stagnating.

Regards, Bill
@EOT:

--- Msgedsq/2 3.05 alpha
* Origin: VK4CQ, Logan City, Qld. (3:711/934.18)
SEEN-BY: 640/305 690/718 711/809 934 30163/9
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.