On Tue, Apr 8, 2008 at 8:09 AM, bobjack [EMAIL PROTECTED] wrote:
Uhm... This looks more complicated than I thought. All the more reason
to encapsulate it and hide the details from plugins and scripts I suppose
...
Am I right in thinking
a) that stuff put on tnodes appears on all clones and
On Apr 3, 11:11 am, Edward K. Ream [EMAIL PROTECTED] wrote:
I am starting to understand the true advantage of bzr, namely that
it's possible to work on several projects simultaneously in different
branches. [snip]
At present there are three main branches: trunk, stable and ekr-devel.
I've
On Apr 8, 9:51 am, Edward K. Ream [EMAIL PROTECTED] wrote:
The question is, what does this mean :-) I think the short answer is that
the present scheme, involving descendentTnodeUnknownAttributes, does not
allow information contained in vnodes in @thin trees to be saved. However,
a plugin
On Apr 7, 4:01 am, bobjack [EMAIL PROTECTED] wrote:
It does not work for me. It is counting the matches in the minibuffer
text widget not the body.
The fix is now on the trunk. You were correct about the editWidget
method: it now never returns the minibuffer widget, and defaults to
the body
On Apr 7, 7:40 am, bobjack [EMAIL PROTECTED] wrote:
find-word
[snip]
goto-character
The fixes are on the trunk. Again, the change to the editWidget
method means that these commands can not be applied to text in the
minibuffer.
find-word is such a useful command that I added a variant:
On Apr 7, 10:56 am, Steve Zatz [EMAIL PROTECTED] wrote:
home = os.getenv('HOME',default=None)
Thanks. That does help.
I am no Windows expert but I suspect that on many Windows systems, it
is HOMEPATH and HOMEDRIVE that are available and that the HOME
environment variable is not set and
On Apr 8, 9:35 am, Edward K. Ream [EMAIL PROTECTED] wrote:
The fix is now on the trunk. You were correct about the editWidget
method: it now never returns the minibuffer widget, and defaults to
the body pane. A side effect of this change is that no editing
commands can be used in the
On Apr 6, 6:33 am, bobjack [EMAIL PROTECTED] wrote:
Trying to edit the minibuffer, when I backspace to a character and
press delete the cursor moves to the end of the buffer and deletes the
last character instead.
A small joke: this disappears after the recent change to
On Apr 8, 11:00 am, Edward K. Ream [EMAIL PROTECTED] wrote:
trying to make sense of when focus really belongs in the minibuffer
might make my head explode...
Happily, Leo has excellent tracing facilities, as you can see by
setting:
@bool trace_masterCommand = True
@bool
On Apr 8, 11:00 am, Edward K. Ream [EMAIL PROTECTED] wrote:
A small joke: this disappears after the recent change to
leoEditCommands.editWidget because the left and right arrow keys are
pretty messed up. I'll be noodling over this for awhile. I don't
want to break all the edit commands by
On Apr 8, 11:14 am, Edward K. Ream [EMAIL PROTECTED] wrote:
One possibility: define a set of minibuffer-specific commands,
corresponding to the commands in
@shortcuts Minibuffer commands/bindings
in leoSettings.leo.
Another possibility is to make cursor movement commands smarter. They
On Apr 8, 1:47 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
I'll push the code to the trunk after I use it for several hours. All unit
tests pass.
Still to do: the original bug that started this thread :-) I have
hopes now...
Edward
--~--~-~--~~~---~--~~
You
On Apr 8, 1:52 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
Still to do: the original bug that started this thread :-) I have
hopes now...
Ah. This is a problem with the find-completion feature. Totally
different code, probably, which in this case makes the fix easier...
Edward
On Apr 8, 11:22 am, Edward K. Ream [EMAIL PROTECTED] wrote:
Another possibility is to make cursor movement commands smarter. They
would tell editCommands.editWidget to return the minibuffer if focus
is already there.
This was surprisingly easy. There is now a set of commands that can
be
Edward, I want to make you aware of some work that I have done to
improve (imo) the use of Vim with Leo. It may be of interest to you
as you consider the scope of your work on providing Vi support within
Leo. With some modifications to the Open With plugin, I have
implemented support for the
TL wrote:
These changes have given me a very usable Vi capability that works
well with Leo. As a result, it is not as important to me that Leo
have a full featured Vi editor emulated. Now that 4.4.8 has been
released, do you have time to take a look at the changes and, perhaps,
mainline
TL [EMAIL PROTECTED] wrote:
These changes have given me a very usable Vi capability that works
well with Leo. As a result, it is not as important to me that Leo
have a full featured Vi editor emulated.
I am sceptical about implementing Vim features in Leo--there are too
many of them. Would
vpe wrote:
Would it be possible to use gVim as a Leo GUI?
That's what I think TL is saying here:, sing the tab feature within Vim
results in each node, opened by Leo
in Vim,
John G
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
The term use gVim as a Leo GUI implies that gVim emulates Leo's
functionality. I did not implement this. I enhanced the existing
Open With plugin such that a node sent from Leo to gVim opens a new
tab instead of replacing the previously sent node. This allows
multiple nodes to be sent over to
19 matches
Mail list logo
