nedit filename command, it works.
1. The keyboard shortcuts (accelerator keys) are not working when 'Caps' or 'Num Lock' are switched on. Have I overlooked something obvious?
You haven't overlooked anything, it's a Motif design flaw. Netscape painfully works around this and the Alt/Meta key reversal on Sun workstations by internally re-implementing the Motif menu accelerator mechanism. NEdit will likely follow suit with the release of version 5.2.
Another possibility (writes Peter Daifuku of SGI):
There's another answer which unfortunately isn't widespread as yet. For an X11R6.3 X server supporting the XKB extension, there is a mechanism to ignore the NumLock and CapsLock key as modifiers. The file /usr/lib/X11/xkb/X0-config.keyboard should contain the string IgnoreLockMods=NumLock+Lock . For systems with multiple displays, display 1 would be controlled by the file X1-config.keyboard, etc.
On SGI systems, this mechanism is support on IRIX 6.2 with X server patch 1574 or later, on IRIX 6.3 and IRIX 6.4 and all later releases.
2. Sometimes NEdit inserts <dc3> instead of saving the file when I type ^S. Other keyboard shortcuts (accelerator keys) don't work either.
You have probably NumLock or CapsLock ON. See the answer to this question.The bug is not in NEdit, but in Motif. This is fixed as of NEdit 5.2, but that might not help you much. Older versions have the same problem.
Here's how you tell X to interpret the keypad keys as numbers without turning NumLock on. Create a file .Xmodmap in your home directory, and put the following lines in it:
keycode 79 = KP_7 keycode 80 = KP_8 keycode 81 = KP_9 keycode 83 = KP_4 keycode 84 = KP_5 keycode 85 = KP_6 keycode 87 = KP_1 keycode 88 = KP_2 keycode 89 = KP_3 keycode 90 = KP_0 keycode 91 = KP_Decimal
Then make sure the script that starts your X session parses this file with the command:
xmodmap -merge ~/.Xmodmap
This script can be ~/.xinitrc (called by startx) or something like Xsession if you use xdm/kdm/gdm. Then again, it might be an entirely different script on some systems.
Then turn off numlock, and just continue using the keypad. The only thing is, you loose the alternate set of functions (cursor/home/pgdown/etc).
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.
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.
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.
7. 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
8. 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.
9. When ever 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.
10. 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.
11. 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 S.u.S.E. 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/
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.
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
14. 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. You can safely rename NEdit's
nc to something else (we recommend ncl), or put it first in
your path before netcat.
15. 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 S.u.S.E. 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 S.u.S.E Linux systems was to remove an unnecessary line in the global /etc/profile (provided by S.u.S.E.):
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?)
16. I want to be able to spawn a command from NEdit. By this I mean that I
want to NEdit to launch another program 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 it's 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, so it reads:
mctags >& /dev/null &
Until version 5.0, NEdit had no way of even knowing what language you were operating in when making the flash/match decision, so it simply counted opening and closing instances, disregarding language syntax context (strings, comments, etc.) completely. Now that the feature is more possible to implement, it may be included in a future version, but I'm not entirely sure how best to do it yet.
18. 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.
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.
20. On our PCs we have Windows 3.1 and we run XVision as X-Server. The problem that we have is, that we cannot mark with the mouse within NEdit.
When you click and hold the left mouse button and then move the mouse, you can see the mark-area flickering during the movement of the mouse. When stopping the movement nothing is highlighted and nothing is marked.
XVision is grabbing the selection immediately, as soon as it is made, not allowing applications to own it. This behavior is completely wrong, and I have no idea what they might have been thinking when they implemented it. It may be possible to turn it off, ask their technical support people if they're not already out of business.
21. 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.
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.
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.