faq.xml

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

continues and assumes the editor has finished, when in fact it hasn't.</p>
</long-q>

<a>

<p>nc is actually finished communicating with the NEdit server when it
returns.  It's possible to create a shell command that invokes nc and
then goes to sleep, and a second script to be run from the NEdit Shell
menu, which looks for the sleeping process with a matching file name
and kills it.  Try the shell scripts in:</p>

<blockquote>
<p>
<site>ftp://ftp.nedit.org/pub/contrib/misc/</site>nc_and_wait.tar
</p>
</blockquote>

</a>
</qna>

<qna id="N788">
<q>I started nedit as root, then tried later to edit a file as myself with
<code>nc</code>; the file was opened in the root's nedit</q>

<long-q> <p>I started nedit (via <code>nc</code>) as root, and then
later tried to edit a file as myself with <code>nc</code>. I was very
suprised to see that a new nedit wasn't started--rather, I was given
the old nedit window, with root permissions. Isn't this a security
hole?</p> </long-q>

<a>

<p>Actually, NEdit does check who the user is.  When you use the su
command, however, several Unix variants return the original user name
in response to the standard C library calls for getting a user name,
rather than the name to which you have su'd.  Starting with version 5.1,
a different mechanism is used for getting this information, so you shouldn't
see this problem any more.</p>

<p>In your case, my guess is that you used su to become root, then
started an nedit server as root.  On a system which returns the
original user name, both the new server and the nc client program
think the user name is your original user name, so the server accepts
requests from both you as root and you as you.</p>

<p>The security of an nedit session, depends upon the security of your X
server.  Only those with access to your screen can send commands to an
nedit server, but they can also send keystrokes to any nedit, or a shell
window, etc...  Anyhow, just upgrade to the latest NEdit version.</p>

</a>
</qna>

</section>













<section id="sect_techniques">

<title>Editing techniques</title>

<qna id="N816">
<q>I'd like to select a large expanse of text
without dragging all the way through it with the mouse.</q>

<a>

<p>Using the shift key with the left mouse button, you can select all of the text
between the cursor (or an existing selection) and the mouse.</p>

<ul>
  <li>Position the cursor at one end of the desired selection</li>
  <li>Use the scroll bar to make the other end visible</li>
  <li>Shift+Click with the left mouse button to select the text between
     the cursor and the mouse</li>
</ul>

<p>Alternatively, using only keyboard navigation:</p>

<ul>
  <li>Position the cursor at one end of the desired selection</li>
  <li>Type Alt-m and a letter to mark the position</li>
  <li>Use the keyboard to go to the other end of the desired selection</li>
  <li>Type Shift-Alt-g and the letter you used to mark the first end
  of the selection</li>
</ul>


</a>
</qna>

<qna id="N847">
<q>How can I select the text between two marks?</q>

<a>
<ul>
	<li>Go to the first mark (Goto Mark).</li>
	<li>Hold the shift key while selecting Goto Mark or Alt+Shift+G to
    select the text.</li>
</ul>

</a>
</qna>

</section>
















<section id="sect_bugs">

<title>Bugs</title>

<qna id="N900">
<q>The keyboard shortcuts (accelerator keys) are not
working when 'Caps' or 'Num Lock' are switched on.</q>

<long-q>
<p>The keyboard shortcuts (accelerator keys) are not
working when 'Caps' or 'Num Lock' are switched on.  Have I
overlooked something obvious?</p>
</long-q>

<a>

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

<p>Another possibility (writes Peter Daifuku of SGI):</p>

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

</a>
</qna>

<qna id="NumLockBis">
<q>Sometimes NEdit inserts &lt;dc3&gt; instead of saving the
file when I type ^S</q>

<long-q>
<p>Sometimes NEdit inserts &lt;dc3&gt; instead of saving the
file when I type ^S. Other keyboard shortcuts (accelerator keys) don't
work either.</p>
</long-q>

<a>
You have probably NumLock or CapsLock ON. See the answer to
<link href="#N900">this</link> question.
</a>

</qna>




<qna id="Keypad">
<author><name>Joor Loohuis</name></author>
<q>I use the numeric keypad really often, so I keep NumLock on.
But NEdit shortcuts don't work when NumLock is on.</q>

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

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

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

<p>Then make sure the script that starts your X session parses this file with
the command:</p>
<pre>
  xmodmap -merge ~/.Xmodmap
</pre>

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

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


</a>

</qna>





<qna id="N927">
<q>NEdit crashes I try to paste text in to a text field in a dialog
(like Find or Replace) on my SunOS system.</q>

<a>

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

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

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

</a>
</qna>

<qna id="N955">
<q>NEdit crashes frequently, particularly on window closing.</q>

<a>

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

</a>
</qna>

<qna id="N970">
<q>NEdit sometimes crashes when I execute a shell command menu item I
just added.</q>

<a>

<p>Check the "Command Input" setting, in the Preferences-&gt;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.</p>

</a>
</qna>

<qna id="N985">

<q>When NEdit starts up, I get errors like:
<tt>Cannot allocate colormap entry for "#b3b3b3".</tt>
</q>
   

<long-q>
<p>When NEdit starts up, I get errors:</p>

<pre>
   Cannot allocate colormap entry for "#b3b3b3"
   Cannot allocate colormap entry for "#e5e5e5"
</pre>
</long-q>

<a>

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

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

<blockquote>
<p><tt>Netscape*maxImageColors: 80</tt></p>
</blockquote>

</a>
</qna>

<qna id="N1011">

<q>Sometimes when I use regular expression replacement inside of a
rectangular selection, NEdit fails to match text.</q>

<long-q>
<p>Sometimes when I use regular expression replacement inside of a
rectangular selection, NEdit fails to match text which does legally
match the expression.</p>
</long-q>

<a>

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

</a>
</qna>

<qna id="N1026">

<q>When ever I execute a nedit shell command (such as spell or wc) I get
extra junk.</q>

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

<a>

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

<pre>
    csh -c ls
</pre>

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

<pre>
    if ($?prompt == 0) exit
</pre>

<p>The manual entry on csh has more information on this.</p>

</a>
</qna>

<qna id="N1055">
<q>On a Solaris system, the right part of the 'file open' dialog
is too narrow, I can't see the complete file names.</q>

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

<a>

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

<pre>
    nedit*XmFileSelectionBox.pathMode:  XmPATH_MODE_RELATIVE