NEdit FAQ/bugs

From Niki

Contents 1 Bugs 1.1 Clipboard and LessTif 1.2 Paste problem on Mac. 1.3 NEdit inserts <dc3> instead of saving the file when I type ^S. Other keyboard shortcuts (accelerator keys) don't work either. 1.4 The keyboard shortcuts (accelerator keys) are not working when 'Caps' or 'Num Lock' are switched on. 1.5 There is a problem in the LaTeX syntax highlighting patterns: \% is seen as comment inside $ $. 1.6 NEdit crashes I try to paste text in to a text field in a dialog (like Find or Replace) on my SunOS system. 1.7 NEdit crashes frequently, particularly on window closing. 1.8 NEdit sometimes crashes when I execute a shell command menu item I just added. 1.9 When NEdit starts up, I get errors: 1.10 Sometimes when I use regular expression replacement inside of a rectangular selection, NEdit fails to match text which does legally match the expression. 1.11 Whenever I execute an nedit shell command (such as spell or wc) I get (extra junk, error messages, complaints from stty) inserted into my text, or an Information dialog with (extra junk, error messages, complaints from stty). 1.12 The file name list is sometimes too narrow 1.13 When I try to open a file from the "Open" dialog nothing appears in the "Filter" textfield. Instead, I get repeated message like: 1.14 NEdit seems to be running very slowly on my Solaris 2.6 system. 1.15 I can't seem to enter accented characters on my system. 1.16 nc gives me host lookup error 1.17 Whenever I try to open existing files by using menu, nedit crashes, and sometimes I get the following error message: 1.18 I want to be able to spawn a command from NEdit without waiting for the program to return. 1.19 NEdit flashes or matches the wrong parenthesis, bracket, or brace if there is an intervening paren/bracket/brace quoted in between. 1.20 I'd like to edit a file which is about 50 Megabytes long. 1.21 We installed NEdit Version 5.0 recently, and the accelerators Ctrl-G (Find again) and Ctrl-L (Goto Line Number) are now missing 1.22 NEdit is slow and pages continuously on my 8MB Linux system 1.23 Some of the special keys on my keyboard don't do what I expect. 1.24 Message 'Illegal mnemonic character; Could not convert X KEYSYM to a keycode' appears when I start nedit or when i open another file from within nedit.

Bugs

Clipboard and LessTif

There is a problem with the Clipboard and LessTif.

Paste problem on Mac.

On MacOS 10.2.3 with the new X11 application (version 0.1 from the Apple site, not to be confused with the earlier combination of XDarwin and window managers like Orobor OS X), paste does not work. Interestingly, cut from nedit to other applications does. If you merely need to move (rather than copy) text, a workaround is highlighting it and dragging it with the option key depressed.

NEdit inserts <dc3> instead of saving the file when I type ^S. Other keyboard shortcuts (accelerator keys) don't work either.

Either you are still using an NEdit version prior than 5.2 (see the next question), or you have turned Scroll Lock on, or you have an NEdit binary built with Lesstif.

If you have a binary built with Lesstif (perhaps necessarily using NEdit on non-open operating systems like MS Windows, Mac OS/X, OS/2), the <dc3> like insertions will happen only after showing the window background menu (more precisely after selecting an entry in this menu). If it happens, click in the window with the mouse to cure it (or display the background menu shortly again). If you have Lesstif version 0.93.0 you can avoid this by explicitly clicking with the left mouse button in the entry (to execute the macro) and leaving off the right button at the same time.

The keyboard shortcuts (accelerator keys) are not working when 'Caps' or 'Num Lock' are switched on.

This is a Motif design flaw. Since version 5.2 NEdit works around this, so update your NEdit version.

There is a problem in the LaTeX syntax highlighting patterns: \% is seen as comment inside $ $.

There is a fixed patterns set here: http://www.nedit.org/archives/discuss/2002-Aug/0083.html

NEdit crashes I try to paste text in to a text field in a dialog (like Find or Replace) on my SunOS system.

On many SunOS systems, you have to set up an nls directory before various inter-client communication features of Motif will function properly. Before NEdit 4.0 this wasn't much of a problem, because users couldn't cut and paste at all, and Motif would sometimes print a warning about not finding an nls directory, so most users figured it out right away. But with 4.0, everything seems to be working fine, except when someone tries to move text in or out of a dialog field, then blamo.

There are instructions in README.sun in ftp://ftp.nedit.org/pub/<current-version<, as well as a tar file containg a complete nls directory: ftp://ftp.nedit.org/pub/<current-version</individual/README.sun

