features lacking relative to NEdit
Oliver Kiddle
of different alternatives (NEdit doesn't support UTF-8, uses Motif and
isn't much maintained). There's a few features that I'm missing in
scite and I was hoping someone might already have a lua script to do
some of these things. Sorry for putting several questions in one e-
mail: if you reply to just one, consider changing the subject. If
there are any other NEdit converts here I'd be interested in any other
hints based on your experience.
Find Selection: In NEdit, i can select a word with the mouse and press
Ctrl-H and it will find it. This works with text selected outside the
editor such as in the terminal. (scite does include text selected with
scite as the default when you do Ctrl-F).
Go to Line Number: In NEdit, if I select a number, for example in some
build output in the terminal, I can press Ctrl-E to go to the line
number corresponding to that number.
Indentation one character at a time: something like tab and shift-tab
do with a selection but always by just one character position. (These
are Ctrl-( and Ctrl-) in NEdit).
Justify/Fill Paragraph: Ctrl-J does something equivalent to piping the
current paragraph through fmt - in vi, something like 0!}fmt. This
surely can be done with a script. For the Wrap Output option in scite,
how configurable is the maximum line width. I'd like to set it to 72
characters but can't find a way.
Version 2 apparently adds multiple selections. Are these possible in
the GTK port? Ctrl-Mouse is the rectangular selections, Alt-Mouse is
used by Gnome for moving the window. In NEdit, to do "secondary
selections", you drag with the middle mouse button - pasting is done
on middle mouse button release as opposed to on the press. Are the
mouse combinations configurable at all?
I can configure the status bar to look how I want but one thing I like
about the equivalent in NEdit is that the contents can be selected.
Does anyone know if it is possible to enable this, perhaps with
something in .gtkrc-2.0. It'd also be nice if the Pathbar contents
could be configured much in the way the Status bar is and if there was
some mechanism for having elements left, centre and right-aligned.
Is it possible to make monospace the default font but still be able to
use a variable width font for certain file types - DocBook for
instance. I can configure a monospace default but not without breaking
the "Use Monospace" menu option.
I find that the fonts look much bigger on Linux than I would expect
given a particular point size. On Solaris, they look right. Any ideas?
I've got
position.width=605
position.height=395
in my configuration. Is it not possible to specify the size in
characters rather than pixels. For example, 80x24.
The biggest problem I have is with the way check.if.already.open=1
works (or doesn't) but I'll post about that separately later.
Thanks
Oliver
Philippe Lhoste
> Find Selection: In NEdit, i can select a word with the mouse and press
> Ctrl-H and it will find it. This works with text selected outside the
> editor such as in the terminal.
Ctrl+F3 (I use it all the time). Obviously won't work outside of SciTE.
> Go to Line Number
Ctrl+G
> Indentation one character at a time
Mmm, until recently, it wasn't doable without changing temporarily the tab settings
(Ctrl+Shift+I to go there quickly).
Now you do a rectangular selection (eg. Alt+drag pressed mouse or Alt+Shift+keyboard
arrows) and you can type your space.
> Justify/Fill Paragraph [...] This
> surely can be done with a script.
Yes. Maybe define a precise need if the Edit > Paragraph > Join/Split option doesn't do
that for you.
> For the Wrap Output option in scite,
> how configurable is the maximum line width. I'd like to set it to 72
> characters but can't find a way.
Both this and the Join/Split act on the visible right margin. You can set the edge.mode
and edge.column (and edge.colour) settings to help you set this margin to the desired char
width, depending on your font.
> Is it possible to make monospace the default font but still be able to
> use a variable width font for certain file types - DocBook for
> instance. I can configure a monospace default but not without breaking
> the "Use Monospace" menu option.
Somehow, I do that: I have just set my fonts to be fixed width font on most lexers, except
on some scripting languages (the informal look is nice...) and in HTML for example. That's
just some tweaks on the font.code.* settings.
> I find that the fonts look much bigger on Linux than I would expect
> given a particular point size. On Solaris, they look right. Any ideas?
Change the styles, as shown above. It might be hard to share the same properties files,
though, unlike PLAT_WIN vs. PLAT_GTK
> in my configuration. Is it not possible to specify the size in
> characters rather than pixels. For example, 80x24.
No, since it depends on the font(s) you chose, which depend on the currently opened
document, etc.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Oliver Kiddle
> The biggest problem I have is with the way check.if.already.open=1
> works (or doesn't) but I'll post about that separately later.
When running scite, It creates a named fifo in /tmp. This is named
something like SciTE33c2.results. This allows a second instance of
scite to control the first instance so that I can run scite <file> on
the command-line and it gets opened in the first instance. With
multiple users running scite, they each have their own fifo.
Unfortunately, if one user is logged in at more than one display, it
goes wrong. From a Windows or single-user Linux perspective this may
not seem a problem but I've hit it quite a lot. Where I work, we have
role based "user" accounts for operations (as opposed to for
development) and many terminals connected to the same machine (via Sun
Ray thin clients) so this situation occurs a lot. We also have some
non-Xinerama multiple monitor setups with different displays allocated
to each monitor. Even at home, I have a multi-seat Linux setup and
sometimes log in to both displays for whatever reason. It also comes
up using vnc.
The quick fix for this would be to include the X display name in the
temporary file name. Is scite used on platforms where gtk is used but
X isn't?
NEdit uses X properties to achieve the same effect. This includes X
Action Routines for more complex control of the running NEdit
instance. NEdit even manages to nicely handle multiple desktops with
separate NEdit windows (corresponding to a single instance) opening on
different desktops.
The GTK way of doing this is to use dbus. There is even a libunique
which ensures a single instance of the application.
What is the rationale for the temporary fifo solution. Looking around
for other applications that use a temporary file (albeit a socket
rather than a fifo), I've only found oldish audio players which is
arguably different because control of audio hardware is potentially
separate from the display. A link that goes through the X server uses
X authentication so security is simplified. It also avoids the issue
of clearing up the temporary file. I'd be interested to know whether
you are open to other solutions?
Oliver
Neil Hodgson
> When running scite, It creates a named fifo in /tmp. This is named
> something like SciTE33c2.results.
*.results was the fifo used for running tools. I think you mean *.in
> The quick fix for this would be to include the X display name in the
> temporary file name.
This may cause trouble for applications that work with SciTE and
expect a particular naming scheme.
> Is scite used on platforms where gtk is used but
> X isn't?
I think that was how the Cygwin variant worked. Don't really want
to lock out other platforms - its possible that GTK+ on OS X will be
worth using at some point and its a lot less work than a native OS X
port.
> The GTK way of doing this is to use dbus. There is even a libunique
> which ensures a single instance of the application.
The director interface is a general purpose control channel, its
not just for ensuring uniqueness.
> What is the rationale for the temporary fifo solution.
It had to be reasonably similar to the use of WM_COPYDATA messages
on Windows.
ORBit used to be the preferred mechanism in this area for GTK+ and
GNOME but being CORBA it was doomed and a fifo appeared much simpler.
D-Bus may be longer lived but when I had a quick look it appeared
complex. Others have argued on the list against D-Bus.
Neil