Message-ID: <bnews.cca.4248>
Newsgroups: net.emacs
Path: utzoo!decvax!cca!z
X-Path: utzoo!decvax!cca!z
From: cca!z
Date: Thu Jan 13 05:53:30 1983
Subject: New CCA EMACS Distribution
Posted: Tue Jan 11 19:26:54 1983
Received: Thu Jan 13 05:53:30 1983
A new version of EMACS has now been released by CCA. A number of
important new features have been added since the last release, including
word abbreviation mode, visible marks, and the ability to run shells
inside buffers. Starting with this version, the following new
distribution policy applies:
A CCA EMACS licence is now available for $850 ($350 for educational
institutions). The license is valid for a single CPU; quantity
discounts are available. Those sites interested in purchasing a license
should send me their name and address, and I will send them a pair of
license forms to be filled out. Upon receipt of two completed forms
plus the appropriate fee, CCA will execute the license and send one
completed form to the applicant, along with a tape containing CCA EMACS
(including sources), a complete manual, and command charts.
Major updates of CCA EMACS are available to license holders for $300.
Until March 15th, current users of CCA EMACS who do not hold licenses
may also get the latest release for $300. After March 15th, the rates
quoted in the previous paragraph apply to everyone.
License forms may be obtained by contacting me through uucpnet at
decvax!cca!z, or through the U.S. mail at the following address:
Steven Zimmerman
Computer Corporation of America
Four Cambridge Center
Cambridge, MA 02142
(617) 492-8860
The phone number listed is effective Monday, January 10th, 1983.
Message-ID: <bnews.cca.4253>
Newsgroups: net.emacs,net.usoft
Path: utzoo!decvax!cca!z
X-Path: utzoo!decvax!cca!z
From: cca!z
Date: Wed Jan 19 01:59:28 1983
Subject: Description of CCA EMACS
Posted: Sun Jan 16 19:02:50 1983
Received: Wed Jan 19 01:59:28 1983
Since I announced the availability of CCA EMACS last week, I have been
flooded with questions such as "What is CCA EMACS?", "What are its major
features?", etc. I am posting the following in the hope that it will
answer many of these questions. I will be happy to answer further
questions personally.
Steve Zimmerman
decvax!cca!z
CCA EMACS is a powerful screen editor closely based on the original
EMACS written at MIT. It currently runs on VAXes running Berkeley's
4.0BSD or 4.1BSD. Some of its major features are:
- An interactive spelling checker and corrector, which allows the user
to step through his text, pausing at each spelling error. The user
can either correct the error himself, or have EMACS suggest possible
correct spellings.
- Text filling, justifying, and centering commands, which can work on
lines, paragraphs, or arbitrary regions of text.
- A word abbreviation mode, which allows words, phrases, or arbitrary
regions to be abbreviated by a few characters. Abbreviations may be
saved for use in later editing sessions.
- A directory editor which allows viewing and deleting of files and
directories, as well as editing their protection fields.
- A crash recovery feature using keystroke files as protection against
machine crashes. An auto save mode is also available.
- A "Make" command for automatic compilation of programs, with an
interface which provides easy location of errors.
- The ability to run a shell and arbitrary subprocesses asynchronously
in a buffer. Up to five such shell buffers may be present and in
operation at any one time.
_ Virtually complete compatibility with ITS EMACS. All major features
of ITS EMACS (with the temporary exception of an extension language)
and most minor features are included in CCA EMACS.
- Multiple editing buffers (up to 200), which allow the user to easily
alternate editing between different files in the same session.
- Two window mode, which allows two different buffers (or two different
parts of the same buffer) to be displayed on the screen at once. The
user can adjust the size of each window.
- Keyboard macros, which allow a user to encode a frequently used series
of commands into a single command. A keyboard macro is defined by
executing the commands which are its definition, so there are no
special macro conventions to remember. Multiple keyboard macros may
be defined in a single editing session, and they may be saved in
libraries for later use.
- A "Tags" package, which allows EMACS to move directly to any C
function or variable in any file, without the user's having to know
what file the function or variable is in.
- Commands to pass regions of text through arbitrary Unix filters.
- A ring of sixteen marks, which allow a user to mark various places in
the buffer. These marks may be used as place holders, or they may be
used to delimit regions for other commands. Each buffer has its own
ring of marks.
- A kill ring of sixteen levels, which automatically retains text which
the user has deleted. Text can be later retrieved from any level of
the kill ring into the current buffer. The same kill ring is used
across all buffers, which makes it easy to transfer text from one
buffer to another.
- A set of 37 named registers (known as Q-registers) which are useful
for storing numbers, marks, or text.
- A full set of commands for manipulating rectangular regions. These
are useful for operations such as moving columns around in tables.
- An Auto Fill mode, which causes text to automatically be broken into
separate lines once it reaches a user settable right margin.
- An Undo facility, which allows the last change to the buffer to be
undone.
- Extensive online documentation, ranging from self-documenting commands
to an interactive tutorial to a full hierarchical online manual,
complete with its own specialized reading program.
- A full set of forward and backward movement, deletion, and
transposition commands for characters, words, sentences, paragraphs,
program expressions, and arbitrary regions.
- Powerful search and replace commands, which do case independent
matching at the user's option. There is also a Query Replace command,
which allows the user to decide at each occurrence of the specified
string whether that occurrence should be replaced or not. All search
and replace commands have variations which use Unix regular
expressions, and all may optionally traverse buffer boundaries.
- Optional numbering of the lines in the buffer by EMACS.
- More than 50 user settable variables, which allow each user to
customize EMACS in the way he or she prefers. The local variables
feature allows the same variable to have different settings for
different buffers.
- Dynamic key binding, which allows users to determine themselves which
commands they want to have bound to which keys.
- Init files, which allow variable setting and key binding to be
automatically done at the beginning of each editing session.
Message-ID: <bnews.cca.4298>
Newsgroups: net.emacs
Path: utzoo!decvax!cca!t-krgr
X-Path: utzoo!decvax!cca!t-krgr
From: cca!t-krgr
Date: Thu Feb 3 05:07:58 1983
Subject: Evaluation of CCA EMACS
Posted: Wed Feb 2 13:09:29 1983
Received: Thu Feb 3 05:07:58 1983
I lead a team of UNIX software engineers at Translation Systems Inc. in Boston.
We are re-hosting System III (soon to be V) to the National Semiconductor 16000
series architecture. (Yes, we are installing a full demand paging system in
the first release; no, we aren't involved with the NS/HCR port.)
In the process, we have been among the very few external organizations using
the current release of CCA EMACS. Our experience with C-E dates back to early
fall 1982, on a VAX-11/780 system maintained by CCA in Cambridge. Members of
our team have used Gosling's EMACS; our company is also a test site for another
version of EMACS that runs on a PR1ME system in-house. (Since we are a test
site, that version will NOT be discussed here.) Collectively, we have used
a bunch of other editors on various systems, some interesting (old and new
EDT for RSX, EDT for VMS, TECO, Fastedit, etc etc), and some we'd rather forget
(how about the MPX-32 v1.4 line editor?).
Preferences in editors rank right up there with politics, religion and
salary as dangerous topics of conversation. I won't spend time here defending
the extent of my objectivity here other than to mention that the information
presented here can be independently verified easily. I would like
to hear of conflicting views, with concrete data.
1. Always my favorite point of comparison, reliability. We have NO experience
with C-E failures, over a period of over 4 months of very heavy use.
We have of course been on the system during some significant hardware
(disk) failures, cases in which the C-E crash recovery has proven very
helpful since it is based on journal files and edit history directories that
remember the contents of buffers and the keystokes that apply to each buffer.
When you go into crash recovery, it plays a 'movie' of the edit session up to
the last few keystrokes before the crash. You then continue the edit as you
wish. Very nice! (Regular Auto-Save is available, too.)
2. Features worthy of note:
- The commands are built-in, with none of the delays and processing
attendant with the 'libraries' approach; this makes it seem
more time-effective to learn and use the less common commands.
(There are 379 commands at last count.)
- To the degree that they can, the command keystrokes make sense in
an effort has obviously been made to keep some orthogonality
for related functions.
- Mark and point can delimit a rectangular area on the screen, where
neither need be at the beginning of a line. These rectangular
regions can be opened, filled, etc., which makes it possible
to manage columns of information.
- Use of the named kill buffers and mark buffers don't require use of
any extension language; they can be used right in the normal
editing mode.
- Shell-in-buffer: you aren't limited to one (limit is currently 5).
- The spelling checker has a corrector option in which it will suggest
alternate spellings.
- No extension language; sorry, hackers. Personally, if I need LISP,
I write a LISP procedure; with C-E, there is less need for
such horsing around.
3. Documentation. The manual is extensive, but approachable. Also quite good
are the on-line tutorial, on-line help, in-command help, and INFO-type
documentation. The extent of the documentation is unusual even for a software
product of this genre. I use a relatively wide variety of commands, largely
without the use of the printed documentation (in favor of the on-line
information.) Worthy of note is the fact that C-E capabilities ARE documented;
ever find out that your editor could do some strange function all along
(while you spent a late evening creating a very imaginative extension
language procedure)?
4. Performance. We pay for connect time and cpu time on a VAX with daytime
loads of 25-35 logged-in users, so we pay attention to how things go in an
edit (where most of our time is spent). Eight C-E users typically show
a user load of less than 2.0, and it shows in general editor response
and resource charges. Even with a considerable system load, C-E has some
snap which makes it easier to concentrate on the real problems.
5. Product Considerations:
- Price is $850 per VAX system, which speaks for itself. The only
better deal I know of is the UNIX PL/I-G compiler due out this
summer (for about the same price).
- C-E doesn't use multiplexed files, and will be released for use
under 4.2BSD (as well as 4.1BSD). Note well, users of other
EMACS products!
- CCA is easy to contact and ready to sell now. The product is
delivered in source form, and maintenance will be via
source modification.
- C-E is compatible to a large degree with ITS EMACS, the PDP-10
and PDP-20 version of EMACS. Someone familiar with ITS can
sit down and begin using C-E right away.
- Since termcap is used, there is a good chance for support of
the usual mongrel collection of in-house terminals.
Now the inevitable question: what negative aspects of C-E or any EMACS haven't
been mentioned? In my opinion, the perfect editor will simply require you to
think of the code(*). In the meantime, find the most reasonable editing tool.
EMACS' truly negative aspect: you must use your fingers.
See? We avoided politics and religion!
Mike Krueger
Translation Systems, Inc.
138 Brighton Ave.
Allston, MA 02134
617-254-3482
* When that day arrives, we'll probably verify the suspicion that programmers
don't think about code.
Message-ID: <bnews.ucbvax.988>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Tue Mar 1 02:09:42 1983
Subject: CCA EMACS Notices
Posted: Sun Feb 27 21:34:48 1983
Received: Tue Mar 1 02:09:42 1983
>From GEOFF@SRI-CSL Sun Feb 27 21:31:31 1983
Received: by UCBVAX.ARPA (3.314/3.5)
id AA08010; 27 Feb 83 21:33:34 PST (Sun)
Mail-From: ARPANET host SANDIA rcvd at 6-Jan-83 1118-PST
To: info-vax@CCA-UNIX
Remailed-Date: 27 Feb 1983 0857-PST
Remailed-From: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-To: Info-VAX@SRI-CSL.ARPA: ;
To users of CCA EMACS:
The following two notices were inadvertently omitted from a number of
copies of CCA EMACS which were distributed. If you have a copy of CCA
EMACS without these notices, please add them to the README file and to
the tape containing CCA EMACS. Thank you.
Copyright 1982 by Computer Corporation of America as an unpublished
work. All rights reserved. In claiming any copyright protection which
may be applicable, CCA reserves and does not waive any other rights that
it may have with respect to this material. See notice of Proprietary
Rights.
PROPRIETARY RIGHTS. The CCA EMACS programs recorded on this tape or
disk or printed in this listing are the property of Computer Corporation
of America. Reproduction, copying, and/or disclosure to others of all
or any part of these programs in this or any form is prohibited except
pursuant to a written license agreement with CCA.
Joseph Jarzembowski, Counsel
Computer Corporation of America
Note: A message describing current availability of CCA EMACS will
shortly be sent to the newsgroup net.usoft by Steven Zimmerman. If you
do not receive this newsgroup, you can contact him directly at
decvax!cca!z, or through U.S. Mail at
Steven Zimmerman
Computer Corporation of America
Four Cambridge Center
Cambridge, MA 02139
Message-ID: <bnews.cca.4490>
Newsgroups: net.general,net.emacs
Path: utzoo!decvax!cca!z
X-Path: utzoo!decvax!cca!z
From: cca!z
Date: Fri Mar 25 08:30:32 1983
Subject: EMACS Survey
Posted: Thu Mar 24 09:01:31 1983
Received: Fri Mar 25 08:30:32 1983
I'm conducting a survey of EMACS usage on Unix machines. If your machine
has an EMACS or EMACS-like editor, please drop me a note letting me know
1. The name of the editor and its author
2. Which machines it runs on
3. Approximately how many people use it
If you don't know the answers to all of these questions, please tell me
what you do know. If you are using more than one EMACS-like editor,
please answer for all of them. I'll post a summary of the results to
net.emacs. Thank you.
Steve Zimmerman
decvax!cca!z
z@cca
Message-ID: <bnews.sri-arpa.712>
Newsgroups: net.emacs
Path: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!sri-unix!utah-gr!
thomas@utah-cs
X-Path: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!sri-unix!utah-gr!
thomas@utah-cs
From: thomas@utah-cs
Date: Wed Mar 30 01:31:39 1983
Subject: EMACS Survey
Posted: Fri Mar 25 16:49:10 1983
Received: Wed Mar 30 01:31:39 1983
We've got
1. Montgomery's emacs (called emacs)
2. Gosling's emacs (called gemacs)
3. CCA emacs (called zemacs) (But I'm not sure if it's the latest version
It may be the last "free" one.)
=Spencer
Message-ID: <bnews.cca.4599>
Newsgroups: net.emacs
Path: utzoo!decvax!cca!z
X-Path: utzoo!decvax!cca!z
From: cca!z
Date: Wed Apr 20 05:56:45 1983
Subject: CCA EMACS pricing
Posted: Sun Apr 17 10:14:20 1983
Received: Wed Apr 20 05:56:45 1983
Since the question has arisen, I thought I should clarify the pricing
policies for CCA EMACS.
The price for a single CPU license is $850; additional CPU's are $680
each. For machines designed to support four or fewer users, the price
is $475 for the first CPU and $380 for each additional CPU. Educational
institutions get a flat $350 rate for each CPU of any type. These are
full source licenses.
Although CCA EMACS doesn't yet have an extension language, the existing
keyboard macro library facility is quite powerful. For example, one of
users has used it to make his EMACS automatically come up looking just
like EDT. Nevertheless, there is no substitute for a full extension
language, and such a language is in the works. It will be a true small
Lisp, including such niceties as garbage collection. A large amount of
work has already been done on it, although not much since our marketing
department took over direction of EMACS a few months ago. They plan to
continue funding the extension language as soon as EMACS starts
generating revenue, which should be very soon as we are about to start
shipping out tapes. The priority that the extension language gets
depends on the demand that our marketing department perceives exists for
it. If you would be interested in buying CCA EMACS if it had an
extension language, please send me a message saying so. If I can
deliver a whole pile of such messages to our marketing department, I
assure you that they will become very interested in getting the
extension language finished and out the door soon.
We do not intend to raise the price of CCA EMACS once the extension
language is released. For existing CCA EMACS customers, it will be
available at the normal update charge of $300; this one charge will
cover all currently licensed CPU's.
As some people know, actual distribution of CCA EMACS has been held up
for several months by our legal department, who was taking all this time
drawing up the licenses. They finally finished the licenses on Friday,
and we have begun mailing them out. There's quite a backlog, so it may
take a couple of weeks to get forms to everyone who requested them.
However, the major bottleneck has been cleared, so tapes should be going
out soon to all who want them.
Steve Zimmerman
decvax!cca!z
z@cca
Message-ID: <bnews.cca.4699>
Newsgroups: net.emacs
Path: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!cca!z
X-Path: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!cca!z
From: cca!z
Date: Tue May 17 09:45:39 1983
Subject: New version of CCA EMACS
Posted: Wed May 11 12:04:10 1983
Received: Tue May 17 09:45:39 1983
Both the buffer management and display management routines of CCA EMACS
have been completely rewritten from scratch. The result of this effort
has been a significant increase in both the efficiency and capability of
the editor.
CCA EMACS has always had a reputation for being fast, and the algorithms
used in the buffer manager were a major reason for this. However, these
algorithms had the problem that their efficiency significantly decreased
once the size of the file being edited exceeded the internal buffer
size. In previous versions of CCA EMACS, the size of the internal
buffer was 512K, so this problem was rarely noticed. However, when
reading in large files of a megabyte or so, the problem became quite
obvious. The new buffer manager does not suffer this problem at all.
Using the same 512K internal buffer, the user CPU time required to read
in a 1.2 megabyte file was reduced by a factor of six. Even when the
size of the buffer was reduced down to 8K, the new routines were still a
factor of five faster than the old ones. For files less than the size
of the internal buffer, the speed of the old and new routines is
comparable.
One additional advantage of the new buffer routines over the old ones is
that the old limit of 1024 characters per line has been raised to 64K
characters per line. Since even binary files tend to have at least one
byte which looks like an ASCII linefeed every few thousand characters or
so, this effectively means that CCA EMACS can now be used to edit files
in arbitrary formats. This is very useful for editing EMACS keystroke
files; you can also use it for such things as editing the wizard's
password in the rogue object file.
The display manager was also rewritten from scratch, and I believe that
the algorithms that it uses are close to the optimum possible using a
termcap-based display. The new display manager uses all of the relevant
termcap fields, so that even really strange terminals should now work
correctly with CCA EMACS as long as their termcap description is
correct. Other terminals which used to work with EMACS are now
supported better than before; for example, scrolling regions are now
fully supported for VT100's. The cursor motion routines are much more
intelligent than before, and even use somewhat obscure features such as
absolute horizontal positioning, absolute vertical positioning, and
backtabs, when appropriate. However, the calculations required for
these optimizations are small, and their cost is miniscule in comparison
to the gain that results from them. The result is that measurements
have shown these routines to be more efficient than the cursor motion
routines of the vi which came with 4.1BSD, which is the most recent
version I have. (I have an old version of Gosling's EMACS, and although
my tests show a great difference in efficiency between the display
routines of CCA EMACS and my copy of Gosling's, this is probably not
conclusive since the copy I used is so old. I would be very interested
in running benchmarks against his current version, however.)
Another improvement in the display manager is that a complete
distinction is now made between buffer lines and screen lines. This
means that, unlike some other EMACSes, when you type C-V or M-V, you go
forwards or backwards exactly one screenful, regardless of whether there
are any intervening wrapped lines. This is especially useful for
editing files such as /etc/group, which at large sites may consist
mostly of lines wrapped many times. Carrying this distinction to its
logical conclusion, going forward a screenful may cause the new screen
to start in the middle of a wrapped line. This capability was
absolutely necessary in order to permit editing of binary files, where
single lines may extend for more than a screenful. Giving arguments to
C-V and M-V causes the display to shift the appropriate number of screen
(not buffer) lines. In general, the new scheme provides the user with a
much more flexible window into any part of the file.
One minor change that was made along the way was that the variables
Screen Height and Screen Width now refer to the size of the total
screen, instead of just the display area.
All orders for CCA EMACS which have been received up till now are being
filled with this new version.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!genrad!decvax!cca!z
From: z...@cca.UUCP
Newsgroups: net.general,net.unix-wizards,net.emacs
Subject: Important notice for EMACS users
Message-ID: <4874@cca.UUCP>
Date: Mon, 13-Jun-83 16:51:48 EDT
Article-I.D.: cca.4874
Posted: Mon Jun 13 16:51:48 1983
Date-Received: Tue, 14-Jun-83 04:29:24 EDT
Lines: 48
This notice is directed to all users of CCA EMACS, version 162.35z or
earlier, and users of Montgomery's EMACS (BTL EMACS).
Versions of CCA EMACS up to and including version 162.35z had contained
some portions of Warren Montgomery's EMACS version 4.0, which was
developed by Mr. Montgomery at Bell Laboratories. Beginning with CCA
EMACS version 162.36z, CCA EMACS no longer contained any of the code
from Mr. Montgomery's EMACS, or any methods or concepts which would be
known only by programmers familiar with BTL EMACS of any version. CCA
has not shipped any versions of CCA EMACS earlier than version 162.36z
since January, 1983.
On May 19, 1983 CCA was informed that Bell Laboratories considers BTL's
EMACS version 4.0, developed by Mr. Montgomery, to be Bell Laboratories
proprietary information. They have asked us to notify those persons to
whom we may have distributed Mr. Montgomery's EMACS, or parts thereof,
that Bell Laboratories considers that software to be proprietary and
that its use must be discontinued and all copies in the possession of
these people must be destroyed immediately.
Although CCA no longer uses any of the code asserted by Bell
Laboratories to be proprietary information, we realize that these
assertions by Bell Laboratories may cause some inconvenience.
Therefore, we would like to make the following offer: If you are using
a version of CCA EMACS earlier than 162.36z, we will replace it with a
version of the current CCA EMACS which has been configured to have the
same capabilities as your present EMACS, but which contains none of Mr.
Montgomery's code. There will be no charge for this replacement. All
that we ask is that you sign the standard CCA EMACS license agreement
and send us a tape containing the version of CCA EMACS that you are now
using; we will return the tape with your replacement EMACS.
Although the replacement EMACSes we will be sending out will have
basically the same capabilities as the ones they are replacing, they
will actually be an improvement, since the new routines are superior to
the ones they replace. However, the replacement copies will not have
all the various features which have been added to CCA EMACS since the
originals were obtained. If users of these older versions would like to
take this opportunity to upgrade to the current version of CCA EMACS, we
will make this easier by making a one-time offer of $475 per CPU
license, in contrast to the normal $850 for the first CPU and $680 for
additional CPU's. There is no discount on the educational fee of $350
per CPU. Both the offer of a free replacement EMACS and the discount
price on the current EMACS are valid through August 15, 1983.
Steve Zimmerman
decvax!cca!z
{allegra,philabs}!linus!cca!z
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!cca!z
From: z@cca.UUCP (Steve Zimmerman)
Newsgroups: net.emacs
Subject: CCA EMACS extension language
Message-ID: <5317@cca.UUCP>
Date: Tue, 2-Aug-83 19:07:14 EDT
Article-I.D.: cca.5317
Posted: Tue Aug 2 19:07:14 1983
Date-Received: Wed, 3-Aug-83 04:13:35 EDT
Lines: 13
I am currently porting CCA EMACS to VMS, which should take another couple
of weeks. Once this is finished, I will be working full time on the
EMACS extension language. I would be very interested in knowing what
other people think this language should be like. At this point, I
know that it will be a small but complete Lisp; it will have garbage
collection, so it will be able to support functions like cons and eval.
Beyond this, the design is pretty much open. I would be interested in
opinions on all aspects of the design, from which Lisp functions should
be built in to which EMACS primitives should be supported. Though I
can't promise to take all the advice I receive, I will certainly give
careful consideration to all messages sent to me.
Steve Zimmerman
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!cca!z
From: z@cca.UUCP (Steve Zimmerman)
Newsgroups: net.emacs
Subject: Release of CCA EMACS Version 162.42z
Message-ID: <6302@cca.UUCP>
Date: Thu, 15-Dec-83 12:47:50 EST
Article-I.D.: cca.6302
Posted: Thu Dec 15 12:47:50 1983
Date-Received: Sat, 17-Dec-83 03:27:48 EST
Lines: 99
Version 162.42z of CCA EMACS has now been released. This version
contains several additional features since the last release; the
documentation for these features follows.
Ada Mode
Ada mode is useful for programs written in the Ada language. The
following commands are specific to Ada mode:
Tab Indent appropriately for the current line.
C-M-\ Indent a section of Ada code.
C-C C-A Adjust the case of the current line.
C-C - Unindent one tab stop.
One of the primary functions of Ada mode is to assist the programmer in
indenting Ada code properly. For this purpose, the function ^R Indent
for Ada is bound to Tab in Ada mode. A Tab given at the beginning of a
line will indent the line to be lined up with the previous line of code.
If the previous line of code begins with one of the Ada reserved words
which requires additional indentation, then Tab will indent one level
further. A Tab given anywhere else in the line will indent one
indentation level. The number of spaces in an indentation level is
specified by the variable Ada Indent; by default it is three. Since
Linefeed is always defined to be a Return followed by a Tab, typing
Linefeed at the end of a line of Ada code is a good way of automatically
indenting the next line. It is possible to unindent a level of Ada code
by using the command C-C - (^R Unindent for Ada); this command may be
given an argument in order to unindent multiple levels. If an entire
section of Ada code needs to be indented properly, this can be done with
the command C-M-\ (^R Indent Region).
The second primary function of Ada mode is to set Ada code automatically
to its proper case. By convention, Ada reserved words are used in lower
case and user variables are in upper case. In Ada mode, whenever a
Return or Linefeed is typed, all words in the current line are set
automatically to upper case, with the exception of reserved words,
string literals, and comments. When a line is modified, its case may be
readjusted in this fashion by using the command C-C C-A (Set Case for
Ada). Comments in Ada mode are defined to start with two dashes, and
the comment commands work accordingly. (*Note Comments: Comments.)
Files which end with the extension ".ada" automatically cause the buffer
to be set to Ada mode when they are read in; this can be changed by
modifying the value of the variable Ada Extension 1. If a second
extension is also used to denote Ada files, this string can be specified
in the variable Ada Extension 2.
----------
Line Buffering
When displaying large amounts of text, EMACS normally writes characters
to the screen in one kilobyte blocks, which is very efficient and uses a
minimum of machine resources. However, there are two drawbacks to this
approach. When a command that causes a large amount of redisplay is
typed, such as C-V (^R Next Screen), there is a short delay before text
begins to be refreshed on the screen. What is happening is that EMACS
is first filling up its one kilobyte buffer with text to be displayed,
and until this buffer is full nothing is sent to the screen. Also, once
redisplay is underway, EMACS cannot interrupt it to start redisplaying
something else until the current one kilobyte block has been completely
output. This is most noticeable on terminals running at low baud rates,
where typing C-V in the middle of a screen refresh usually does not take
effect until many lines later.
The variable Line Buffering exists to address these problems. When Line
Buffering is set, text is written to the screen after every line, rather
than after every one kilobyte block. Response to an initial C-V command
is immediate, and C-V commands that are given in the middle of screen
redisplay take effect within three or four lines at most. (This minimal
delay is due to operating system buffering, and is not easily overcome.)
When the variable Line Buffering is set to 1, it takes effect on
terminals running at 2400 baud or less; when it is set to 2, it takes
effect on all terminals.
There are unfortunately drawbacks to this method as well, which is why
it is not the default. On very heavily loaded systems, redisplaying a
page of text using line buffering may take up to 80% longer than
redisplaying using block buffering. On the other hand, on lightly
loaded systems line buffering may actually result in redisplay that is
faster than block buffering by up to 25%, with the increased speed being
due to the increased overlap between the EMACS user-level program and
system I/O. Because of these performance tradeoffs, users in different
environments will prefer different settings for this variable.
----------
There is now a new command Meta-Space (^R Just One Space), which deletes
all the whitespace around the cursor and replaces it with a single
space. This command is similar to typing M-\ (^R Delete Horizontal
Space) followed by a space, except that it is easier to type. Giving a
numeric argument to Meta-Space causes it to insert that many spaces
instead of just one. This command is an old favorite among many MIT
EMACS users.
The command M-X Create Local Variable now accepts a zero argument, which
is interpreted to mean that an existing local variable should be made
global once again. The current local value of the variable is replaced
with the global value.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!cca!z
From: z@cca.UUCP (Steve Zimmerman)
Newsgroups: net.emacs
Subject: CCA EMACS for Suns
Message-ID: <6733@cca.UUCP>
Date: Mon, 20-Feb-84 11:23:15 EST
Article-I.D.: cca.6733
Posted: Mon Feb 20 11:23:15 1984
Date-Received: Wed, 22-Feb-84 04:11:31 EST
Lines: 15
CCA EMACS is now available for the Sun Microsystems workstation. This
version of CCA EMACS is the same one that runs on the VAX, and has all
of the features of the VAX version. Additionally, it runs inside of
Sun windows. Tests have shown that CCA EMACS runs significantly faster
than any other screen editor available for the Sun, largely due to its
highly optimized use of the Sun's bitmapped display.
For further information, contact:
Steve Zimmerman
Computer Corporation of America
Four Cambridge Center
Cambridge, MA 02142
617-492-8860
decvax!cca!z
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!cca!z
From: z@cca.UUCP (Steve Zimmerman)
Newsgroups: net.emacs
Subject: Release of CCA EMACS 162.43z
Message-ID: <6908@cca.UUCP>
Date: Wed, 14-Mar-84 10:17:32 EST
Article-I.D.: cca.6908
Posted: Wed Mar 14 10:17:32 1984
Date-Received: Thu, 15-Mar-84 07:17:21 EST
Lines: 136
Version 162.43z of CCA EMACS has now been released. This version
contains the following new features:
File version numbers
As Unix has moved more into the arena of large operating systems, one
feature that has been noticeably lacking is automatic numbering of file
versions. In this scheme, when a new file is created with the same name
as an existing file, or when an existing file is modified, instead of
the existing file being replaced with the new file, a file is created
with the same name as the existing file but with a higher version
number. This feature is usually implemented directly in the operating
system. However, EMACS has now implemented this feature at the user
level as an extension of the currently existing backup file facility.
If the new variable File Versions is set to a positive number, EMACS
will keep that many numbered versions around as backup files. It does
so by appending a number directly after the tilde in the backup file
name; succeeding backups receive increasingly higher numbers. For easy
reference, the highest numbered backup file is always linked to a
standard backup file name that ends only in a tilde.
Associated with this new feature is a modification to the DIRED B
command, which places deletion marks in front of backup files. The B
command with no argument will now place deletion marks in front of all
backup versions of the current file, which is defined to be the file
named on the line where the cursor is located. If given an argument,
the B command will place deletion marks in front of all backup versions
of all files.
Buffer and file name completion
EMACS now supports full buffer and file name completion for all commands
that prompt for buffer or file names. This feature works essentially
the same as M-X command name completion, except that Space has no
special meaning. Typing an Escape while entering the buffer or file
name will cause EMACS to complete as much of the name is as unambiguous;
if EMACS is able to complete the whole name, it prints a dollar sign at
the end. If EMACS is unable to complete the name any more than it is
already typed in, it beeps. Typing a question mark at any point will
cause EMACS to list the possible valid completions for the name at this
point.
Automatic Buffer Names
When the Find File command is used, EMACS uses the last component of the
file name to create a name for the file's buffer. If the buffer already
exists and contains a different file, EMACS will ask the user what name
to use for the new buffer instead. If the new variable Automatic Buffer
Names is set, EMACS will not ask the user, but will instead create a new
buffer name by appending a unique number (starting with 2) to the last
component of the file name.
C Mode enhancements
The default size of an indentation level for C mode is eight spaces. Up
until now, the only way to change this was by modifying the size of a
tab stop. The disadvantage of this method was that the indentation
level still ended up being eight spaces when the file was printed out or
examined by a program other than EMACS.
The new variable C Indent has been introduced to solve this problem. C
Indent is by default eight spaces, but can be set to any number, and
represents the actual number of spaces in an indentation level. EMACS
will indent to the proper level by using the optimum combination of
spaces and tabs unless the variable Indent Using Tabs is zero, in which
case it will use all spaces.
When C Indent is set to its default value of eight, unindenting a level
is easy, as typing Delete will delete a tab stop and thereby unindent
exactly one level. When C Indent is anything else, unindenting a level
is no longer so easy. For example, if C Indent is four, the user ends
up either deleting four spaces, or deleting a tab and inserting four
spaces. For this reason, the command C-C - (^R Unindent for C) has been
introduced. C-C - will unindent exactly one indentation level, breaking
up tabs if necessary. If given an argument, C-C - will unindent that
many indentation levels.
Ada Mode
Up until now, the command Set Case for Ada always adjusted the case of
the current line. This command has now been modified to accept positive
or negative arguments, adjusting the case of that many lines forward or
backward.
Autoarg Mode
Autoarg mode means that you don't need to type C-U to specify a numeric
argument. Instead, you type just the digits. Digits followed by an
ordinary inserting character are themselves inserted, but digits
followed by an Escape or Control character serve as an argument to it
and are not inserted. A minus sign can also be part of an argument, but
only at the beginning. If you type a minus sign following some digits,
both the digits and the minus sign are inserted.
To use Autoarg Mode, set the variable Autoarg Mode nonzero.
Autoargument digits echo at the bottom of the screen; the first nondigit
causes them to be inserted or uses them as an argument. To insert some
digits and nothing else, you must follow them with a Space and then rub
it out. C-G cancels the digits, while Rubout inserts them all and then
rubs out the last.
Changing directories
If you like to have EMACS automatically set a buffer's default directory
to be that of the file that it contains when EMACS finds a file in
another window, you may want to set the variable Change to File's
Directory. This causes the C-X 4 F and C-C 4 F commands to execute the
command Find File in Directory to read the file into the buffer, instead
of using the default Find File command.
Character searches
EMACS now has two new search commands, ^R Character Search and ^R
Reverse Character Search, which are useful for searching forward or
backward for a single character. When these commands are executed, they
read a single character from the terminal and then immediately search
for that character. Their behavior is exactly the same as if you had
started an incremental search and then exited after typing the first
character. After invoking a character search, a C-A can be used to turn
the search into a string search, a C-R can be used to reverse the
direction of the search, a C-S can be used to search for the last
character searched for by one of these commands, and a C-Q can be used
to quote the next character. These two commands are not normally bound
to any keys; many people who use them like to bind them to C-S and C-R
and then use the C-A option of these commands to enter a full string
search when necessary.
----------------------
Elisp
Excellent progress is being made on the Elisp extension language for CCA
EMACS. The core of the interpreter is now operational, and the entire
extension language should be ready for release in a couple of months.
Elisp is a subset of Common Lisp, and will contain all the basic
functions of a true Lisp.