It contains directions for setting up an nls directory, which is required by Motif for handling copy and paste to Motif text fields.

NEdit crashes frequently, particularly on window closing.

There is an obsolete resource in Motif called defaultFontList, which does nothing but cause random crashing. I don't know why NEdit users keep popping up with this resource set, maybe it looks enticing when you look at widget resources with editres. Anyhow, setting it to anything, whether it be a valid font or just garbage, causes random crashing in both Motif 1.2 and 2.0, so just don't set it.

NEdit sometimes crashes when I execute a shell command menu item I just added.

Check the "Command Input" setting, in the Preferences->Shell Commands dialog for that menu item. If the shell command being executed does not take input, but "Command Input" is set to "selection" or "window", NEdit tries to write the input anyhow, and fails. Set "Command Input" to "none" to prevent this possibility. This is fixed in version 5.1 and later.

When NEdit starts up, I get errors:

> Cannot allocate colormap entry for "#b3b3b3" 
> Cannot allocate colormap entry for "#e5e5e5"

Most X displays are set up to operate in a mode which allocates 8 bits of video memory per-pixel, and requires a color mapping table to translate pixel values to screen colors. With just 8 bits there are only 256 possible colors, and programs must either allocate and share these pixel values, or swap in their own colormap and make all other windows flash to strange colors while their window is focused. Some programs, Netscape in particular, are bad neighbors in this environment and snarf up every free entry in the shared colormap, such that every program that runs after them gets the errors you're asking about.

The solution is either to start Netscape last, after all other applications that you might want to run, or better, tell Netscape how many colors it is allowed to allocate. Fortunately, you can do this with a resource setting:

   Netscape*maxImageColors: 80

Sometimes when I use regular expression replacement inside of a rectangular selection, NEdit fails to match text which does legally match the expression.

The problem with REs and rectangular selections is that matching is bounded by the rectangular selection, but text outside of the selection is still fed to the matching routines, so ^, $, don't refer to the edges of the selection, they still refer to the beginning and ending of the line, and some legal matches are excluded because they continue outside of the selection are thereby excluded, or are shadowed by matches which begin or end outside of the selection.

Whenever I execute an nedit shell command (such as spell or wc) I get (extra junk, error messages, complaints from stty) inserted into my text, or an Information dialog with (extra junk, error messages, complaints from stty).

You probably have printing commands in your shell startup file (.cshrc, or equivalent). These should either be skipped in non-interactive mode, or moved to your .login file. You can often see the problem outside of nedit by typing:

   csh -c ls

Error messages from stty are a result of it being executed from a process which isn't attached to a terminal. You can safely move stty statements and most other interactive commands to your .login file (calling stty from a .cshrc file is redundant because the terminal device doesn't change for each sub-shell). If you can't remove interactive commands, you should skip around them in non-interactive shells, I think the usual method is to put them at the end, preceded by something like:

   if ($?prompt == 0) exit

The manual entry on csh has more information on this.

The file name list is sometimes too narrow

On a Solaris system, when trying to open a file within nedit, you get the listing of available file names. However, the sub-window (on the right) containing the file names (not directory names) sometimes is too narrow so that you can't see the filename part (i.e. /usr/people/rainer/sometextfile.txt shows up as /usr/people/rain or so). When resizing the dialog box, the filenames sub-window on the right doesn't become larger. I know I can use nedit.stdOpenDialog to type a filename, but that's annoying.

It's a bug in the shared Motif library. Depending on your system, the patch is one of ID# 103461-07, # 102226-19, or # 103186-21. If you can't patch your system, you can set the resource:

   nedit*XmFileSelectionBox.pathMode:  XmPATH_MODE_RELATIVE

