Google
 

Trailing-Edge - PDP-10 Archives - mit_emacs_170_teco_1220 - emacs/twenex.losses
There are no other files named twenex.losses in the archive.
Problems with Twenex that ought to be fixed  -*-Text-*-

* GTJFN filename defaulting and completion

  Filename defaulting and completion in GTJFN don't work together
properly.  The way that would be right for EMACS is this (assuming
that the defaults are FOO.BAR):

 If the user types UGH then complete based on what files exist
 starting with UGH, ignoring the defaults.

 If the user types UGH.BLETCH, then use it, regardless of whether the
 file UGH.BLETCH exists.

 If the user types no filenames (<cr> or just a directory name),
 use FOO.BAR as the filenames.

 If the user types just one name, as in UGH<cr>, it should mean UGH.BAR.

This behavior cannot be obtained by any single setting of the
arguments and flags for GTJFN.  TECO has to go to a terrible amount
of trouble, including up to seven calls to GTJFN for one operation,
to do it.  GTJFN should be extended so that this behavior is easily
obtained.


* Interrupt characters

  It causes trouble for EMACS that ^G is not available in the input
stream via PBIN because it causes an interrupt.  Great kludgery is
required to prevent this from losing.  In fact, there are legitimate
TECO programs that would fail to work.  It just happens that EMACS
doesn't contain one of them.  It should be possible for the program to
request that this be done.


* System-wide Help character

  Wouldn't it be nice if you could type ^_ to get help at any time,
not just inside EMACS?  Twenex already has the ability to give help if
you type "?".  However, there are times when "?" cannot be used to ask
for help because an arbitrary text string is being read, and "?" must
be taken as text.  ^_ would not have such a limitation.


* Multiple forks

  EXEC should let you keep several forks.  You should be able to keep
an EMACS while running other programs side by side with it.
Such a feature has existed for a long time in the EXEC at a few sites
that have the source.  DEC's programmers have put code for this into
EXEC, but the conditional is normally off.  So you can't use it unless
you have bought the sources.  From what I hear, marketing people are
to blame.  Your pressure can certainly have an effect on this one.


* TEXTI

  Everyone is eager for EMACS to use TEXTI break masks to do more
efficient echoing of insertion at the end of a line.  Unfortunately,
it can't be used by EMACS (or any comparable editor) because it has so
many misfeatures.  For one thing, it echoes the break character (the
control character or whatever which follows the inserted text)!  There
are other problems: binary mode, which EMACS must use to be able
to read the ^@ character, turns off the break mask and also forces
echoing off.  In addition, there is no way to deal with the Meta bit
on terminals which have it (Meta-A must break whether A does or not).


* Renaming open files

  Twenex does not allow anyone to rename a file that is open.  This
contrary behavior causes trouble if you want to rename all of the
EMACS files from one directory to another -- a natural thing to do if
you are bringing up a new version.  There is no legitimate reason for
not allowing this.

  Also, files cannot be superseded while they are open.  This might be
a little harder to implement than renaming, but not much, because the
file being superseded could simply be renamed into a directory named
<garbage>.  The inability to do this can cause trouble for the batch
file EMACS.CTL, since building TECO writes files whose version numbers
MUST match the TECO source version number.  If an EMACS had been built
before using the same TECO version, the new TECPUR.EXE supersedes the
old one, which is mapped into (and opened by) every EMACS fork.  Thus,
the operation cannot succeed unless every EMACS fork is reset.


* The TYPE command and control characters.

  If you try to look at an EMACS source file with the TYPE command,
you won't be able to tell what's going on, because Altmodes will be
output to the terminal as actual Altmodes, and you won't be able to
see them.  Or, even worse, they will combine with the following
characters to make escape sequences and really screw you.

  The TYPE command should output ALL characters found in the file as
printing or formatting characters.  For instance, Altmodes should be
printed as dollar signs if nothing better is available.  Actual
Altmodes or other nonformatting control characters should never be
output as themselves by TYPE.

  DEC people defend the current behavior saying that it allows people
to put escape sequences in files and print them to do terminal
control.  The two operations
1) printing out a file and seeing what is in it, and
2) sending terminal-specific escape sequences for display control,
are both useful, but the first is fundamental and the second is obscure.
Clearly, it is the fundamental one which should be easiest to ask for.
Nothing says there cannot be another command PRINT-DISPLAY-CONTROL-FILE
for doing the other.