Bug Watch September 2004

AutoCAD’s Editing Idiosyncrasies Have Text Playing Hide and Seek

The MTEXTED system variable was introduced in AutoCAD Release 13 to control which editor is used when editing mtext. You can enter it at the Command prompt or use Options / Files / Text Editor, Dictionary, and Font File Names / Text Editor Application. By default, MTEXTED is set to Internal, which means you're using the standard internal mtext editor. The current AutoCAD documentation indicates that you can specify an external executable file such as Notepad for your editor. It also mentions, in a slightly misleading and half-baked way, that you can use a setting of ":lisped" if you want to use a LISP editor.

However, this is only a small portion of the full story. This feature was fully documented in Release 13, and also in Release 14's Readme file. After that, Autodesk decided you didn't need to know the full story and chopped a lot of useful information out of the documentation. Release 14's Readme file mentioned that Autodesk might discontinue mtext support for an AutoLISP function name in the future. Fortunately, nobody at Autodesk has yet removed this useful feature of MTEXTED, which still works as well as ever. In fact, from AutoCAD 2000i onward, it has worked better than before, which is good because MTEXTED also affects what happens when you double-click on mtext.

Here is the full MTEXTED syntax:

:<lisp function name>#<editor name>

The bit after the colon (:) is the name of any AutoLISP function you want to use for editing the text. It must accept a single-string argument and return either a string that represents the edited text, an integer 0 to cancel, or an integer -1 to use the secondary editor. The secondary editor is whatever comes after the hash/pound (#) symbol. For example, set MTEXTED to this:

:lisped#Internal

This tells AutoCAD to use a simple one-line editor. If the mtext is more than 80 characters or you pick the Full Editor button, the normal internal editor is used instead. If you don't specify a secondary editor, AutoCAD defaults to Notepad.

Why would you want to do this? In a word, control. Mtext supports a large number of formatting codes and character sequences, some of which are not supported by the various incarnations of the internal mtext editor that have appeared over the years. In some cases, the internal editor actually gets things wrong with these funny codes. Using a plain-text editor lets you see and control the codes, and, in some cases, correct AutoCAD's mistakes. For reasons of either legibility or simplicity, some people prefer a single-line editor for most of their text editing jobs and call on the full editor only when they need it. Many people have been doing this happily and efficiently for a decade. Here's hoping that nobody at Autodesk ever does get around to removing this useful tool.

A Fine Mess (Minor Bug in R13 to 2002, Major Bug in 2004/5)
To see this bug, first set MTEXTED to ":lisped#Internal," as described above. Invoke the Mtext command to create some mtext and follow the usual prompts. When you get to the single-line LISP editor, enter the following:

ANOTHER\PFINE MESS

The \P code is just a paragraph marker to put "FINE MESS" on the next line, equivalent to pressing Enter in the internal editor. Pick OK and the mtext appears. Now edit the mtext -- that is, invoke the Ddedit command -- erase the P, and pick OK. The FINE MESS text vanishes from the mtext object! Pick the object again and see that it contains the following, as it did when you edited it:

ANOTHER\FINE MESS

This mischievous little vanishing trick occurs with all AutoCAD versions from Release 13 on. It's caused by the fact that \F is a font file code. For example, if you have some mtext that says "Hello World," you can use a plain-text mtext editor to force the word "World" to use the ROMAND.SHX font file, for example:

Hello {\Fromand.shx;World}
Hello {\Fromand;World}
Hello \Fromand;World

So far, so good. But what happens if the text after the \F does not represent a valid font file? For example:

Hello {\Fnot_here;World}
Hello \Fnot_here;World

Nothing bad happens here. AutoCAD just uses its default font if it can't find the one you specify, which is a very reasonable thing to do. Now let's see what happens if you get things slightly more wrong by omitting the semicolon, like this:

Hello \Fnot_here World

Pick OK and your World is gone! This is the same situation as our first vanishing "FINE MESS" text. You've been able to make half-vanished mtext like this since Release 13, but that was just a minor glitch. In AutoCAD 2004 and 2005, such mtext represents an unexploded bomb. AutoCAD locks up whenever you use the full mtext editor on it. To prove this, edit some half-vanished mtext and pick the Full Editor button in the LISP editor dialog box. An hourglass appears, AutoCAD freezes, and your CPU runs at or near 100%. All you can do now is use Task Manager to close down AutoCAD, losing any unsaved work in all your open drawings.

The mtext editor contains error trapping for other invalid mtext codes. In such cases, AutoCAD issues a warning and converts the code to inert text. The same should happen with \F codes, but it doesn't in any AutoCAD release. In Release 13 to AutoCAD 2002, using the full editor on such mtext causes the system to permanently remove the text from \F on as soon as you pick the OK button. That's not nice, but at least it's not fatal.

The lock-up happens with faulty \F codes in both normal mtext and dimension mtext. However, AutoCAD 2005's new table cell text suffers from only the vanishing text, not the lock-up. This behavior also applies to the \f code. I can't find it documented anywhere, but the \F code is for .SHX fonts and \f is for TrueType fonts.

Workaround. "Don't do that" is the obvious workaround, but AutoCAD shouldn't punish your slightly faulty editing efforts with a lock-up. If you use something other than the standard (lisped) function for your editor, that function could be written in such a way that it can deal with this situation. It could convert dangerous \F and \f codes without a matching semicolon to \\F and \\f. This prevents both the vanishing text and the lock-up problems. It also makes the codes visible in the drawing so you can readily identify and rectify them.

Another Fine Mess (2005)
If you use a plain-text editor for editing mtext, dimension, and table cell text, the internal mtext editor may annoy you when it messes up your formatting. For example, let's say your mtext contains this:

Hello \Fromand;World

If you use the internal mtext editor and pick OK without making any changes, it nevertheless changes to something like this:

Hello {\Fromand.shx|c1;World}

This adds unnecessary complications by surrounding the text with braces, specifying the font file extension, and assigning a local code page override to the word World where there was none before. While this is slightly antisocial behavior, it's not so much a bug as an unwelcome feature. Here's the bug. Let's take the same text as above, but apply a TrueType font instead, thus:

Hello \fArial;World

After editing with no changes in the internal editor, the text becomes this:

Hello {\fArial|b0|i0|c0|p0;;World}

This contains a superfluous secondary semicolon, which is a bug. The semicolon appears in the drawing, and you need to edit it out.

The internal editor also adds braces and local overrides for bold, italic, code page, and pitch/family, which is an unwelcome feature. It's especially unwelcome because AutoCAD documentation does not describe those overrides anywhere, so users of plain-text editors find themselves editing a bunch of undocumented gobbledygook.

No known workaround.