This will stop the dialog from displaying the path component of file names. Another possible workaround is to use the nedit_sunos executable (from ftp://ftp.nedit.org/pub/), which is statically linked with a good Motif.

When I try to open a file from the "Open" dialog nothing appears in the "Filter" textfield. Instead, I get repeated message like:

> Name: Text
> Class: XmTextField
> Character '/' not supported in font.  Discarded.

In some versions of SuSE Linux, there's apparently something wrong with their builds of NEdit and other Motif apps. I've been told you can make nedit work by seting the environment variable LD_PRELOAD to /lib/libBrokenLocale.so.1 before launching it. You can also use the statically linked version of NEdit for Linux from ftp://ftp.nedit.org/pub/

NEdit seems to be running very slowly on my Solaris 2.6 system.

If you're running NEdit on a Solaris 2.6 system and experiencing performance problems (windows come up slowly), the patch for Sun's shared Motif library is ID# 105284-04. Installing the patch alone will improve the performance dramatically. The patch also enables a resource, *XmMenuReduceGrabs. Setting this to True will eliminate the delay completely.

I can't seem to enter accented characters on my system.

This should be working properly on most systems as of NEdit 5.1 or later. If it's not, try re-building NEdit with -DNO_XMIM. If it still doesn't work, send mail to develop@nedit.org

nc gives me host lookup error

When I try to use nc to start an nedit server, for instance using

> nc (filename)

I receive the following error message:

> (filename): forward host lookup failed:
>  Host name lookup failure: Connection refused

There is another program called nc which is installed on some systems. In this case, nc is for netcat, some kind of network diagnostic tool. If you install NEdit yourself, you can safely rename NEdit's nc to something else (we recommend ncl). If you use NEdit as provided by your OS supplier, look for ncl, nclient, nedit-nc or something similar.

Whenever I try to open existing files by using menu, nedit crashes, and sometimes I get the following error message:

>  X Error of failed request:  BadAlloc (insufficient resources for operation)
>  Major opcode of failed request:  53 (X_CreatePixmap)

But if I type 'nedit filename' command, it works. So how can I open file by using menu bar?

Several users have reported this problem. Most of them were using SuSE Linux. A few others had different distributions, but always European. The problem appears to be related to how Motif searches for named pixmaps and bitmaps. My guess is that on some systems, this search encounters a match with a bad pixmap file, or tries to load something which is not a pixmap at all. One solution was to set the environment variable XBMLANGPATH to a random directory. For example:

 XBMLANGPATH=.
 export XBMLANGPATH

The solution on SuSE Linux systems was to remove an unnecessary line in the global /etc/profile (provided by SuSE):

 export XAPPLRESDIR=
     "$XAPPLRESDIR:/var/X11R6/app-defaults:/usr/X11R6/lib/X11/app-defaults"

Another user who had the problem reported that the root cause appeared to be insufficient read permissions on some xm_* (e.g. xm_warning) pixmaps in "/usr/X11R6/include/X11/bitmaps". (Could someone else confirm this?)

I want to be able to spawn a command from NEdit without waiting for the program to return.

At the moment I'd like to be able to launch mctags, but I also have a variety of other things I'd like to do. The shell command: 'mctags &' continues to wait for mctags to finish, despite the "&". Is there any way to do what I want?

It's a bug/feature of NEdit that it considers a shell command process alive as long as any of its file descriptors remain open. Forked processes generally copy and keep open the stdout and stderr descriptors from their parent process, so you have to add >& /dev/null to your shell command (c-like shells), so it reads:

   mctags >& /dev/null &

Notice that this will not work with Bourne shells (not even with the correct syntax for these shells). (This is fixed in v5.5.)

The above solution seems to miss that csh and tcsh by default print the job and process IDs for shell commands that are executed in the background, that is, shell commands that end in "&". To stop this output from showing up, enclose the shell command, including the "&", in parentheses (generate a sub-shell) and redirect the output of the entire sub-shell to /dev/null, i.e.:

   (mctags &) >& /dev/null

NEdit flashes or matches the wrong parenthesis, bracket, or brace if there is an intervening paren/bracket/brace quoted in between.

Update to NEdit version 5.3.

I'd like to edit a file which is about 50 Megabytes long.

Whenever I try to read this file, there was always a message as following:

>  Error: Cannot perform realloc

How large a file you can edit with NEdit depends on how much swap space + RAM you have, since it loads your file into virtual memory and occasionally does a full copy of that memory space. NEdit can handle a 100MB file reasonably well if you increase your swap space, but I don't know how far beyond that it can go. To work with a 100MB file, you must have at least 200MB of virtual memory available. Many Unix systems can be set up to temporarily increase swap space by creating a temporary swap file.

We installed NEdit Version 5.0 recently, and the accelerators Ctrl-G (Find again) and Ctrl-L (Goto Line Number) are now missing

You have an out-of-date app-defaults file. We strongly recommend not using such files for this exact reason. When you use an app-defaults file, it replaces ALL of the program defaults. If you do install an app-defaults file, it is your responsibility to keep it up to date with each new release of the executable. Otherwise, as you have observed, certain features will degrade with each release, as the app-defaults file and the executable get further and further out of sync with eachother.

! My regular expression replacement got truncated! I wrote a regular expression to nest additional braces around blocks of code (replace {([^{}]|\n)*} with {\0}), which works for small blocks of text, but it fails on large ones, truncating the replacement at around 512 bytes.

A remnant of pre-regular-expression, pre-macro-language NEdit, is that replacement strings are limited to 511 bytes. This is high on the list to fix in a future upgrade.

NEdit is slow and pages continuously on my 8MB Linux system

On most Unix workstations, 8MB of RAM is actually insufficient to run X and Motif properly. Some Linux users get by with it and Linux itself seems to be quite memory efficient, but you really should have 12 or 16 if you're going to be using X much. NEdit would not be my first choice in editors on an 8MB system.

Some of the special keys on my keyboard don't do what I expect.

X systems are rife with this kind of problem because are just too many levels of re-settable bindings between the keyboard and the application program that reads it. Sun systems are the worst offenders, combining poor Motif support with a variety of strange keyboard arrangements.

To diagnose these problems, you have to look at all three levels of key binding that affect Motif programs.

At the bottom level are the modifier map and keymap table, where hardware key codes are bound to X keysyms. You can see the bindings on this level with the xmodmap program (see man xmodmap). A useful tool in debugging the xmodmap level is a program like xev, which can show you the keysyms it receives.

The next level up from that is the motif virtual binding level (see man VirtualBindings). You can (usually) view the bindings at this level by looking at the value of the root window property: _MOTIF_DEFAULT_BINDINGS, using the xprop -root command, however what you see is not necessarily what you'll get. The defaults for these bindings are determined by an unbelievably complicated process involving not just the application in question, but Motif applications which have run before it attached to the same server. This process is described in detail in the VirtualBindings manual page (which is often not available on systems where the bindings are messed up). While it's usually better to attack system configuration problems at the source, this one is so contorted that you're better off with a patch. Luckily, the default Motif virtual bindings can be overridden by an application resource called defaultVirtualBindings. If you think the problem is at the Motif virtual binding level, define a defaultVirtualBindings resource in your .Xresources or .Xdefaults file, using the example below as a template, replacing the keysym names (to the right of the colon) with the keysyms shown by xev when you press the desired key:

   !
   ! Motif Virtual Key Bindings
   !
   nedit*defaultVirtualBindings: \
        osfActivate     :               <Key>KP_Enter\n\
        osfCancel       :               <Key>Escape\n\
        osfHelp         :               <Key>Help\n\
        osfMenu         :               <Key>F4\n\
        osfMenuBar      :               <Key>F10\n\
        osfLeft         :               <Key>Left\n\
        osfUp           :               <Key>Up\n\
        osfRight        :               <Key>Right\n\
        osfDown         :               <Key>Down\n\
        osfBeginLine    :               <Key>Home\n\
        osfEndLine      :               <Key>End\n\
        osfPageUp       :               <Key>Prior\n\
        osfPageDown     :               <Key>Next\n\
        osfBackSpace    :               <Key>BackSpace\n\
        osfDelete       :               <Key>Delete\n\
        osfInsert       :               <Key>Insert\n\
        osfUndo         :               <Key>F14\n\
        osfAddMode      :Shift          <Key>F8\n\
        osfCopy         :               <Key>F16\n\
        osfCut          :               <Key>F20\n\
        osfPaste        :               <Key>F18\n

If NEdit is having binding problems, chances are that other Motif-based programs are also having trouble. Removing the "nedit" from the resource name above (just *defaultVirtualBindings), will apply it to the other Motif programs that you run as well.

The top level bindings in the key binding hierarchy, are the X toolkit translation tables (see the NEdit Help section called X Resources). To show the translations in use, you can add a binding which dumps the table itself:

    nedit*text.Translations: #override \
        Alt<Key>t: XtDisplayTranslations()\n

Typing Alt+T will then display the contents of the translation table to stdout (the terminal from which you started NEdit). If you have the NEdit source, you can also look at the default bindings in the module text.c.

Sometimes, even if you don't understand the problem, you can patch around it by supplying translations for the keysyms that NEdit actually sees, binding them to the action routines that you want activated when you press that key.

Message 'Illegal mnemonic character; Could not convert X KEYSYM to a keycode' appears when I start nedit or when i open another file from within nedit.

The full text of the error message is:

   Name: executeCommandLine
   Class: XmPushButton
   Illegal mnemonic character;  Could not convert X KEYSYM to a keycode

This appears to be an issue when the user is in a VNC session. The solution is to add an entry to the xmodmap file to the numeric keypad key 'Enter'. e.g. xmodmap -e 'keycode 0x6C = KP_Enter' . To make the previous command line solution permanent, add the line to a .xmodmap file that is loaded when your x server starts. An easy way to find out the keycode for your keyboard, they are not all the same, is to use the program called xkeycaps from http://www.jwz.org/xkeycaps