Your mission, should you choose to accept it...
Robin Dunn
Hi all,
Kevin O. and I recently discussed in IM about yet another wxPython-based
code editor and the subject of my Emacs use came up. I've been an Emacs
user for more than two decades, and it has been a love/hate relationship
for most of that time (I hate that I love it and I love hating it) but I
would like to dump it for something else, iff the RIGHT something else
came along. Part of our discussion centered on the fact that it is not
just the emacs-style key-bindings that keep me using Emacs (most of the
key-bindings I use are customized anyway, or I load extensions to add
CUA key-bindings, etc.) but it is some more fundamental features that I
use many times every day that keep me there.
So here is your challenge and your mission impossible, should you choose
to accept it: Create a code editor that will pry emacs and its
25-year-old nearly dead technology out from under my fingers.
Here are the emacs features that I use very often that any editor would
need to have in order for me to switch. I've seen some editors with
some of these, but none with all unless it is an emacs clone. I'll
leave out the obvious things like platform independence, good syntax
highlighting, calltips or auto-completion. Also, these features are
just dealing with the code editor portion of the app, if it is more than
that (like a full IDE) then some of these things may or may not apply to
the non code editor parts:
* Python should be just one of the languages that this editor supports,
not the primary target. I spend as much time in C/C++ as I do Python,
and my editor of choice needs to help me with C/C++ coding just as much
as it does with Python. So some sort of support for calltips and
auto-completion would be marvelous, and also being able to act as a
front-end for gdb since I currently use emacs for that most of the time.
* Absolutely every feature or action must be able to be done with just
the keyboard. Moving the hand back and forth to the mouse wastes time,
breaks concentration and contributes to RSI. Multi-key sequences are
fine as long as they are grouped in a logical fashion. For example in
emacs all of the version control features are accessible via the
Ctrl-x,v sequence plus one more letter.
* Incremental search, both forward and reverse, and wrapping around
after you've reached the end or the beginning of the document. I like
to have the same key to start the search and also do a search-next after
you've typed all the characters you are searching for, and also to have
backspace go back one search position and/or remove one character from
the search text.
* Multiple top level windows, and able to show any buffer in any TLW,
including those that are already displayed in another TLW. Of course
there should be key-bindings available for opening a new TLW, cycling
forward and backward through the buffer list, and a way to select a
buffer from a popup list of buffer/file names.
* The Kill-Ring. For those of you that have never used an emacs-like
editor it works like this: There is a collection of the N previous
blocks of text that have been cut or copied (in emacs 'cut' == 'kill'
more or less) When I do a yank (paste) it uses the last thing put in
the kill-ring. If I then immediately use another key-binding then it
replaces that pasted text with the next item in the kill ring, and so on
until I eventually wrap around get back to the first one in the ring, or
I do some other command or move the cursor somewhere else.
* Registers. A text snippet can be copied into a register, which is
like the kill ring except you refer to each one by name, where the names
are 'a' through 'z'. You can also append to a register that already has
text in it, and you can paste the contents of a register into the
document at the current cursor location.
* Able to have selections be either a stream of characters or a
rectangle. A stream selection is like what you have in all text
editors, it starts from position a on line N and continues forward or
back to position b on line M and includes all the characters in between.
A rectangle selection is all the characters between position a and b
on lines N to M. In other words, it has width and height and it might
be something like positions 5 through 10 on lines 20 to 25. Cutting or
deleting a rectangle removes the text in the rectangle and shifts any
text to the right of the rectangle over. It does not remove any lines
although they may end up being empty. Pasting a rectangle inserts the
new text with the upper-left of the rectangle at the current cursor
position, shifts existing text to the right if needed, and fills with
spaces on the left if a line affected by the paste is not long enough.
New lines are not added unless the file needs to be extended to
accommodate the rectangle paste. Rectangles can also be put into registers.
* Good keystroke macro recording and the ability to save and load
keystroke macros, and the ability to assign a key-binding to a saved
recorded macro. Any time I need to make the same edits to a bunch of
lines or groups of lines I'll record doing it on the first one including
the keystrokes needed to reposition for the next line, and then stop
recording and then it's just one keystroke to replay the keystrokes for
every other line that needs it done. I record, use and throw away up to
a dozen or so macros per day.
* If you must have a toolbar make it optional and keep it simple.
Toolbars require the mouse and the goal is to keep the hand off the
mouse as much as possible.
* Similarly, avoid using popup dialogs whenever possible. This includes
things like the file dialog. I don't mind seeing the file dialog if I
select a menu item, because most likely my hand is already on the mouse,
but the rest of the time I just want to hit a key, type a path name
(with tab-completion to help find stuff, up/down keys to cycle through
past selections) and press enter. So I would prefer this editor to have
something like emacs' minibuffer, or the QuickFind panel in Firefox. In
other words, when there is something you would normally use a dialog for
just create a small panel that rolls up from the bottom of the frame,
put the keyboard focus there, perhaps do stuff in the main buffer as
they are typing if appropriate, and then when the user is done the panel
rolls out of sight again and keyboard focus is restored to their active
buffer. This can be done for file open/saves, search & replace,
specifying build or grep commands (see next item) choosing to execute
some editor function by name that may not have some key-binding yet (see
item after next) etc.
* Flexible build/grep commands. Emacs handles both of these in almost
the same way so I'll list them together here. I hit a key and am
presented with either the default, or the most recently used compile or
grep command. I can edit the command or use the up/down arrows to
select previous commands that I've used. I then hit enter and emacs
runs the command putting the output in an editor buffer. There is a key
I can hit to kill the compile if needed. It then parses the output and
there is a key I can use to find the file listed in the compile or grep
output, load it, and position the cursor on the reported line. (This
can even be done while the compile/grep is still running.)
* For access to editor commands/functionality that may not be bound to a
keystroke it's real nice to have the ability to hit a key, type the
command name, press enter and then it's done. This can also allow for
commands that might need to prompt for parameters, be interactive, etc.
All editor commands should be named and can be bound to keys by name
or executed by name in this way.
* Regex search. Emacs has support for regular expression search modes
for all of the search types, incremental search, search/replace,
although I don't use it that much.
* Multi-file search and replace. Be able to select files interactively,
or by wildcard, or both. Enter search string, or regex, and replace
text. The editor loads each file and does the search, allowing you to
choose for each one whether to do the replacement, or replace all.
* If it is a full IDE it would be nice to have a way to start just the
code editor portion for quick edits.
Things that would be nice to have, but that I could live without:
* Interactive diffs, merges and applying of patches.
* Able to be a front-end for gdb.
* Able to be a front-end for CVS, SVN, etc.
* Be able to run shell commands, or the shell itself in an editor buffer.
* have a built-in psychotherapist or be able to play towers of hanoi. ;-)
<warning: this message will self destruct in 5 seconds...>
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Dusty Phillips
Write me a decent cross-platform gui toolkit for Python, and I'll do it!
< no time passes>
Damn, you work fast.
---
Seriously, this list is brilliant. Thanks for taking the time to write
it up. I'm puttingt a link to this message in Pallavi's tracker for
whenever I get bored. It may take another 25 years to finish
everything though. *grin*
I'm inspired by the number of things that overlap my own wishes and
that I've found lacking in one or another of the many editors I've
tried. I'm especially touched by the "optional toolbar" request. My
biggest issue with emacs and jEdit (besides LISP and Java) are that
they have features I don't use or need loaded. Good features, sure,
but IMHO, they should not only be optional, they should not even be
loaded into memory if I don't need them. Like toolbars.
To this list: Which of the current Python editors would you say
supports the most of these features already? What about amoung the
current wxPython editors?
Dusty
Ali Afshar
> <fade from dramatic music with a lit fuse running across the screen...>
>
> Hi all,
>
> Kevin O. and I recently discussed in IM about yet another wxPython-based
> code editor and the subject of my Emacs use came up. I've been an Emacs
> user for more than two decades, and it has been a love/hate relationship
> for most of that time (I hate that I love it and I love hating it) but I
> would like to dump it for something else, iff the RIGHT something else
> came along. Part of our discussion centered on the fact that it is not
> just the emacs-style key-bindings that keep me using Emacs (most of the
> key-bindings I use are customized anyway, or I load extensions to add
> CUA key-bindings, etc.) but it is some more fundamental features that I
> use many times every day that keep me there.
PIDA 0.5 embeds Emacs into a graphical IDE, so you get the best of both
worlds. I am a Vim user myself, and won't give that up easily (it also embeds
Vim).
http://pida.co.uk/files/screenshots/pida_0-5-1_16.png
Ali
Rob McMullen
> worlds. I am a Vim user myself, and won't give that up easily (it also embeds
> Vim).
It looked to me that PIDA was very unix/GTK centric. I want an editor
that is cross platform, looking like a native app yet functioning the
same on all platforms. Not to be a wxPython zealot, but that's what I
get for free with wx and scintilla.
Cross platform really is the key for me. Not just usability either,
but configuration as well. Ever tried getting XEmacs/*nix and
XEmacs/win32 to use the same fonts? Totally different processes to
get them to work, and my win32 fonts are still wonky.
That's the problem with embedding a native editor as I see it --
you're still left with the cross platform differences. You could
embed SciTE, I suppose, but then you're left with extending the editor
in C++. Embed Emacs, and you're forced to write elisp to support a
new major mode. If you're a Vim guy, maybe you're all set since
you're really just dealing with a terminal widget. However, Vim is
not for me.
Rob
Edward Ream
1. I spent over a year integrating an emacs-style minibuffer interface and corresponding emacs-style commands into Leo. In the process I found ways to improve emacs's interface a bit.
Leo has most of the features you list. And the reason Leo has those features is that LeoUser, aka B.H, a heavy-duty emacs user, took the trouble to write a plugin to emulate all essential emacs features in Leo. I then spent another year making them a full part of Leo.
2. Leo has several ways of working closely with Emacs, when nothing but the original will do. (And that will *always* be so). There is an emacs plugin that allows seemless switching between Leo and Emacs.
http://webpages.charter.net/edreamleo/plugins.html#xemacs-py
And there is the leoBridge module that allows you to execute Python scripts from emacs **in the Leo context**.
http://webpages.charter.net/edreamleo/emacs.html
3. But compatibility with emacs is hardly enough to displace emacs. Something more is needed, namely the ability to do things that emacs cannot. This Leo provides with its structural orientation.
Robin, do you use Leo? If you don't you might be surprised at how close Leo already is to doing/having what you want. Many of the features you list are present in Leo. True, not all the features are fully 'fledged'. Registers, macros and some search operations come to mind. But there is a reason these features aren't complete: nobody seems to care.
If *you* become a Leo user, and you make a case for adding, say, better macro support, it will go up on the list. Actually, code already exists, and it may even work. You might find it a task of only an hour or two to make it work exactly as you like.
In short, it may be worth your time to look into Leo :-)
Edward
--------------------------------------------------------------------
Edward K. Ream email: edre...@yahoo.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.
wo...@xsteve.at
That looks impressive!!
I am also a hardcore Emacs user. So I won't give up Emacs.
Can you give a short description about how this integration works?
The most interesting points are:
* Can I use the full power of Emacs, or do I loose some functionality?
* What does PIDA offer in additon to the Emacs functionality?
Stefan.
Ali Afshar
Oh, I completely agree, people want different editors on different platforms,
and PIDA is very GTK/*nix centric. In fact, we are missing one really good
cross-platform editing component written in Python that has an API that can
be used from any language with any toolkit on any platform.
In the general scheme of things I imagine PIDA as combiner of other Pyxides
services of which an editor is one. I imagine there will me many such
combiners.
Ali
Ali Afshar
> On Sep 6, 9:14 am, Ali Afshar <aafs...@gmail.com> wrote:
> > On Thursday 06 September 2007 05:22:19 Robin Dunn wrote:
> > > <fade from dramatic music with a lit fuse running across the screen...>
> > >
> > > Hi all,
> > >
> > > Kevin O. and I recently discussed in IM about yet another
> > > wxPython-based code editor and the subject of my Emacs use came up.
> > > I've been an Emacs user for more than two decades, and it has been a
> > > love/hate relationship for most of that time (I hate that I love it and
> > > I love hating it) but I would like to dump it for something else, iff
> > > the RIGHT something else came along. Part of our discussion centered
> > > on the fact that it is not just the emacs-style key-bindings that keep
> > > me using Emacs (most of the key-bindings I use are customized anyway,
> > > or I load extensions to add CUA key-bindings, etc.) but it is some more
> > > fundamental features that I use many times every day that keep me
> > > there.
> >
> > PIDA 0.5 embeds Emacs into a graphical IDE, so you get the best of both
> > worlds. I am a Vim user myself, and won't give that up easily (it also
> > embeds Vim).
> >
> > http://pida.co.uk/files/screenshots/pida_0-5-1_16.png
>
> That looks impressive!!
>
> I am also a hardcore Emacs user. So I won't give up Emacs.
> Can you give a short description about how this integration works?
Hi,
Integration of any editor is of three parts.
1. Commands sent to the editor
2. Events received from the editor
3. UI Embedding
1 & 2 are achieved with the Emacs server with a python-written client.
3 is achieved with patches to Emacs that I am assured will land in trunk one
day (not very reassuring).
Best I can suggest is to check these out:
http://pida.co.uk/trac/browser/trunk/pida/utils/emacs
http://pida.co.uk/trac/browser/trunk/pida/editors/emacs
>
> The most interesting points are:
> * Can I use the full power of Emacs, or do I loose some functionality?
Emacs is embedded entirely untouched. Full Emacs, any plugins, your settings
etc etc.
> * What does PIDA offer in additon to the Emacs functionality?
Essentially, PIDA provides two things:
1. a graphical user interface above and beyond what Emacs provides. As an
example, the PIDA file browser automatically detects version control system
for any directory, and displays files' version control status. So if you
prefer a nice looking file list with coloured files with icons and little "M"
or "D" or whatever then PIDA provides extra functionality.
2. An ability to extend the functionality of the environment using Python and
PIDA's plugin system. And the plugins we have developed.
I admit there is very little gain in absolute functionality, so I offer these
two quotes from Emacs users who have tried PIDA.
"Emacs don't need no stinking PIDA"
(A fair point, you can probably do anything you want in Emacs)
"Well, PIDA doesn't get in my way when I am using Emacs"
(I like that one the best)
Ali
Don Dwiggins
same reason), only better than I'd thought of. Just a few
additions/comments:
> * Incremental search, both forward and reverse, and wrapping around
> after you've reached the end or the beginning of the document. I like
> to have the same key to start the search and also do a search-next
> after you've typed all the characters you are searching for, and also
> to have backspace go back one search position and/or remove one
> character from the search text.
visible matches for the string ... and for extra credit, incremental
regex search.
> * Multiple top level windows, and able to show any buffer in any TLW,
> including those that are already displayed in another TLW. Of course
> there should be key-bindings available for opening a new TLW, cycling
> forward and backward through the buffer list, and a way to select a
> buffer from a popup list of buffer/file names.
It makes it easy to browse the list, mark some of the buffers for
deletion, etc. Particularly useful when you've been doing edits and
searches in many files of a project, and your popup list is getting just
too long.
> * Able to have selections be either a stream of characters or a
> rectangle.
them, it's a great time-saver.
> * If you must have a toolbar make it optional and keep it simple.
> Toolbars require the mouse and the goal is to keep the hand off the
> mouse as much as possible.
pretty common, I guess, but I think worth mentioning.
> * .... So I would prefer this editor to have something like emacs'
> there is something you would normally use a dialog for just create a
> small panel that rolls up from the bottom of the frame, put the
> keyboard focus there, perhaps do stuff in the main buffer as they are
> typing if appropriate, and then when the user is done the panel rolls
> out of sight again and keyboard focus is restored to their active
> buffer. This can be done for file open/saves, search & replace,
> specifying build or grep commands (see next item) choosing to execute
> some editor function by name that may not have some key-binding yet
> (see item after next) etc.
minibuffer is used to do a variety of things. It's way out from most
GUI interface guidelines, but once you're used to it, it really
contributes to usability. (Another example: in the case of a
multi-keystroke command, if you hesitate partway through for a second or
two, the minibuffer echoes what you've typed so far.)
> * For access to editor commands/functionality that may not be bound to
> a keystroke it's real nice to have the ability to hit a key, type the
> command name, press enter and then it's done. This can also allow for
> commands that might need to prompt for parameters, be interactive,
> etc. All editor commands should be named and can be bound to keys by
> name or executed by name in this way.
description of what it does (in a Help Mode buffer, of course). (If you
type the name, it'll show the keys bound to it; if you type a key, it'll
show you the command name.)
> * Regex search. Emacs has support for regular expression search modes
> for all of the search types, incremental search, search/replace,
> although I don't use it that much.
> * Multi-file search and replace. Be able to select files
> interactively, or by wildcard, or both. Enter search string, or
> regex, and replace text. The editor loads each file and does the
> search, allowing you to choose for each one whether to do the
> replacement, or replace all.
incremental multi-file search through a directory hierarchy of source
code. Since I'm maintaining a mixed set of VB, SQL, Python, etc., this
is a very useful feature. (By incremental, I mean that it begins the
search until it finds a match, then opens the file where the match
occured in a buffer with the point at the match; you can look around in
the buffer and edit it as usual. A single keystroke moves to the next
match.)
Finally, look at Emacs' point and mark concept for selection. The
question it addresses is, how do you allow convenient, flexible
selection of chunks of text using only the keyboard?
--
Don Dwiggins
Advanced Publishing Technology
Christopher Barker
Robin Dunn wrote:
> I've been an Emacs
> user for more than two decades,
>... I would like to dump it for something else, iff the RIGHT
something else
> came along.
I'm in exactly the same situation!
My must-have list is almost entirely a subset of Robins, but a few
additional comments:
> it is not
> just the emacs-style key-bindings that keep me using Emacs
My too -- in fact, I don't like, or want to keep using Emacs bindings --
I want the common stuff to match modern standards, and all the other
apps I use (ctrl+[X,C,V] for cut, copy, paste, for instance).
> * Python should be just one of the languages that this editor supports,
key, key key! I spend most of my computing life in a text editor, but
only some of it in Python. I think it's critical that this be the intent
from the beginning of the design process.
Key to this is that (X)Emacs has a very high quality mode for almost
everything you an imagine. IN fact, it's got the best Python mode I"ve
seen in an editor (and the best LaTeX one, and...). Expecting the editor
developers to make all those modes (and make them well) is out of the
question (indeed, one major beef I have with BBEdit on the Mac is that
you can't make your own mode. They have a Python mode, but it just
doesn't handle indentation right -- there was a discussion with the
developers a few years back, and short version of the response was: "you
shouldn't want it to work that way". I don't think any of the developers
are Python users -- so how they heck would they know? -- but I digress)
You don't need to write the modes, just have the infrastructure so that
they can be (easily) written.
So how is this done? it goes a bit beyond plug-ins and lexers. Emacs
uses the the concept of Major and Minor modes. Major modes are things
like Python mode, Plain Text Mode, LaTeX mode, etc. Minor modes are
things like Fill-Paragraph, Word Wrap, etc. Another piece of this is the
key bindings standards -- bindings peculiar to Modes are all proceeded
with a ctrl+C -- that way different modes don't stomp on the core
bindings or each-other. There are also a standardized set for the common
uses: "Comment Text", "Compile", etc.
I'm not sure about the multi-key bindings thing -- but it does have some
nice use in Emacs.
* One key feature that Emacs Does Not have (or I haven't found it) is a
good soft wrap for text -- that is, it wraps in screen, but doesn't
insert and line endings.
> * Incremental search, both forward and reverse,
Easily done with very few keystrokes! Emacs has ctrl+s, then you start
typing what you want to search for. If you hit ctrl+s again, you get the
last thing you searched for.
> * Multiple top level windows, and able to show any buffer in any TLW,
> including those that are already displayed in another TLW.
Yes, Yes, Yes!!!! Multiple views of the same buffer is very useful.
> * Able to have selections be either a stream of characters or a
> rectangle.
another key feature, though I'm not thrilled with how Emacs does it --
at least not visually -- there isn't a rectangular selection that you
can see. -- I also haven't found "copy rectangle", only "cut rectangle",
but that's probably my lack of effort.
> * Similarly, avoid using popup dialogs whenever possible. This includes
> things like the file dialog.
yes, yes, yes -- the Emacs standard is that if use a toolbar button or
menu to ask to open a file -- you get a dialog. If you use the keyboard,
you get a mini-buffer.
* Oh, and about opening files -- the file open (and save as) should
always default to the same dir that the file you are currently working
in is in-- that has a very high probability of being near where you want
to open or save something.
> I don't mind seeing the file dialog if I
> select a menu item,
If the file dialog is completely keyboard controllable -- that's not too
bad.
> All editor commands should be named and can be bound to keys by name or
> executed by name in this way.
This is key -- an extra level between UI action and actual command -- it
makes for better command line use, customization of key bindings, macro
writing, etc.
Along these lines -- the "tab" key should be able to be bound to "Indent
this line properly", rather than "put a tab here", even if "put a tab
here" is defined to use 4 spaces, or whatever. And hitting the delete
key at the end of an indentation should mean "remove one level of
indentation", not "delete a space".
> * If it is a full IDE it would be nice to have a way to start just the
> code editor portion for quick edits.
yup -- an IDE should have a "just edit files" mode. For example, as far
as I can tell, you can't do that at all with Eclipse!
* Brace matching -- not as key for Python, but critical for other languages.
* Platform independent -- I work regularly in Windows, Linux and OS-X --
one major productivity sap is that I don't have the same editor on all
three (yes, I know I can run (X) emacs on all three, but it just doesn't
"feel" right on Windows or OS-X)
Dusty Phillips wrote:
> To this list: Which of the current Python editors would you say
> supports the most of these features already? What about among the
> current wxPython editors?
None close enough for me to get far using them -- the multiple top-level
frames is a must-have for me. Peppy is looking great, but isn't quite
been ready for prime time yet.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Don Dwiggins
>
> * One key feature that Emacs Does Not have (or I haven't found it) is
> a good soft wrap for text -- that is, it wraps in screen, but doesn't
> insert and line endings.
the other hand, it's easy to switch between line wrapping and
truncating. I use both, depending on context.
>
>> * Incremental search, both forward and reverse,
> Easily done with very few keystrokes! Emacs has ctrl+s, then you start
> typing what you want to search for. If you hit ctrl+s again, you get
> the last thing you searched for.
with ctrl_r to search backwards.
One more thing I just thought of: when you open a file, make some
changes, and undo all of them, Emacs marks the buffer "not modified" on
the last undo. I've seen too many editors and word processors that
don't properly keep track of undone changes.
Robin Dunn
> Robin, do you use Leo?
No, it's been a few years since I looked at Leo, it sounds like you've
made a lot of progress with it. I'll find some time to give it another
spin.
Robin Dunn
>> * Able to have selections be either a stream of characters or a
>> rectangle.
>
> another key feature, though I'm not thrilled with how Emacs does it --
> at least not visually -- there isn't a rectangular selection that you
> can see. -- I also haven't found "copy rectangle", only "cut rectangle",
> but that's probably my lack of effort.
I copy the rectangle to a register (C-r-r-register_letter) and then
insert register to paste it (C-r-i-register_letter)
Robin Dunn
> Robin:
>
> Write me a decent cross-platform gui toolkit for Python, and I'll do it!
> < no time passes>
> Damn, you work fast.
I have the Time Machine on loan...
Edward Ream
> I'll find some time to give [Leo]
another spin.
Thanks! Your support would mean a lot.
I'd like to point out how Leo's structural (outline) orientation can be used to extend Leo in a way that can not even be 'thought' in Emacs. This may not be apparent to the newbie.
The rest of this post shows how to support scripting in any language from within Leo. This is a fairly long post--feel free to ignore it :-)
Programmers can extend Leo in many ways, but the easiest way is to create a script button. See
http://webpages.charter.net/edreamleo/scripting.html#creating-script-buttons
for the (somewhat too dry) documentation about script buttons. The Aha behind script buttons is the most brilliant idea ever to appear in the Leo world. I can say this because it wasn't my idea :-)
In effect, a script button 'brings a (Python) script to data'. I put 'Python' in parentheses because we can create script buttons that allow allow scripting in languages other than Python. For example, here is the code needed to script in Tk directly:
s = g.getScript(c,p,forcePythonSentinels=False)
g.es(g.app.root.tk.eval(s))
The first line 'synthesizes' a script from the presently selected node p, in the context of an outline c. The second line pass the script s to the Tk interpreter, and prints the result on Leo's log pane. Please note that the c, g, and p variables are predefined using magic that I need not explain here.
To use this script, create a node in your Leo outline called, say,
@button Run Tk.
This is the node's headline. Put the two lines of code shown above in the body text of the new node.
Now hit the 'Script button' button in Leo's icon area. This will create another icon button called, not surprisingly, 'Run Tk'.
Now here is the cool part. Pressing the button executes the script in the @button node **on whatever part of the outline is presently selected**. This is indeed bringing scripts to data.
For example, suppose we have a node whose headline is 'my first tk script' and whose body text is:
# This is a comment
set x 50
return [expr $x*10]
To execute this script, simply
select the node and press the Run Tk button. 500 appears on the log
pane. If you want the output to go to the console instead, replace g.es by print the script button.
Notes:
- Creating the 'Run Tk' button also creates a command called run-tk. So <alt-x>run-tk<return> will execute this command and <ctrl-p> or <alt-x>repeat-complex-command<return> will repeat this command.
- You can bind <alt-8> to the run-tk command as follows:
@button Run Tk @key=Alt-8
- When loading a .leo file, Leo (or rather Leo's scripting plugin) creates a script button for every @button nodes it finds. The next time you load the file containing the @button Run Tk node Leo will create the script button (and the run-tk command, including key bindings) automatically.
- I said earlier that the line
s = g.getScript(c,p,forcePythonSentinels=False)
synthesizes a script from the presently selected node p. What this means is that scripts need not be confined to a single node. You can organize complex scripts using Leo's tree structure using Leo's @others and noweb markup. This is an extremely powerful feature that again, can not even be conceived in emacs. Many of Leo's plugins started life as such scripts.
In short, script buttons allow you to support scripting in any Language. Just use g.getScript to compose the script, then pass the script to a compiler/interpreter (as emacs does) and print the result. You now have a new command that can be applied to complex scripts in your language of choice.
Edward
--------------------------------------------------------------------Edward K. Ream email: edre...@yahoo.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.
Peter Damoc
rectangle. A stream selection is like what you have in all text
editors, it starts from position a on line N and continues forward or
back to position b on line M and includes all the characters in between.
A rectangle selection is all the characters between position a and b
on lines N to M. In other words, it has width and height and it might
be something like positions 5 through 10 on lines 20 to 25. Cutting or
deleting a rectangle removes the text in the rectangle and shifts any
text to the right of the rectangle over. It does not remove any lines
although they may end up being empty. Pasting a rectangle inserts the
new text with the upper-left of the rectangle at the current cursor
position, shifts existing text to the right if needed, and fills with
spaces on the left if a line affected by the paste is not long enough.
wx.stc.STC_SEL_RECTANGLE
--
There is NO FATE, we are the creators.