CTRL/O IN EVE
2051e...@vms.csd.mu.edu
nothing happend, eve keeps waiting for key/key combination to be entered. It
seems that ctrl/o is never sensed by eve. Can anybody explain this?
note: I'm using VMS 5.2.5
Omar Elwary
2051E...@VMS.CSD.MU.EDU
fair...@slacvx.slac.stanford.edu
> I attempted to define the ctrl/o key combination to mean "one window" in tpu
> nothing happend, eve keeps waiting for key/key combination to be entered. It
> seems that ctrl/o is never sensed by eve. Can anybody explain this?
Yes. Take a look at HELP TPU NONDEFINABLE_KEYS. It states in part:
[...]
The following keys can be defined -- although doing so is not recommended
-- only under some special terminal settings, as follows:
CTRL/C, CTRL/O, To execute a procedure or program bound to
CTRL/X, and F6 one of these keys, you must have entered
the DCL command SET TERMINAL/PASSTHRU.
[...]
There is more. Please take the time to read what I've omitted.
The point is that it is the _terminal_driver_ which "sees" and handles
the CTRL/O. EVE/TPU never gets a chance. You _may_ set your terminal as
described in the HELP, but I would discourage it due to the other side
effects (e.g. CTRL/O no longer works at DCL, nor does CTRL/C at DCL or in
EVE, etc.).
The restriction is really just a DCLism, or VMSism, but it's very
widespread in terms of applications counting on the default behaviour. If
you insist on going against convention, wrap your invokation of EVE in a
command procedure which saves the terminal's [NO]PASSTHRU setting, does the
SET TERM/PASSTHRU, and then invokes the editor. On exiting EVE, it should
reset the the terminal [NO]PASSTHRU setting to the saved value.
-Ken
--
Dr. Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 98 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | FAX: (415) 926-4335
----------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Heribert Dahms
: I attempted to define the ctrl/o key combination to mean "one window" in tpu
:
I suggest using another key sequence. How about:
<PF1> O
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
fair...@slacvx.slac.stanford.edu
> In article <1993Mar15...@slacvx.slac.stanford.edu>
> fair...@slacvx.slac.stanford.edu writes:
>> The point is that it is the _terminal_driver_ which "sees" and handles
>> the CTRL/O. EVE/TPU never gets a chance. You _may_ set your terminal as
>> described in the HELP, but I would discourage it due to the other side
>> effects (e.g. CTRL/O no longer works at DCL, nor does CTRL/C at DCL or in
>> EVE, etc.).
>
> this automatically--- other editors do and if done properly, there are no side
> effects. So I would put part of the ``blame'' on EVE/TPU.
I don't think so, (IMHO :-). If I get caught in a looping LEARN
sequence, I sure as hell want CTRL/C to interupt it. That depends on
TPU's CTRL/C AST handler being available. With /PASTHRU set, the
CTRL/C ast won't be delivered (I'm making a pretty big assumption here...
will someone more knowledgable please correct me if I'm wrong 8-).
And I don't consider CTRL/Y an alternative since that boots me clear
out of the editor. A CONTINUE a DCL just gets me into the same loop;
doing something else looses my edits.
In other words, I think consistency with the rest of VMS is a major
_benefit_ here. If you need an application to act like un*x or messy-dos,
then you _may_, but it's "user beware".
What do others think?
John E. Davis
fair...@slacvx.slac.stanford.edu writes:
I don't think so, (IMHO :-). If I get caught in a looping LEARN
sequence, I sure as hell want CTRL/C to interupt it. That depends on
TPU's CTRL/C AST handler being available. With /PASTHRU set, the
CTRL/C ast won't be delivered (I'm making a pretty big assumption here...
will someone more knowledgable please correct me if I'm wrong 8-).
And I don't consider CTRL/Y an alternative since that boots me clear
out of the editor. A CONTINUE a DCL just gets me into the same loop;
doing something else looses my edits.
I do not know how TPU functions internally but I do know that it could be made
to do the stuff that you want above. However, I can speak about my own
editor which runs under VMS (JED). In JED (0.84 and above), the user can
select the abort character to be ^C. The abort character will abort all
keyboard macros as well as functions written in the extension langauge.
In fact, the abort character is caught by JED's keyboard AST.
--
_____________
#___/John E. Davis\_________________________________________________________
#
# internet: da...@amy.tch.harvard.edu
# bitnet: davis@ohstpy
# office: 617-735-6746
#
fair...@slacvx.slac.stanford.edu
[...]
> The restriction is really just a DCLism, or VMSism, but it's very
> widespread in terms of applications counting on the default behaviour. If
> you insist on going against convention, wrap your invokation of EVE in a
> command procedure which saves the terminal's [NO]PASSTHRU setting, does the
> SET TERM/PASSTHRU, and then invokes the editor. On exiting EVE, it should
> reset the the terminal [NO]PASSTHRU setting to the saved value.
J. Biggerstaff <J...@STC10.CTD.ORNL.GOV> took me to task for that:
# Your message about ^O was, of course, correct except for one glaring
# error. Several places you misspelled PASTHRU as PASSTHRU.
#
# This is significant because, as I recall, PASSTHRU is actually
# interpreted as PASSALL which is now undocumented and probably undesirable!
Well, I didn't really _misspell_ it in the classical sense, since I
just _copied_ verbatum the TPU HELP entry. It was the guy or gal doing
the TPU documentation that messed up :-( On the other hand, it is my fault
that I didn't go back and check the help on SET TERM /PASTHRU (sic). :-)
^^^^^^^
BTW, a quick perusal of SET.CLD (using VERB) verifies J. Biggerstaff's
assertion: /PASSxxxx _would_, indeed, be interpreted as /PASSALL. Thanks
for pointing this out. :-)
Carl J Lydick
>nothing happend, eve keeps waiting for key/key combination to be entered. It
>seems that ctrl/o is never sensed by eve. Can anybody explain this?
>
>note: I'm using VMS 5.2.5
Control-O is used by the terminal driver to toggle whether or not output to the
terminal is suppressed. It never gets to TPU unless you set your terminal
/PASTHRU before invoking the editor.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Thomas H. Hopson
In article <1993Mar16...@slacvx.slac.stanford.edu>,
fair...@slacvx.slac.stanford.edu writes:
>In article <1993Mar15...@slacvx.slac.stanford.edu>,
>[...]
>> The restriction is really just a DCLism, or VMSism, but it's very
>> widespread in terms of applications counting on the default behaviour. If
>> you insist on going against convention, wrap your invokation of EVE in a
>> command procedure which saves the terminal's [NO]PASSTHRU setting, does the
>> SET TERM/PASSTHRU, and then invokes the editor. On exiting EVE, it should
>> reset the the terminal [NO]PASSTHRU setting to the saved value.
>
> J. Biggerstaff <J...@STC10.CTD.ORNL.GOV> took me to task for that:
># Your message about ^O was, of course, correct except for one glaring
># error. Several places you misspelled PASTHRU as PASSTHRU.
>#
># This is significant because, as I recall, PASSTHRU is actually
># interpreted as PASSALL which is now undocumented and probably undesirable!
>
> Well, I didn't really _misspell_ it in the classical sense, since I
>just _copied_ verbatum the TPU HELP entry. It was the guy or gal doing
>the TPU documentation that messed up :-( On the other hand, it is my fault
>that I didn't go back and check the help on SET TERM /PASTHRU (sic). :-)
> ^^^^^^^
Of course, the neatest thing about the whole spelling issue is the VMS
help entry on the qualifier:
SET TERMINAL /PASTHRU
/PASTHRU
/NOPASTHRU (default)
[...]
Make sure that you spell both these qualifiers exactly as they
appear in the text.
I guess they got one too many calls, eh?
- Tom
--
Thomas H. Hopson work: mgr...@rosevc.rose-hulman.edu
VMS Manager / CS geek mgrthh@rhit
Rose-Hulman Institute of Technology play: hops...@cs.rose-hulman.edu
Terre Haute, Indiana
Carl J Lydick
=fair...@slacvx.slac.stanford.edu writes:
= The point is that it is the _terminal_driver_ which "sees" and handles
= the CTRL/O. EVE/TPU never gets a chance. You _may_ set your terminal as
= described in the HELP, but I would discourage it due to the other side
= effects (e.g. CTRL/O no longer works at DCL, nor does CTRL/C at DCL or in
= EVE, etc.).
=
=What you say is true but I do not know why EVE/TPU does not have code to do
=this automatically--- other editors do and if done properly, there are no side
=effects. So I would put part of the ``blame'' on EVE/TPU.
Well, let's take a look at how things are now and how you're suggesting they be
changes. Now, when I fire up TPU, it uses my terminal settings exactly as I
set them. If I set the terminal /PASTHRU, it stays that way. If I set it
/NOPASTHRU, it stays that way. Mostly, I want the terminal /NOPASTHRU. On
rare occasions I'll want it set /PASTHRU, but those occasions are, as I said,
quite rare. If things had been done your way, then I'd have no control over
this. EVE would muck with the terminal settings every time I fired it up. I,
for one, would be quite unhappy with this. I suspect most other people using
the editor would object, too. Any time someone wrote a TPU procedure that got
stuck in a loop, they'd have to log in elsewhere to stop the process stuck in a
loop. (Yes, I know, EVE could process the control characters itself, but then
we'd be back where we are now, except that there'd be more overhead).
Jerry Leichter
your terminal as described in the HELP, but I would discourage it
due to the other side effects (e.g. CTRL/O no longer works at DCL,
nor does CTRL/C at DCL or in EVE, etc.).
What you say is true but I do not know why EVE/TPU does not have code
to do this automatically--- other editors do and if done properly,
there are no side effects. So I would put part of the ``blame'' on
EVE/TPU.
EVE doesn't do this for a very simple reason: It follows DEC's standard for
text-mode user interfaces.
One of the great, unappreciated strengths of VMS is its well-defined user
interface. DCL, whatever you may think of it, is VERY predictable: You
can generally guess how to frame at least simple commands for programs you've
never seen before, and you are almost always right. For example, you can use
/LIST with any DEC compiler, and with many other programs for which the
concept of a listing makes sense.
Similarly, you can learn ONCE what a small set of control characters mean,
and they will mean that in just about every context within VMS. Or take a
look at the keypad interface: You can define keys in the same way, using the
same names, in DCL, MAIL, the Debugger, and many other places. The default
key bindings are, where possible, quite similar - for example, PF1 is a
prefix, PF2 gets help. The whole notion of a key state - used to implement
PF1 - is also common. In fact, one of the annoying things about EVE is
that it does NOT provide a compatible DEFINE/KEY interface - though it is
fairly close. (VAX NOTES is actually the worst offender here, or was when
I last used it.)
These days, "consistent interfaces" are all the rage. It was the Mac that
finally got the industry in general to understand their importance; these
days, you get a "style guide" and you are expected to follow the rules,
whether the rules of the Mac world, Motif, Windows, or whatever. Nice to
see - but DEC had it years ago.
So, yes, EVE COULD change the meaning of CTRL/O, or CTRL/Q, or CTRL/S. It
doesn't for exactly the same reasons that Mac applications don't all make
up their own file specification windows, but use the standard one - even if,
looked at purely as a local problem, there might be a "better" solution. In
the large, using the standard interface is MUCH better.
-- Jerry
Carl J Lydick
=> this automatically--- other editors do and if done properly, there are no side
=> effects. So I would put part of the ``blame'' on EVE/TPU.
=
= I don't think so, (IMHO :-). If I get caught in a looping LEARN
=sequence, I sure as hell want CTRL/C to interupt it. That depends on
=TPU's CTRL/C AST handler being available. With /PASTHRU set, the
=CTRL/C ast won't be delivered (I'm making a pretty big assumption here...
=will someone more knowledgable please correct me if I'm wrong 8-).
=And I don't consider CTRL/Y an alternative since that boots me clear
=out of the editor. A CONTINUE a DCL just gets me into the same loop;
=doing something else looses my edits.
=
= In other words, I think consistency with the rest of VMS is a major
=_benefit_ here. If you need an application to act like un*x or messy-dos,
=then you _may_, but it's "user beware".
I'm in complete agreement with Ken: I WANT ANY EDITOR I RUN TO KEEP ITS BLOODY
HANDS OFF MY TERMINAL SETTINGS. If I want PASTHRU, I can damned well
explicitly ASK FOR PASTRHU. The suggested default of having an editor muck
with terminal setting seems pretty damned close to a canonical example of
artificial stupidity.
Barry Tannenbaum
rest of VMS.
- Barry Tannenbaum
ex-TPU Developer
David G. North, CCP
da...@pacific.mps.ohio-state.edu ("John E. Davis") writes:
>What you say is true but I do not know why EVE/TPU does not have code to do
In article <1o5q13...@gap.caltech.edu>,
ca...@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> quite rare. If things had been done your way, then I'd have no control over
> this. EVE would muck with the terminal settings every time I fired it up. I,
Why would you mind having 'PASTHRU' mucked with, but not 'BROADCAST' [Which
TPU does via SMG]? And, why _wouldn't_ you object to the editor puking up
escape sequences that leave your terminal hosed over until you do a reset...
[Try aborting an edit with ^Y, STOP and see how screwed your terminal is...]
Ever use SET HOST/DTE or KERMIT? [Yes I know, they can get hung :( ].
Do you object to these programs setting PASTHRU?
My point is that this is a non-problem so long as the editor puts the
terminal back the way it found it... your message seems to imply that
somehow the terminal would be left in /PASTHRU if the original poster's
suggestion were implemented.
Frankly, I think it's a darn good idea & I _do_ wonder why the programmers
who wrote TPU didn't use PASTHRU.
--
David G. North, CCP
D_N...@onDEC.LoneStar.Org {...!letni!tachyon!ondec!d_north}
onDEC systems "Everyone's crazy but you & me...
P.O.Box 795848, Dallas TX 75379-5848 and come to think about it, I'm
(214)985-1316 ... (214)902-3957 not so sure about you either!"
fair...@slacvx.slac.stanford.edu
> In article <DAVIS.93M...@pacific.mps.ohio-state.edu>,
> da...@pacific.mps.ohio-state.edu ("John E. Davis") writes:
> [regarding SET TERM/PASTHRU and ^O in EVE/TPU]
>>What you say is true but I do not know why EVE/TPU does not have code to do
>>this automatically--- other editors do and if done properly, there are no side
>>effects. So I would put part of the ``blame'' on EVE/TPU.
>
> In article <1o5q13...@gap.caltech.edu>,
> ca...@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
>> quite rare. If things had been done your way, then I'd have no control over
>> this. EVE would muck with the terminal settings every time I fired it up.
>
> TPU does via SMG]?
Eh?? What gave you _that_ idea? Would you please do an ANAL/
IMAGE on SYS$SYSTEM:TPU.EXE and/or SYS$LIBRARY:TPUSHR.EXE and show
me where SMGSHR appears in the shareable image list?
> And, why _wouldn't_ you object to the editor puking up
> escape sequences that leave your terminal hosed over until you do a reset...
> [Try aborting an edit with ^Y, STOP and see how screwed your terminal is...]
I'll give you one point on this. :-) Apparently TPU _does_ change
the setting of BROADCAST to NO BROADCAST and WRAP to NO WRAP.
That's it. I would claim that these are in a different class of
function than those affected by PASTHRU. But I'll grant you that my
Modgraph terminal (DON'T buy one if you can avoid it :-( ) doesn't
behave properly when, on exit, TPU resets the terminal to WRAP: the
Modgraph thinks it needs to reset itself to "autowrap" and I start
getting extra blank lines after wrapped lines. However, I attribute
this its to being a VT-clone that DOESN'T act like a real VT. Same
argument for a terminal emulator that gets itself screwed up by
simple DEC(-private) escape sequences...
> Ever use SET HOST/DTE or KERMIT? [Yes I know, they can get hung :( ].
> Do you object to these programs setting PASTHRU?
There's a time and a place for everything. I just don't think the
editor is the place for this one :-)
> My point is that this is a non-problem so long as the editor puts the
> terminal back the way it found it... your message seems to imply that
> somehow the terminal would be left in /PASTHRU if the original poster's
> suggestion were implemented.
But _my_ point is that I _want_ TPU (EVE) to be able to handle a
CTRL/C _when_ I type it (i.e., via a CTRL/C AST, rather than having
to wait to come back to a read-key in a loop), and I _want_ a CTRL/Y
to get me out of the editor fast, if I need to. And, I _like_
having CTRL/T show me the time in the message window.
> Frankly, I think it's a darn good idea & I _do_ wonder why the programmers
> who wrote TPU didn't use PASTHRU.
Because, as Carl and I, and others, have pointed out, TPU is more
consistent with the rest of VMS this way. You _can_ change this
behaviour if you want to (write a TPU$CALLUSER routine that changes
the terminal settings on startup and restores them on exit, etc.),
but that shouldn't be the default. I think I've heard this referred
to as "The principle of least astonishment". It's a good principle
IMHO. ;-)
-Ken
--
Dr. Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 98 | DECnet: 45537::FAIRFIELD [45537=SLACVX]
Stanford, CA 94309 | FAX: [415] 926-4335
simons/G=Colin/S=Sewell/O...@mhs.attmail.com
[...]
> I'll give you one point on this. :-) Apparently TPU _does_ change
> the setting of BROADCAST to NO BROADCAST and WRAP to NO WRAP.
> That's it. I would claim that these are in a different class of
it also sets /BRDCSTMBX so that broadcast messages sent to the
terminal are sent to the associated mailbox instead. TPU
reads 'em and puts MESSAGE_BUFFER.
Also, Arne Vajh j writes in a separate article
>TPU does not use the SMG$-routines ! TPU use the SCR$-routines, which
>have been obsolete since VMS 4.4 (or something like that) !
nope, TPU certainly doesn't use SCR$ routines either!
(or was that a joke? ;) the screen driver stuff for TPU
is in SYS$SHARE:TPU$CCTSHR.EXE for character cell terminals.
colin sewell
h.a.simons ltd.
vancouver, bc
"simons/g=colin/s=sewell"@mhs.attmail.com
Michael Lemke
>In article <1993Mar18...@slacvx.slac.stanford.edu>
>fair...@slacvx.slac.stanford.edu writes:
> But _my_ point is that I _want_ TPU (EVE) to be able to handle a
> CTRL/C _when_ I type it (i.e., via a CTRL/C AST, rather than having
> to wait to come back to a read-key in a loop), and I _want_ a CTRL/Y
> to get me out of the editor fast, if I need to. And, I _like_
> having CTRL/T show me the time in the message window.
>
>and cannot argue against this point of view. However, the point expressed
>above is irrelavent to the set term/past issue. Granted, the way eve/tpu
>currently works, set term/nopast will disable the ^C/^Y checking that you are
>referring to above. I still maintain that if properly written, it would be
>possible to process the ^C as desired above without waiting for a read-key
>statement--- just look at Emacs (^G instead of ^C but same idea) or JED.
Sure you can change it. But isn't VMS great? You don't have to do
anything and it does handle CTRL/C, CTRL/O etc. the same all the time
without you having to do anything. So why bother? Accept it the way it
is. Makes much more sense than Emacs' fucking redefinition of CTRL/C,
so without the magic CTRL exit password you are stuck (unless you find
the 400 pages manual).
Michael
--
Michael Lemke
Astronomy, UT Austin, Texas
(mic...@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Carl J Lydick
=and cannot argue against this point of view. However, the point expressed
=above is irrelavent to the set term/past issue. Granted, the way eve/tpu
=currently works, set term/nopast will disable the ^C/^Y checking that you are
=referring to above. I still maintain that if properly written, it would be
=possible to process the ^C as desired above without waiting for a read-key
=statement--- just look at Emacs (^G instead of ^C but same idea) or JED.
And Ken maintains that you can do that via a CALL_USER procedure. If you
really want what what you're whining about, get off your ass and write the
program!
David G. North, CCP
fair...@slacvx.slac.stanford.edu writes:
>>
>> Why would you mind having 'PASTHRU' mucked with, but not 'BROADCAST' [Which
>> TPU does via SMG]?
> ^^^
> Eh?? What gave you _that_ idea? Would you please do an ANAL/
> IMAGE on SYS$SYSTEM:TPU.EXE and/or SYS$LIBRARY:TPUSHR.EXE and show
> me where SMGSHR appears in the shareable image list?
to me that it actually uses the SCR$ routines. My point was that it _does_
grab the broadcast-related stuff. I.e. it screws around with the terminal
settings, then puts them back upon exit...supposedly anyway.
[...]
> But _my_ point is that I _want_ TPU (EVE) to be able to handle a
> CTRL/C _when_ I type it (i.e., via a CTRL/C AST, rather than having
> to wait to come back to a read-key in a loop), and I _want_ a CTRL/Y
> to get me out of the editor fast, if I need to. And, I _like_
> having CTRL/T show me the time in the message window.
Yeah... you're right that you don't get the outband ASTs if you're in /PASTHRU,
but would you mind if you got your ^C and ^Y ASTs as terminators for a READ
COMPLETION? The net result is the same [i.e. you actually interrupt whatever
TPU is currently up to], except that TPU could then actually allow the
programmer to redefine ^O, ^Y, ^T, ^C, etc. at will, which was what the first
poster was referring to.
>> Frankly, I think it's a darn good idea & I _do_ wonder why the programmers
>> who wrote TPU didn't use PASTHRU.
> Because, as Carl and I, and others, have pointed out, TPU is more
> consistent with the rest of VMS this way. You _can_ change this
> behaviour if you want to (write a TPU$CALLUSER routine that changes
> the terminal settings on startup and restores them on exit, etc.),
> but that shouldn't be the default. I think I've heard this referred
> to as "The principle of least astonishment". It's a good principle
> IMHO. ;-)
Point well taken, and I basically agree, however, using the above-described
approach, the programmer has full control without having to do anything weird,
_and_ TPU could've easily duplicated the expected behavior of VMS for ^T,^Y,
and ^C without running any real risk of getting permanently hosed over. As it
stands, TPU has almost forced the section-writer to NOT use a certain subset
of the control characters - this can make even partial simulation of other
word/text processing environments difficult or impossible.
Note that this is really just an observation rather than a complaint -
I do like TPU fairly much as it stands.
fair...@slacvx.slac.stanford.edu
> fair...@slacvx.slac.stanford.edu writes:
>>>
>>> Why would you mind having 'PASTHRU' mucked with, but not 'BROADCAST' [Which
>>> TPU does via SMG]?
>> ^^^
>> Eh?? What gave you _that_ idea? Would you please do an ANAL/
>> IMAGE on SYS$SYSTEM:TPU.EXE and/or SYS$LIBRARY:TPUSHR.EXE and show
>> me where SMGSHR appears in the shareable image list?
>
> Oops... you're right of course... Arne Vajhøj was kind enough to point out
> to me that it actually uses the SCR$ routines.
Please, let's put this to rest once and for all. TPU does NOT use
either SMG$ or SCR$ routines!!! (I took Arne to task privately for
this... unfortunately, he was propagating misinformation he'd
gotten from a supposedly reliable source.) TPU.EXE is linked only to
TPUSHR, MTHRTL and LIBRTL; TPUSHR is linked only to MTHRTL and
LIBRTL.
[Arne did point out in a private communication that a number of
images in SYS$SYSTEM _apparently_ do still reference either SCRSHR
or SCR$. He determined this using SEARCH on the images. The single
image I checked, TYPE.EXE, does have the string "SCRSHR" imbedded in
the image, however an ANAL/IMAGE SYS$SYSTEM:TYPE.EXE reports NO
shareable images linked at all! I don't know _what_ that
combination of evidence means...]
> My point was that it _does_
> grab the broadcast-related stuff. I.e. it screws around with the terminal
> settings, then puts them back upon exit...supposedly anyway.
[...]
> Point well taken, and I basically agree, however, using the above-described
> approach, the programmer has full control without having to do anything weird,
> _and_ TPU could've easily duplicated the expected behavior of VMS for ^T,^Y,
> and ^C without running any real risk of getting permanently hosed over. As it
> stands, TPU has almost forced the section-writer to NOT use a certain subset
> of the control characters - this can make even partial simulation of other
> word/text processing environments difficult or impossible.
Except, as I pointed out in an earlier post, the programmer can
easily do the equivalent of SET TERM/PASTHRU via the CALL_USER
mechanism at editor startup. At that point, you _do_ have all the
control keys available as you'd like them. I don't know, however,
if you could establish your own CTRL/C AST, for instance...
Nevertheless, the objections voiced with respect to certain keys NOT
being available within TPU, e.g. for making an emacs clone, or
whatever, is simply not true.
> Note that this is really just an observation rather than a complaint -
> I do like TPU fairly much as it stands.
I do too :-)
-Ken
--
Dr. Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 98 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | FAX: (415) 926-4335
Arne Vajhøj
> >>> TPU does via SMG]?
> >> ^^^
> >> Eh?? What gave you _that_ idea? Would you please do an ANAL/
> >> IMAGE on SYS$SYSTEM:TPU.EXE and/or SYS$LIBRARY:TPUSHR.EXE and show
> >> me where SMGSHR appears in the shareable image list?
> >
> > to me that it actually uses the SCR$ routines.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Please, let's put this to rest once and for all. TPU does NOT use
> either SMG$ or SCR$ routines!!! (I took Arne to task privately for
> this... unfortunately, he was propagating misinformation he'd
> gotten from a supposedly reliable source.) TPU.EXE is linked only to
> TPUSHR, MTHRTL and LIBRTL; TPUSHR is linked only to MTHRTL and
> LIBRTL.
>
> [Arne did point out in a private communication that a number of
> images in SYS$SYSTEM _apparently_ do still reference either SCRSHR
> or SCR$. He determined this using SEARCH on the images. The single
> image I checked, TYPE.EXE, does have the string "SCRSHR" imbedded in
> the image, however an ANAL/IMAGE SYS$SYSTEM:TYPE.EXE reports NO
> shareable images linked at all! I don't know _what_ that
> combination of evidence means...]
I can supply two more facts !
1) If you put TYPE.EXE through DISM32, the you will find one call of
both SYS$IMGACT and SYS$IMGFIX !
2) If you use INSTALL LIST/FULL SYS$SHARE:SCRSHR.EXE to see the
access count of SCRSHR.EXE, you can see that a TYPE/PAGE will
increment the access count by one.
With the risk of goofing again I will conclude, that TYPE/PAGE loads
SCRSHR.EXE dynamicly !
PS: The two undocumented (in the gray wall) system services
SYS$IMGACT and SYS$IMGFIX are the one which is also used
by LIB$FIND_IMAGE_SYMBOL to load shareable images.
Arne
Arne Vajhøj local DECNET: KO::ARNE
Computer Department PSI: PSI%238310013040::ARNE
Business School of Southern Denmark Internet: AR...@KO.HHS.DK
Barry Tannenbaum
1: TPU was written the way it was for consistency with the rest of VMS. It is
not going to be changed at this late date.
2: TPU does *NOT* use SMG$, SCR$ or any other screen handling functions besides
$QIO (on VMS. I don't know what was used on Ultrix)
- Barry Tannenbaum
TPU Project Leader, V2.0 - V2.6