faq.txt

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

Replace dialogs via the up-arrow and down-arrow keys.

> I would like to use (multiple fonts, special symbols) in my file, but NEdit
> seems to allow just one single font.

NEdit is a plain text editor, not a word processor. Plain text files have
no font or formatting information contained in them, they are just a string
of ascii characters. While you might find a font with limited symbols and
greek letters, your troubles would just be beginning. You'd still have
trouble getting the printer to agree and print out the characters as they
appeared in NEdit. For anything involving font changes or special symbols,
you need a word processor, such as Microsoft Word, or a text formatting
program like LaTEX.

> Auto-wrap doesn't work very well. When I type in the middle of a line, I
> can push the end of the line beyond the right margin, and when I delete, It
> doesn't keep the right edge of the text lined up.

You probably want continuous wrap mode (Preferences -> Wrap -> Continuous).

Because NEdit is not a word processor, it is stuck with the limits of the
plain text format. In the default, auto-newline, wrapping mode, nedit does
wrapping by inserting newline characters. Because there is only one newline
character, NEdit can't distinguish a newline which can be "unwrapped" from
one which the user intended to be permanent. While it might be possible for
NEdit to temporarily make that distinction, for example while the cursor is
on a particular line that the user is typing, ultimately, NEdit will have
to forget this information, because there is no way to save it in the file.
Users who work in auto-newline wrap mode tend to make liberal use of the
Fill paragraph command.

In continuous wrapping mode, you can intentionally leave out the newlines
within paragraphs, and lines will be wrapped as needed to fit within the
page. When you edit in the middle of a paragraph, the text will be
continuously adjusted. However, continuous wrap mode has it's limitations
too. All paragraphs must be lined up against the right margin to take
advantage of continuous wrapping, and Unix systems have limited support for
files of that format. You may have trouble printing and viewing the files
outside of NEdit.

> NEdit scrolls too fast when I extend a selection by dragging the mouse
> outside of the window.

NEdit features proportional auto-scrolling, where the speed is controlled
by how far your mouse is beyond the edge of the window. If you want it to
scroll slower, bring the mouse back closer to the text.

> Is there a special symbol (as % for filename in the shell commands) that
> can be used to represent the text that is selected, which can then be used
> as an argument to a command? For instance, I want to feed the selection to
> a script so that it can be used as the expression to a 'grep' command. Is
> there any other way that I can accomplish this goal?

Below is an example from the NEdit discussion list (from David L.
Paterline) of a "Find All" command implemented by using the selection as an
argument to the grep command:

    I set up a command to list all lines in a file which contain the
    highlighted selection as follows, using the Preferences -> Shell
    Commands menu:

        Menu Entry:           all <selection>
        Command Input:        selection
        Command Output:       new window
        Save file before:     yes
        Shell Command:        grep -n -- "`cat -`" %

    The 'cat -' portion of the command echoes the selected text to the
    'grep -n' command, which lists the lines containing the selection with
    line numbers. The output of the command appears in a new window; I can
    then highlight a line number in the new window and use the Search ->
    Goto Selected menu in the original window to jump to the line in the
    original file.

> How can I print highlighted text on my printer as it appears in NEdit.

In the current version, that's not possible, but there are external tools
for highlighting, which are specifically designed for printing, including
a2ps, enscript, and genscript.



SERVER MODE AND NC
------------------


> I use a mailer which can invoke an external editor, but if I use nc, the
> mailer process continues and assumes the editor has finished, when in fact
> it hasn't.

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:

    ftp://ftp.nedit.org/pub/contrib/misc/nc_and_wait.tar

> I started nedit (via 'nc') as root, and then later tried to edit a file as
> myself with 'nc'. 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?

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.

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.

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.



EDITING TECHNIQUES
------------------


> I'd like to select a large expanse of text without dragging all the way
> through it with the mouse.

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.

    * Position the cursor at one end of the desired selection

    * Use the scroll bar to make the other end visible

    * Shift+Click with the left mouse button to select the text between the
    cursor and the mouse

Alternatively, using only keyboard navigation:

    * Position the cursor at one end of the desired selection

    * Type Alt-m and a letter to mark the position

    * Use the keyboard to go to the other end of the desired selection

    * Type Shift-Alt-g and the letter you used to mark the first end of the
    selection

> How can I select the text between two marks?

    * Go to the first mark (Goto Mark).

    * Hold the shift key while selecting Goto Mark or Alt+Shift+G to select
    the text.



BUGS
----


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

> 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 (#N900)
question.
> I use the numeric keypad really often, so I keep NumLock on. But NEdit
> shortcuts don't work when NumLock is on.

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

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