Robin Dunn's mission
29 views
Skip to first unread message
Edward K. Ream
Feb 2, 2009, 9:41:57 AM2/2/09
to leo-editor
This thread will discuss Robin Dunn's post, "Your mission, should you
choose to accept it". I'll be discussion how Leo complies with
Robin's checklist, and how Leo goes beyond it.
Robin's post has been subtly driving Leo's development for a long
time. I consider it to be extremely important for Leo.
To find the original, go to http://pyxides.stani.be/ and search for
"your mission".
There doesn't seem to be a way to link directly to Robin's post, so
here it is in its entirety. I'll post my thoughts in responses to
this post.
QQQQQQ
<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.
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 tha 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!
QQQQQQ
Edward
choose to accept it". I'll be discussion how Leo complies with
Robin's checklist, and how Leo goes beyond it.
Robin's post has been subtly driving Leo's development for a long
time. I consider it to be extremely important for Leo.
To find the original, go to http://pyxides.stani.be/ and search for
"your mission".
There doesn't seem to be a way to link directly to Robin's post, so
here it is in its entirety. I'll post my thoughts in responses to
this post.
QQQQQQ
<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.
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 tha 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!
QQQQQQ
Edward
Edward K. Ream
Feb 2, 2009, 9:50:00 AM2/2/09
to leo-editor
On Feb 2, 8:41 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> This thread will discuss Robin Dunn's post, "Your mission, should you
> choose to accept it"...I'll post my thoughts in responses to
> This thread will discuss Robin Dunn's post, "Your mission, should you
> this post.
Here is my present view about how Leo accomplishes this mission:
===== Mission accomplished
* Python should be just one of the languages that this editor
supports, not the primary target.
* Absolutely every feature or action must be able to be done with just
the keyboard.
the keyboard.
* Multiple top level windows, and able to show any buffer in any TLW,
including those that are already displayed in another TLW.
Comment: Leo goes *way* beyond this.
including those that are already displayed in another TLW.
* Registers.
* A rectangle selection and paste.
* Regex search.
* 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.
* If you must have a toolbar make it optional and keep it simple.
mouse" is incorrect. Toolbar items can easily create minibuffer
commands.
* Avoid using popup dialogs whenever possible.
* So I would prefer this editor to have something like emacs'
minibuffer.
* 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.
* If it is a full IDE it would be nice to have a way to start just the
code editor portion for quick edits.
code editor portion for quick edits.
* 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. ;-)
===== Maybe done.
* 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. ;-)
* The Kill-Ring.
Comment: lightly used. Could be improved.
* Typing completion for file dialogs.
Comment: lightly used, because @file nodes reduce the need for this.
===== Not done.
* Incremental search, both forward and reverse, and wrapping around
after you've reached the end or the beginning of the document.
* [Added by EKR] typing completion for Leo itself works well enough,
and it will be further improved this year.
==== Not done, but could be done in @command easily enough
* Flexible build/grep commands.
* Multi-file search and replace.
* Interactive diffs, merges and applying of patches.
Edward
jkn
Feb 2, 2009, 10:09:57 AM2/2/09
to leo-editor
This is probably rather a jump, but never mind...
The text editor I have most fondness of is Brief, which ran under DOS.
It was sold to Borland, who later killed it off.
When MS-windows came along, Premia Codewright was a very capable
editor which used the Brief API ... until Premia sold it to Borland,
who killed it off ;-(
For programming, I currently use CRiSP, which has been around for a
very long time. It started life as a shareware version of Brief, but
is nowadays a licensed product runs under many GUI operating systems.
CRiSP is *extremely* configurable, in a similar way to emacs, but IMO
does this much more elegantly. Partly this is because it is mainly
written by one person. It has a macro programming language, similar to
C but with added data types (strings, dictionaries, dynamic
arrays...). It happens to be compiled down to a lisp-like virtual
machine, but that is not relevant here.
The CRiSP macro language allows creation of key mappings, dialogs, and
all sorts of things I won't go into here. My main reason for posting
this is to point you at the primitive API. As I mention, this is based
on the original BRief API, which was very elegant. you could push()
and pop() a keyboard mapping, which allowed you to map things
temporarily, for instance. Also, the naming was very consistent;
inq_xxx() and set_xxx() were used to inquire and set, respectively,
various parameters, etc. etc.
This:
http://www.infoload.net/CRiSP/user.pdf
is a pdf of the CRiSP macro primitives guide (note: the PDF has
'bookmark not defined' errors). I think it is worth looking at if only
to see the API of an extremely mature and capable editor.
Cheers
Jon N
The text editor I have most fondness of is Brief, which ran under DOS.
It was sold to Borland, who later killed it off.
When MS-windows came along, Premia Codewright was a very capable
editor which used the Brief API ... until Premia sold it to Borland,
who killed it off ;-(
For programming, I currently use CRiSP, which has been around for a
very long time. It started life as a shareware version of Brief, but
is nowadays a licensed product runs under many GUI operating systems.
CRiSP is *extremely* configurable, in a similar way to emacs, but IMO
does this much more elegantly. Partly this is because it is mainly
written by one person. It has a macro programming language, similar to
C but with added data types (strings, dictionaries, dynamic
arrays...). It happens to be compiled down to a lisp-like virtual
machine, but that is not relevant here.
The CRiSP macro language allows creation of key mappings, dialogs, and
all sorts of things I won't go into here. My main reason for posting
this is to point you at the primitive API. As I mention, this is based
on the original BRief API, which was very elegant. you could push()
and pop() a keyboard mapping, which allowed you to map things
temporarily, for instance. Also, the naming was very consistent;
inq_xxx() and set_xxx() were used to inquire and set, respectively,
various parameters, etc. etc.
This:
http://www.infoload.net/CRiSP/user.pdf
is a pdf of the CRiSP macro primitives guide (note: the PDF has
'bookmark not defined' errors). I think it is worth looking at if only
to see the API of an extremely mature and capable editor.
Cheers
Jon N
Edward K. Ream
Feb 2, 2009, 10:22:50 AM2/2/09
to leo-editor
> This thread will discuss Robin Dunn's post, "Your mission, should you
> choose to accept it". I'll be discussion how Leo complies with
> Robin's checklist, and how Leo goes beyond it.
In this "reply" I'd like to discuss some issues that aren't covered in
> choose to accept it". I'll be discussion how Leo complies with
> Robin's checklist, and how Leo goes beyond it.
Robin's post. You could call these the dogs that aren't barking.
I'll link to this post from pyxides as a kind of progress report for
Robin.
1. First, and most importantly, for an editor to displace Emacs, it is
not *nearly* good enough simply to meet all the conditions of Robin's
checklist. If all you want is the checklist, then why not just use
Emacs?
No. If Leo (or any other editor) is to displace Emacs, it must be
much *better* than Emacs at one or more essential tasks.
Without any doubt whatever, Leo meets this requirement. Leo's dom
(document object model) is something that Emacs lacks. Leo's nodes
have rich, true structure. Emacs buffers have no inherently
relationship with other buffers. This is a crucial, *huge* difference
between Emacs and Leo.
Furthermore, Leo is easily scriptable (in Python) in ways that Emacs
users can only dream about. You want the currently selected node?
It's c.p. You want the body text of that node? It's c.p.b. Want to
set the headline text of a node p? p.h = s. Etc. etc. etc.
@button and @test are two features that in essence can not even be
"thought" in Emacs. These features depend on the intimate connection
between nodes (outline structure) and scripting.
These features are not conceivable in Emacs. Oh sure, one could create
some kind of kludgy simulation in Emacs, but that would be like
simulating Python in machine language. It isn't going to be a good
foundation for breakthroughs in programming. Leo is that foundation.
2. Second, Leo already has very good integration with both Emacs
(XEmacs) and vim. So *even if* Leo lacks some esoteric Emacs feature,
it is easy to drop into Emacs to do something, and come right back to
Leo.
3. Third, the reason some of the items on Robin's list are week in Leo
is because nobody uses them in Leo :-) For example, nobody cares about
typing completion for file names in Leo's minibuffer because @thin or
@button are far easier ways to open files.
For more than seven years how I have been responding to requests from
Leo's users. What has gotten done are what people have actually
wanted, and almost nothing else. I plan to continue this strategy.
OTOH, if Robin started using Leo and made requests, I would certainly
listen very carefully :-)
4. There *are* a few features on Robin's list that need some more
work. These include incremental search and a few emacs-like commands
that only work when using the tk gui. I plan to work on these this
week. Also, more work is planned on auto-completion later this year.
5. There are at least two other areas in which Leo is moving far
beyond Emacs.
- Leo's core can support multiple gui's. Leo started out being tk-
centric. Leo now can choose between either tk and Qt for its look and
feel. A swing (jython) version of Leo may happen this year.
- Leo can support either Emacs-style key bindings or vim-like key
bindings. Several of Leo's users are "native" vim users, and they
have improved Leo's vim-like capabilities immensely. More work is
planned in this area later this year.
In short, a case can be made that Leo already meets Robin's essential
requirements. I'll be working on a few loose ends this week, but they
are nits. For several years now, Leo has moved far beyond Emacs in
essential capabilities.
Edward
Edward K. Ream
Feb 2, 2009, 10:43:37 AM2/2/09
to leo-editor
On Feb 2, 9:09 am, jkn <jkn...@nicorp.f9.co.uk> wrote:
> This is probably rather a jump, but never mind...
on vim improvements.
> http://www.infoload.net/CRiSP/user.pdf
Edward
Baxissimo
Feb 2, 2009, 3:36:27 PM2/2/09
to leo-editor
On Feb 2, 11:50 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> * If you must have a toolbar make it optional and keep it simple.
>
> Comment: Leo shows that Robin's assertion that "Toolbars require the
> mouse" is incorrect. Toolbar items can easily create minibuffer
> commands.
I don't get it, if you're saying you click on the toolbar item to
> * If you must have a toolbar make it optional and keep it simple.
>
> Comment: Leo shows that Robin's assertion that "Toolbars require the
> mouse" is incorrect. Toolbar items can easily create minibuffer
> commands.
start up the minibuffer command, then you have indeed used the mouse,
and Robin is still correct.
If you are saying the toolbar commands can be invoked without using
the mouse, then the toolbar isn't really offering any vital service
there other than just advertising the availability of a keyboard
command. In which case it's really the keyboard command you used not
the toolbar, so Robin is still correct. And in this case the toolbar
is just sitting there eating up valuable screen real estate. So
Robin's still correct.
Emacs has a toolbar too, and like everything in Emacs all the buttons
correspond to existing keyboard commands. If you know the commands
then the toolbar is just a waste of space. I think this is the point-
of-view Robin's comment is coming from.
> * have a built-in psychotherapist or be able to play towers of
> hanoi. ;-)
priorities seem a little inverted there. Maybe it was just trivially
simple to get those working... hoping so at least.
--bb
Edward K. Ream
Feb 3, 2009, 5:32:23 AM2/3/09
to leo-e...@googlegroups.com
--------------------------------------------------------------------
Edward K. Ream email: edre...@gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Edward K. Ream
Feb 3, 2009, 5:46:39 AM2/3/09
to leo-e...@googlegroups.com
On Mon, Feb 2, 2009 at 2:36 PM, Baxissimo <wba...@gmail.com> wrote:
I don't get it, if you're saying you click on the toolbar item to
On Feb 2, 11:50 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> * If you must have a toolbar make it optional and keep it simple.
>
> Comment: Leo shows that Robin's assertion that "Toolbars require the
> mouse" is incorrect. Toolbar items can easily create minibuffer
> commands.
start up the minibuffer command, then you have indeed used the mouse,
and Robin is still correct.
As you say, toolbars in Emacs do not require the mouse, and neither does Leo. If you don't like "wasting" screen real estate with hints, then you can use Leo's @command nodes instead of @button nodes.
Leo works like Emacs in this regard, except that creating @button nodes and @command nodes is dead easy, and these nodes contain python scripts instead of elisp.
Edward
Reply all
Reply to author
Forward
0 new messages