faq.xml

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

</pre>

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

</a>
</qna>

<qna id="N1077">
<q>When I try to open a file from the "Open" dialog nothing appears in
the "Filter" textfield</q>

<long-q>
<p>When I try to open a file from the "Open" dialog nothing appears in
the "Filter" textfield. Instead, I get repeated message like:</p>

<pre>
    Name: Text
    Class: XmTextField
    Character '/' not supported in font.  Discarded.
</pre>
</long-q>

<a>

<p>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
<site>ftp://ftp.nedit.org/pub/</site>
</p>

</a>
</qna>

<qna id="N1103">
<q>NEdit seems to be running very slowly on my Solaris 2.6 system.</q>

<a>

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

</a>
</qna>

<qna id="N1118">
<q>I can't seem to enter accented characters on my system.</q>

<a>

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

</a>
</qna>

<qna id="N1140">
<q>When I try to use nc to start an nedit server, I receive a message 
<tt>(filename): forward host lookup failed: ...</tt></q>

<long-q>
<p>When I try to use nc to start an nedit server, for instance using</p>

<pre>
    nc (filename)
</pre>

<p>I receive the following error message:</p>

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

</long-q>

<a>

<p>There is another program called <code>nc</code> which is installed on
some systems. In this case, <code>nc</code> is for <code>netcat</code>,
some kind of network diagnostic tool. You can safely rename NEdit's
<code>nc</code> to something else (we recommend ncl), or put it first in
your path before <code>netcat</code>.</p>

</a>
</qna>

<qna id="N1166">
<q>Whenever I try to open existing files by using menu, nedit crashes; but
if I type <code>nedit filename</code> command, it works.</q>

<long-q>
<p>Whenever I try to open existing files by using menu, nedit crashes, and
sometimes I get the following error message:</p>

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

<p>But if I type <code>nedit filename</code> command, it works. So
how can I open file by using menu bar?</p>

</long-q>

<a>

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

<pre>
  XBMLANGPATH=.
  export XBMLANGPATH
</pre>

<p>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.):</p>

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

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

</a>
</qna>

<qna id="N1202">
<q>I want to be able to spawn a command from NEdit.</q>

<long-q>
<p>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
<code>mctags</code>, but I
also have a variety of other things I'd like to do.  The shell command:
<code>mctags &amp;</code> continues to wait
for mctags to finish, despite the "&amp;".  Is
there any way to do what I want?</p>
</long-q>

<a>

<p>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
<code>&gt;&amp; /dev/null</code> to your shell
command, so it reads:</p>

<pre>
    mctags &gt;&amp; /dev/null &amp;
</pre>

</a>
</qna>

<qna id="N1221">
<q>NEdit flashes or matches the wrong parenthesis, bracket, or brace if there
is an intervening paren/bracket/brace quoted in between.</q>

<a>

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

</a>
</qna>

<qna id="N1236">
<q>I'd like to edit a file which is about 50 Megabytes long,
but I get errors.</q>

<long-q>
<p>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:</p>

<pre>
    Error: Cannot perform realloc
</pre>
</long-q>

<a>

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

</a>
</qna>

<qna id="N1255">
<q>We installed NEdit Version 5.0 recently, and the
accelerators Ctrl-G (Find again) and Ctrl-L (Goto Line Number) are now
missing</q>

<a>

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

</a>
</qna>

<qna id="N1270">
<q>On our PCs we have Windows 3.1 and we run XVision as X-Server and
we cannot mark with the mouse within NEdit.</q>

<long-q>
<p>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.</p>

<p>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.</p>
</long-q>

<a>

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

</a>
</qna>

<qna id="N1288">
<q>My regular expression replacement got truncated!</q>

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

<a>

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

</a>
</qna>

<qna id="N1303">
<q>NEdit is slow and pages continuously on my 8MB Linux system</q>

<a>

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

</a>
</qna>

<qna id="N1318">
<q>Some of the special keys on my keyboard don't do what I expect.</q>

<a>

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

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

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

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

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

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

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

<pre>
    nedit*text.Translations: #override \
        Alt&lt;Key&gt;t: XtDisplayTranslations()\n
</pre>

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

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

</a>
</qna>

<qna id="N1319">
<q>KP Enter does no longer executes the current line or selected text as
   a shell command. How can I get this behavior back?</q>

<a>

<p>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:</p>
   
<pre>
   nedit*shellMenu.executeCommandLine.accelerator: &lt;Key&gt;KP_Enter",
   nedit*shellMenu.executeCommandLine.acceleratorText: KP Enter",
</pre>

</a>
</qna>
</section>





</body>



</faq>