faq.txt

nedit 是一款linux下的开发源码的功能强大的编辑器

> 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.

> 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 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/

> 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 [e-mail]

> 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'.

> 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?)

> 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 &

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

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.

> 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.

> 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.

> 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.

> KP Enter does no longer executes the current line or selected text as a
> shell command. How can I get this behavior back?

It was considered dangerous to have a commonly used key potentially execute
arbitrary shell commands unintentionally (think rm -Rf). Therefore the
shortcut was changed to Ctrl+KP Enter. In case you want the old binding
back, you can add the following lines to your .Xdefaults or .Xresources
file:

   nedit*shellMenu.executeCommandLine.accelerator: <Key>KP_Enter",
   nedit*shellMenu.executeCommandLine.acceleratorText: KP Enter",