MEdit - Programmable Text Editor

---

Programming

This page briefly describes some of the issues you should be aware of when writing your own profiles.

First of all, MEdit has three layers:

1. the construction layer (file medit.tcl) - manages windows on the screen
2. the metaprofile layer (file metaprofile.tcl) - allows to create and edit commands, save profiles, etc., it also manages the menu that is bound to right-click on the command list
3. the profile (files in the profiles directory)

Everything that is defined by the first two layers is placed in the medit namespace.
The important names are:

• medit::allbuffernames - (variable) the list of names of existing buffers
• medit::currentbuffername - (variable) the name of buffer that is currently edited
• medit::t - (variable) the name of current text widget
• medit::s - (variable) the name of current status label
• .aux - the name of auxiliary text widget
• medit::getGoodName - (procedure) returns the unique name of buffer based on the proposed name (use this before opening new buffer)
• medit::createNewBuffer - (procedure) creates new buffer with the given name (must be unique)
• medit::renameBuffer - (procedure)
• medit::focusOnBuffer - (procedure)
• medit::destroyBuffer - (procedure)
• medit::showAuxiliaryWindow - (procedure) shows or hides the auxiliary window (text with scroll)
• medit::currentencoding - (variable) name of currently selected encoding (use it when reading/writing files)
• medit::invokeCommand - (procedure) invokes the command (either text or script) with the given name or the currently selected one (use when you want one command call the other)

Every profile has to define the following:

• New file - a command that is supposed to create new buffer (even the empty profile has this command, look how it implements it)
• insertText - a procedure (defined in the oninit script) that is supposed to insert text into the currently edited buffer
• openFileFromPath - a procedure (in oninit) that is supposed to open new buffer and load a given file into it

Of course, what these commands and procedures really do is up to you as a programmer, but they have to exist.

Note:
Be very careful when editing the oninit script. It should contain for example procedure definitions for use by other commands. In more serious profiles, the oninit script can be quite big.
When you mess something up so that it cannot be properly executed as a Tcl script, the profile will not load.
Then - only hacking the profile by hand (profiles are text files) can help.

The last thing that you may be interested in is the format of profile files.
Normally you do not need to peek inside, but in rare cases when you mess up the oninit script, you may need to edit the profile by hand (for example, using MEdit with a good and stable profile).

The profile file consists of sections, one for each command in the list.
Every section contains (every piece goes in separate line):

• command name
• command type ("separator", "text" or "tcl")
• the last cursor position (in the form line.char)
• number of lines in the body
• body

Separators have only the first two pieces.
The important thing is the number of lines - keep it in mind when editing the body.
The oninit and onclose scripts are stored as "tcl" commands, with dummy names, but with special types.