wenshenk@mas1.UUCP (Shen Kao) (02/12/91)
I have a minor problem with the emacs editor, maybe someone can give me some advices. When I spawn a shell within emacs editor by issuing "shell" command, the emacs prompts "incomplete termcap entry, editing disabled". I have not modified the termcap file, and I am runnging the emacs within the vt100 emulation process. Both are provided by the NeXT computer. My system is the exact configuration as the original configuration delivered from the NeXT Computer. I have tried various termcap setup without success. I will appreciate any help. Thanks.
ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) (02/12/91)
In article <2341@mas1.UUCP> wenshenk@mas1.UUCP (Wen-Shen Kao) writes: > I have a minor problem with the emacs editor, maybe someone can give >me some advices. When I spawn a shell within emacs editor by issuing "shell" >command, the emacs prompts "incomplete termcap entry, editing disabled". Ignore this, it's not a problem. It won't hurt emacs at all. The NeXT machine doesn't have an ordinary CSH, it has CMU's modified CSH with command line editing and other nifty features. In order for those features to work, csh needs to know what terminal type you have. The csh that's running *under* *emacs* isn't running in a VT100 or under any other sort of terminal emulator -- emacs provides a dumb terminal environment for it. Because of this, the csh is notifying you that you can't use features like command line editing -- which you don't need because the shell is in an emacs buffer anyway. -- Doug DeJulio ddj@zardoz.club.cc.cmu.edu (NeXT) dd26+@andrew.cmu.edu (AMS/ATK)
barry@pico.math.ucla.edu (Barry Merriman) (02/12/91)
In article <11903@pt.cs.cmu.edu> ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) writes: >NeXT machine doesn't have an ordinary CSH, it has CMU's modified CSH >with command line editing and other nifty features. Where did you learn about this? (man csh?) Does it do all the things tcsh does? (filename and command completion, spelling correction, editing history list with emacs-style commands, etc). Tell me more! -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet)
charlie@cville.umd.edu (Charles William Fletcher) (02/13/91)
In article <11903@pt.cs.cmu.edu> ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) writes: >In article <2341@mas1.UUCP> wenshenk@mas1.UUCP (Wen-Shen Kao) writes: >> I have a minor problem with the emacs editor, maybe someone can give >>me some advices. When I spawn a shell within emacs editor by issuing "shell" >>command, the emacs prompts "incomplete termcap entry, editing disabled". > >Ignore this, it's not a problem. It won't hurt emacs at all. The >NeXT machine doesn't have an ordinary CSH, it has CMU's modified CSH >with command line editing and other nifty features. In order for >those features to work, csh needs to know what terminal type you have. >The csh that's running *under* *emacs* isn't running in a VT100 or >under any other sort of terminal emulator -- emacs provides a dumb >terminal environment for it. Because of this, the csh is notifying >you that you can't use features like command line editing -- which you >don't need because the shell is in an emacs buffer anyway. >-- >Doug DeJulio >ddj@zardoz.club.cc.cmu.edu (NeXT) >dd26+@andrew.cmu.edu (AMS/ATK) This brings in another related problem. Say you spawn the shell (and get the termcap problem); and (say) you compile a TeX file with an error. By typing an 'e' at this point (and assuming the proper shell set up), you are then inserted into emacs at the line where the error occured. Under the emacs shell, this won't work due to he improper termcap file. In reality, I don't want it to work, since it would mean having a *new* emacs spawn and cause the file to be edited in two separate processes. *What I would like* is to be placed back in the *existing* emacs buffer at the correct line (where the error exists.) Is this possible? Any emacs gurus out there or should I post this to comp.sys.emacs?? I assume the same type of behavior occurs when compiling C code, but I haven't done that yet. Thanks,
melling@cs.psu.edu (Michael D Mellinger) (02/13/91)
In article <1073@kaos.MATH.UCLA.EDU> barry@pico.math.ucla.edu (Barry Merriman) writes:
Where did you learn about this? (man csh?) Does it do all
the things tcsh does? (filename and command completion, spelling
correction, editing history list with emacs-style commands, etc).
Tell me more!
It's in the manual somewhere. Anyway, it isn't very comprehensive, so
I still use tcsh. I would like to switch to BASH if release 1.07 is
usable.
-Mikejacob@gore.com (Jacob Gore) (02/13/91)
/ comp.sys.next / charlie@cville.umd.edu (Charles William Fletcher) / Feb 12 / > Say you spawn the shell > (and get the termcap problem); You don't get the termcap problem with 'bash', a shell written by the same organization that wrote this version of Emacs... > and (say) you compile a TeX file > with an error. By typing an 'e' at this point (and assuming the > proper shell set up), you are then inserted into emacs at the line > where the error occured. Emacs running within an Emacs shell buffer? That'd be cute :-) > In reality, I don't want it to work Good :-) (It can be done, though, using terminal mode instead of shell mode.) > *What I would like* is to be placed > back in the *existing* emacs buffer at the correct line (where the > error exists.) Certainly. There is a program called 'emacsclient' in /usr/lib/emacs/etc that was written for just this kind of stuff. It connects with a server function in Emacs. To tell tex to use emacsclient, set the environment variable TEXEDIT to "/usr/lib/emacs/etc/emacsclient +%d %s". To tell Emacs to start the server for emacsclient, put "(server-start)" into your .emacs file. > I assume the same type of behavior occurs > when compiling C code, but I haven't done that yet. Actually, the common way to compile C code is with "M-x compile" in C mode, then use M-` to step through the errors. TeX mode has similar commands: C-c C-b TeX-buffer C-c C-r TeX-region Do "C-h m" in TeX (or LaTeX) mode. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
cpenrose@sdcc13.ucsd.edu (Christopher Penrose) (02/14/91)
In article <11903@pt.cs.cmu.edu> ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) writes: >Ignore this, it's not a problem. It won't hurt emacs at all. The >NeXT machine doesn't have an ordinary CSH, it has CMU's modified CSH >with command line editing and other nifty features. Where are these features documented? standard csh editting commands (:p et al) do not work normally with NeXT's csh. I am interested in these features. Does CMU have documentation? Christopher Penrose jesus!penrose@esosun.css.gov cpenrose@ucsd.edu
datran2 (02/15/91)
In article <1073@kaos.MATH.UCLA.EDU> barry@pico.math.ucla.edu (Barry Merriman) writes: >In article <11903@pt.cs.cmu.edu> ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) writes: > >>NeXT machine doesn't have an ordinary CSH, it has CMU's modified CSH >>with command line editing and other nifty features. > >Where did you learn about this? (man csh?) Does it do all >the things tcsh does? (filename and command completion, spelling >correction, editing history list with emacs-style commands, etc). > Its really pretty simple, but the documentation is obscure. You can read about it at the end of man csh. The trick is to have a file on your home directory called ".bindings" that has the shell editing keys defined. When you start a csh and it sees this file, the emacs style command line editing and history become enabled. Absolutely critical as far as I'm concerned. Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # "Badgers, we don't have no stinking badgers" # # datran2!smb@csn.org # -from Treasure of the Sierra Madre Zoo # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
dml@esl.com (Denis Lynch) (02/20/91)
Several people lately have complained of not being able to find the
documentation on NeXT's nice csh editing features. It sure isn't
easy to find, but the description is in the csh man page.
Just for the record, here's the contents of my .bindings file:
bind-to-key EraseWord \\e\\^?
bind-to-key FilenameExpansion "\^I"
This make Esc-Delete (and Alt-Delete in Terminal) like M-Del in Emacs,
and makes the tab key do filename completion, like in Emacs. (My brain has
trouble using tab for completion sometimes and escape other times.)
Here's the relevant part of the 2.0 csh page, which is the same as the
1.0 page in this section. One caveat: csh's "binding" mechanism just aint
emacs. In particular, csh can only deal with one-character prefixes.
That means that your standard arrow key sequences (ESC-0-A, for example)
can't be bound to csh editing functions. Too bad.
EXTENDED C-SHELL FEATURES
The version of the C-shell supplied on the NeXT computer
includes several entensions, such as intra-command line
editing, a kill buffer, multi-line named keyboard macros
which can be automatically saved and restored, convenient
access to the history list, and user settable key bindings.
A summary of the currently available functions and their
default key bindings is given in the BINDINGS section below.
In most cases the functionality will be apparent from the
names of the routines in the list.
The shell's editing mode is determined by the value of the
shell editmode variable which users should set to emacs in
their .cshrc files If editmode is not set, then the shell
will run in "dumb" mode. It is possible to set the mode
after the shell starts up; so if you find yourself in "dumb"
mode, you can alter the situation without having to log out
and log in again. Setting the editmode variable has two
important side effects: (1) it causes the key bindings to
be reevaluated, and (2) it sets the EDITMODE environment
variable. The latter has no effect within the shell; so
users should not set the environment variable directly in
hopes of altering the editing mode.
Terminal control capabilities are extracted from the user's
termcap file (usually /etc/termcap), using the value of the
shell variable term -- not the environment variable TERM --
as the terminal type. If term is undefined, unknown, or if
the associated termcap definition is inadequate, a warning
will be displayed and most, or all, of the editing features
of the shell will be disabled. It is the user's responsi-
bility to make sure that term is set to an appropriate value
before the editmode variable is set to emacs. Usually this
should be done in the .cshrc file. If editing is disabled
because term is not properly set when the shell starts up,
simply setting term to the proper value will normally cause
the shell editor to be re-enabled. NB: Setting the shell
variable term causes the environment variable TERM to be set
to the same value. For information on controlling the bell,
see the DIAGNOSTICS section.
There is a new command in this shell, bind-to-key, which
allows the functions listed in the BINDINGS section below,
and also user defined keyboard macros, to be bound to keys.
The form of the command is
bind-to-key function key ...
where function is one of the function names from the list or
else the single character name of a keyboard macro and where
key is a quoted string designating a key sequence. Control
characters in the key designation should not be entered
literally, but should be indicated by the prefix "\^", e.g.
"\^X". Similarly, escape is indicated by "\e". A literal
slash is "\\". Escape and control-X are the only legitimate
"prefix" characters. The following mnemonics should be
used: "\t" for tab, "\^?" for rubout, "\n" for newline, and
"\r" for return. Since the shell converts returns to new-
lines it is probably unwise to alter the binding of newline.
During editor initialization the shell will read a file
named .bindings in the user's home directory. If you regu-
larly want certain non-default key bindings to be effective,
put the appropriate bind-to-key commands in your ~/.bindings
file. NB: The bind-to-key commands would work if placed in
your ~/.cshrc file, but they will be more useful (in the
future) if they are in the ~/.bindings file.
Invocation of the history mechanism with "!" either causes
the matched command to be inserted on the command line for
editing before execution or immediatedly executes the com-
mand. This is controlled by the shell variable edithist,
which is automatically set, when the shell variable editmode
is set, thereby allowing editing of previous commands
invoked by the history mechanism. This feature may be
turned off with the command "unset edithist", which may be
placed in the user's .cshrc file.
HOW TO ENABLE THE EXTENDED C-SHELL FEATURES
To enable the extended C-Shell features, put the line:
set editmode = emacs
in the .cshrc file in your home directory. If you don't
have such a file, create one and add the line to the end.
Log out and log in again and you will be using the new
shell.
BINDINGS
The following functions and default key bindings are
currently implemented.
Emacs Function Name Remark
^B Backspace
ESC-b BackwardWord
^A BeginningOfLine
^L ClearScreen
DefaultBinding
ESC-n DefineNamedMacro name macro
^D DeleteCurrentChar
^H DeletePreviousChar
ESC-d DeleteWord after cursor
EndOfFile exit shell
^E EndOfLine
EraseLine kills whole line
ESC-h EraseWord before cursor
ESC-e ExecuteNamedMacro
ESC-x ExecuteNamedMacro
^X-e ExecuteUnNamedMacro
ESC-ESC FilenameExpansion
ESC-l FilenameList
^F ForwardChar
ESC-f ForwardWord
^W KillRegion to kill buffer
^K KillToEOL to kill buffer
IncrementalSearchForward
IncrementalSearchReverse
InsertChar self insert
^V InsertLiteralChar
^X^R LoadMacroFile
^N NextHistEntry wraps around
^P PreviousHistEntry wraps around
^R Redisplay redraws line
^U Repetition greater than 0
^M,^J Return
^X^S SaveMacroFile
^@ SetMark default mark at BOL
SearchReverse look for next char
SearchForward look for next char
^Q StartFlow (see FLOW CONTROL)
^X-( StartRemembering begin a macro
^S StopFlow (see FLOW CONTROL)
^X-) StopRemembering end a macro
^I Tab inserts 8 spaces
^T TransposeChars before cursor
^Y YankKillBuffer no kill ring
Users may change the bindings of functions to keys by means
of the shell bind-to-key command. These commands may be
stored in a file named .bindings in the users home directory
and will then be read by the shell when the editor is ini-
tialized.
NB: The shell variable bindings is no longer being sup-
ported and will become ineffective in a future release.
Before that happens users should convert to using the
~/.bindings file.dml@esl.com (Denis Lynch) (02/21/91)
One more little note for anybody about to experience the joys of emacs-in-csh: If you are used to emacs, you are probably used to Control-t: transpose characters. The csh editing has this too, but it's different! In emacs, C-t transposes the characters before & after dot; in csh it transposes the two characters before the cursor position! Just enough different to totally confuse almost anybody. (Also, the emacs version advances dot by one, and the csh versions doesn't.) --Denis
hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) (02/22/91)
In article <DML.91Feb20145743@acoustat.esl.com> dml@esl.com (Denis Lynch) writes:
<> If you are used to emacs, you are probably used to Control-t: transpose
<> characters. The csh editing has this too, but it's different! In emacs,
<> C-t transposes the characters before & after dot; in csh it transposes
<> the two characters before the cursor position! Just enough different to
<> totally confuse almost anybody. (Also, the emacs version advances dot by
<> one, and the csh versions doesn't.)
I don't have a NeXT yet (it's my next machine, though);
the behavior you describe is also typical of ksh.
If you want a genuine C-t transpose, you may need to use tcsh
where it works (that's why I gave up on ksh and Ctrl-t-ed to tcsh!)
Hardy Mayer
----****----
Professor Meinhard E. Mayer
Department of Physics
University of California
Irvine, CA, 92717
USAjacob@gore.com (Jacob Gore) (02/22/91)
/ comp.sys.next / dml@esl.com (Denis Lynch) / Feb 20, 1991 / > If you are used to emacs, you are probably used to Control-t: transpose > characters. The csh editing has this too, but it's different! > [...] Just enough different to Look folks, if you want to your shell to behave just like GNU Emacs, why not just use the shell designed with that in mind: the GNU shell? Pick up bash-1.05 from prep.ai.mit.edu (with a patch in the same directory), apply to it the NeXT-specific patch in the NeXT-specific archives, and you're all set! Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
eps@toaster.SFSU.EDU (Eric P. Scott) (02/22/91)
In article <DML.91Feb20145743@acoustat.esl.com> dml@esl.com (Denis Lynch) writes: > In emacs, >C-t transposes the characters before & after dot; in csh it transposes >the two characters before the cursor position! Just enough different to >totally confuse almost anybody. (Also, the emacs version advances dot by >one, and the csh versions doesn't.) Emacs is smarter than that: C-t transposes the characters around point and advances _unless_ it's at the end of a line. In that case, it transposes the two characters before point, and doesn't move. So csh acts like it's at the end of a line, even when it isn't. -=EPS=-
ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) (02/24/91)
In article <DML.91Feb20145743@acoustat.esl.com> dml@esl.com (Denis Lynch) writes: >If you are used to emacs, you are probably used to Control-t: transpose >characters. The csh editing has this too, but it's different! Yeup, the cmucsh transpose-characters functionality is modled after gosmacs, if memory serves. Some people here use a version of csh that has two transpose character functions, "TransposeChars" and "GnuTransposeChars", so you can get whichever behavior you want. The last time I tried to bind GnuTransposeChars to ^T on a NeXT it didn't work though. Perhaps they should pick up this new feature? -- DdJ