The EMACS editing environment.
As Oustervote in 2001 concluded that emacs [L1 ] remains the single most widely-used programming editor among Tcl practitioners, although all vi variants together appear to sum to a larger total.
[Where does one go to find Emacs? What about Emacs on MacOS or Windows?] Is there more than one program that is emacs?
Where to get Emacs:
MacOS and Windows:
Quite a bit of available elisp implements functionality useful to Tcl coders, including syntax highlighting, a first-class REPL with inferior-tcl,...
Just drop elisp specific items into the elisp page, mentioned above.
June 14, 2007 Bezoar - new emacs package to insert templated code interactively
Ok, I'm not really in tune with wiki writing style, so I'll just dump stuff here (davidw):
It is true, that some details of the standard tcl-mode of emacs (I'm talking about GNU emacs, don't know much about Xemacs) could profit of a little bit work by an elisp guru. For example, I'm not that happy with the standard highlight regexp's. I use instead Donal Fellows highlighting code from http://www.man.ac.uk/~zzcgudf/tcl/#fontlock . And there are other, mostly minor problems.
That said, the tcl-mode has some very nice features, that really ease your work, if you are an emacs addict, like me. Have you ever have debugged a tk application? It's very easy to start the whole script from inside emacs (with the tcl mode command tcl-send-buffer, by default bound to C-c M-a). Now you click through your GUI, filling in data here and there. Then you click, let's say, a button, and you have to realize, that there is an error in the command bound to that button. Tk's error message may give you the reason, what's going wrong or at least an idea what debugging 'puts' to insert, to get more insight. Normally, this means exit your application, edit the code, restart your application, click through the GUI again, fill in the necessary data here and there and then you reach the point of interest again.
Not so, if you have started your applicatiom from emacs tcl mode. Don't exit your application, after you have encountered the error. Just edit the according proc (and fill some debugging puts in it, if you feel the needs, you will see the output in a special emacs buffer) and send the changed proc with tcl-send-buffer (per default bound to C-c M-a) to the running interpreter. Now - without restarting the application and clicking through again - just retry the malicious GUI action that has triggered the error before and see the outcome. (Of course, this is only possible due to the dynamic nature of tcl, and is not special to the emacs tcl mode. Emacs tcl mode only makes it very easy to use this tcl feature.) de.
In comp.lang.tcl, Bob Techentin writes the following to someone asking how to write Tcl code in Emacs and get the emacs syntax helps, etc.:
Start emacs. Open a file (new or existing) with a .tcl extension, and you should get Tcl mode automatically. If you don't get Tcl mode (perhaps because your file does not have the .tcl extension), use the m-x-tcl-mode command. One emacs trick to exploit is to put the magic code "-*-Tcl-*-" into one of the first lines of the file, so it always is recognized as Tcl source code. Start with a couple of lines like:
#! /bin/sh # this is a -*-Tcl-*- file
Once you've got emacs running in Tcl mode, just type. Use file-save (or ctr-x-ctrl-s) to write the buffer to a file. Then it should run fine. If your Tcl code is a web page, then you would probably click "refresh".
A page describing how to use Tcl to glue Emacs and Microsoft Outlook together somewhat:- tcom Allows Emacs as Editor for MS Outlook
PT 8-Jul-2003: I usually use FSF Emacs under windows - but I've recently had another go with XEmacs. XEmacs 21.4 supports windows (at least Win2K) very nicely. If also has a dde capability so you can hook into it from other programs. See the winclient.exe in the binary directory. If you create a shortcut to winclient in your SendTo folder, then you can 'send' files to XEmacs and have them open in the current session. (Similar to using gnuclientw with FSF Emacs). From Tcl you can do:
package require dde
proc edit {file} {
set name [file normalize $file]
set cmd "\[PrivoxyWindowOpen(\"$name\")\]"
dde execute XEmacs System $cmd
}Note that dde services {} {}' doesn't list the XEmacs service. This is because XEmacs chooses not to respond to non-specific DDE requests. dde services XEmacs System'' does list the service. This is not a dde package bug.
2003-12-21 VI See JH's Tcl Elisp Macros
WJP One of the nice features of emacs is that it will automatically time-stamp files for you whenever you save them. It can be handy to have access to this time stamp from within a Tcl program. For example, I like to display the time-stamp along with the version number when I am debugging because all too often I end up with two or more invocations of a program running, all with the same version number, and have difficulty figuring out which one is the version that I most recently modified. If the time-stamp written by emacs could be turned into a Tcl variable, the information would be readily accessible.
Unfortunately, the default format used by emacs does not allow this. The default emacs time-stamp looks like this:
Time-stamp: <2005-11-24 19:01:31 poser>
Emacs will accept quotes instead around the second part, so we can easily enough make it into a Tcl string, so we might try this:
set Time-stamp: "2005-11-24 19:01:31 poser"
but if we reference it the usual way we run into a problem:
puts $Time-stamp: # => can't read "Time": no such variable
The problem is that Time-stamp: will not by default be parsed by Tcl as a single word so it isn't convenient for a Tcl variable name. Rather than have to remember to use special measures such as putting the variable name within braces, we can get emacs to use a different string to identify the time-stamp. We can do that by redefining the emacs variable "time-stamp-start". The first line of the following Tcl file header changes the time-stamp identifier to "TimeStamp", allowing us to use it as a Tcl identifier.
#-*- mode: Tcl;time-stamp-start:"TimeStamp[ ]+\\\\?[\"<]+";-*- set TimeStamp "2005-11-24 18:53:03 poser"
If your program is set up to invoke Tcl as a Unix shell file, do it like this:
#!/bin/sh #-*- mode: Tcl;time-stamp-start:"TimeStamp[ ]+\\\\?[\"<]+";-*- # the next line restarts using wish \ exec wish $0 -- $@ set TimeStamp "2005-11-24 18:53:03 poser"
Note that the time-stamp must be one of the first eight lines of the file in order for emacs to find it.
escargo 28 Nov 2005 - In what way is "Time-stamp:" not a legal value for a Tcl identifier? Try this:
proc Time-stamp: {stamp} {
puts $stamp
}WJP 29 Nov 2005 - Well, to be precise its an identifier that isn't readily usable as a variable name. Try executing my first example line. I use tclsh to exemplify:
% set Time-stamp: "2005-11-24 19:01:31 poser" 2005-11-24 19:01:31 poser
Okay so far. But now try to reference the value:
% puts $Time-stamp: can't read "Time": no such variable
You can, of course, do:
% puts ${Time-stamp:}
2005-11-24 19:01:31 poserbut it is a pain to have to remember to do this. Either you have to remember to use special devices to reference the variable or you change the name that emacs uses and thereafter don't have to worry about it. I've revised the above text to be clearer.
LES You are nitpicking (and losing more hair) over nothing. If you use Tcl a little more often, you soon get used to applying braces. Because the name, with a hyphen, obviously requires it. Also, you can always use puts [set Time-stamp]. Actually, escargo's suggestion is probably the best one. That way of using Tcl's procs is very convenient and powerful. Why not use it?
WJP People will differ as to what they find convenient and natural, but I don't find it at all convenient or natural to have to use special syntax to make a variable name usable, even though I know perfectly well how to do it. By the same token, very few programmers in my experience make use of variable names that require special handling in the language they are using other than in special situations in which, e.g., they are encoding information from multiple sources in a single variable name. Ditto file names. That's why you'll find that Unix programmers rarely use file names containing whitespace, whereas MS Windows programmers do it frequently. Any experienced Unix programmer knows how to handle such things, but it's easier to avoid it. As for escargo's proc, I took it to be an illustration of the fact that Time-stamp: is a legal identifier. How would using it help? Remember, the point of the exercise is to construct a line that is, on the one hand, recognized by emacs as conforming to its time stamp format and that is, on the other hand, a valid Tcl statement that records the time stamp so that the information is available later in the program. How does this procedure help to do this with the unmodified emacs time stamp prefix?
LES: How about this:
% proc Time-stamp: {} {puts -nonewline [set ::Time-stamp]}
% puts [Time-stamp:]
2005-11-24 19:01:31 poserAlmost the same as ${Time-stamp:}, but well, you'll have to live with it.
For some emacs features emulated for text widgets, see