The acronym resolves to Smart Editing Environment, it was coined by Jean-Claude Wippler as an alternative to the all-present IDE.
In my (AK) vision the SEE is not a monolithic application containing everything which is required to edit, browse, add, delete in packages, scripts, files, etc., but a set of applications each doing some simple task, talking to each other, maybe by using the kernel builtin send, or by some other means (sockets for example). And for the cases some monolithism cannot be avoided I propose to use a plugin structure, i.e. an application with a well-defined interface for loading additional functionality into it.At the center I have two core applications:
- A browser for archives, able to list and search the extensions (and libraries) in an archive. It should make no distinction between a local archive (the installed extension), and a remote one (part of the net of all archives ETEN). Functionality beyond the described is added via a plugin-system.
- A browser for extension and libraries, which are either in an archive or outside (f.e. during development). It has no basic functionality, just a plugin-system to add some.
- Test suite management. A plugin is able to detect the presence of a test suite and provides functionality enabling the browser to display its contents. It additionally provides an interface for external editor applications wishing to manipulate the test suite. Such applications may range from simple editors for a single testcase to editors which are part of a code editor (procedures, classes) for example, with extended functionality (testcase <-> code association, ...). As long as they speak the defined interface it should not matter. I made a minimal prototype of a GUI to a test suite evaluator/executor. (Add url here).
- Management of help texts and documentation. See Bryan Oakley and his thread about a text dump format. (Note: Find dejanews thread url, insert here).
- Utilities helping in compilation, configuration and installation of extensions. For example a bras-file editor (Note: Paul Duffin, Jean-Claude Wippler, WOBBLE).
- Code browsers/editors. May abstract away from files and concentrate on the logical structure of classes, methods and procedures, plus higher level aggregrates (function groups, ...), which are then automatically mapped to files. Discussion of possible mapping policies required (single file for all, one file per proc, some sort of dependency analysis, user groups procedures/classes into related sets => hints for mapping), as is discussion about useability of such a scheme.
- Other possibilities include:
Documentation as part of code/procedures, at least from the view of the editor.
Automatic linkage to help editor/test editor. Or integrated into the code editor.
Generation of make/bras files from the code/files in the package. See -> automake/autoconf.
Generation of package index files.The concept of the plugins for the extension browser can be extended further, by so-called "smart" extensions. They may contain special plugins which are able to supersede and/or enhance existing plugins or temporarily install new, extension-specific plugins. This way it is possible to handle even very special and/or unusual situations.An example is "Makedist" [1] and its extension specific control file, "PREPARE".Note: Makedist is basically the "setup.py dist" from the Python DistUtils-SIG, "creation of a source distribution".Here is a picture showing some relationships between possible components 
.I have much more text lying around, but it is not organized yet, and therefore not included here, for now.-- AK
Hmmm... I was looking for "see" as a command, not an acronym. But http://wiki.tcl.tk/see*
insists on showing me the seek command.LV Traditionally, these minor commands have been documented either as a part of the major command (such as entry, button, etc.) or as a combination of the major and minor command (perhaps like "button see" , etc.).But I can envision cases where documentation of general features of a minor command that were consistent across all widgets might be worth documenting together.
See can also be a Tk widget command. It adjusts the view of a text widget to a certain position. For example, you load a text widget and want it to cut right through the entire content and show you the last line:
$toplevel.text_widget see "end - 1 char"... or you may want to have the cursor automatically positioned at the 5th line. But that makes the widget display from the 5th line on only, hiding the 4 first lines, and you want to see them all:
tk::TextSetCursor $toplevel.text_widget 5.0
$toplevel.text_widget see 1.0The first line positions the cursor at 5.0. The second line makes you "see" from the first line on.RS 2007-01-22: Here's an appromixation for the same on a canvas widget: it moves the view so that the top left corner of the given tag or id is visible
proc canvas'see {w tagorId} {
foreach {x0 y0 x1 y1} [$w bbox $tagorId] break
$w config -scrollregion [$w bbox all]
foreach {sx0 sy0 sx1 sy1} [$w cget -scrollregion] break
$w xview moveto [expr {$x0*1.0/($sx1-$sx0)}]
$w yview moveto [expr {$y0*1.0/($sy1-$sy0)}]
}Look also at xotclIDE that implements many of written requirements (repository browser, code browser, documentation tool, deployment tool (also for Tclkit), configuration browser, syntax checker and debugger).
