Well this is the first time I am running the files from git repo. In the
past this was never a problem. But now I got the following message from the
github downloaded version:
Traceback (most recent call last):
File launchLeo.py, line 8, in module
leo.core.runLeo.run()
File
I should add that this was an installation on a new computer and I don't
have a global settings file.
On Wednesday, September 17, 2014 7:01:58 PM UTC-7, F.S. wrote:
Well this is the first time I am running the files from git repo. In the
past this was never a problem. But now I got
Hi Terry,
Good to hear from you again. This seems like one tough bug. I dug some more
and found some more threads on this:
https://groups.google.com/forum/#!searchin/leo-editor/F.S./leo-editor/eH5cspNNOD0/SZm95-olO-EJ
https://groups.google.com/forum/#!searchin/leo-editor/F.S./leo-editor
I was away after this thread:
https://groups.google.com/forum/#!searchin/leo-editor/F.S./leo-editor/2XqXrh_2a0c/c-m5t4CxD1IJ
and I came back to this post (also for reporting the same scroll jump
issue). It seems the clock didn't move (for me:-)
I read your post about M-H in the stc group
On Tuesday, March 25, 2014 6:51:04 PM UTC-7, F.S. wrote:
Didn't know that you are (were?) a closet Prolog user. ...
Doh. When I read that:
*Now, this should sound familiar if you've ever used Prolog—you're
essentially computing the proof tree like a human Prolog interpreter
It has been a while :-) This issue seems to have come back (or was it ever
resolved?) as far back as this January. I just downloaded the newest
version and it is still there. It is quite annoying which is why I am
digging up this old thread.
On Thursday, September 27, 2012 11:04:46 AM UTC-7,
It appears that the F-35 program could have benefited from your approach:
http://www.nytimes.com/2012/11/29/us/in-federal-budget-cutting-f-35-fighter-jet-is-at-risk.html?ref=us
They are still pasting paper on a wall to manage the project. Imagine if
the project manager learned to use Leo.
On
, 2012 1:18:30 PM UTC-7, F.S. wrote:
I am thinking a good starting point is to focus on supporting editing of
@auto files in Emacs.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To view this discussion on the web visit
https
On Wednesday, October 17, 2012 5:18:57 AM UTC-7, Edward K. Ream wrote:
On Tue, Oct 9, 2012 at 7:50 PM, F.S. speec...@gmail.com javascript:
wrote:
It is probably not too hard to create an Emacs mode for Leo? With Leo's
core outlining and Python scripting capability integrated with Emacs
I really like @auto. I can just define functions/classes without worrying
about creating nodes for each. But it would be nice to be able to manually
annotate as well. For example to broadly group nodes together or even to
clone nodes. Is there any way to combine the best of both worlds? Ideally
).
On Thursday, October 18, 2012 12:24:50 PM UTC-7, Ville M. Vainio wrote:
For question 2, rclick on the @auto node and choose 'refresh from disk'.
Q1 has been discussed previously, without conclusion to implement the
feature (so far)
On Oct 18, 2012 9:17 PM, F.S. speec...@gmail.com
These are cool questions to ask and get answers on. It would be nice if the
Wiki http://leo.zwiki.org/LeoWiki could be updated with the questions and
answers. At a minimum just create with a headline describing the question
and paste a link to the threads here, so that in the future people can
with Emacs power
in basic editing and countless modes. One can always dream, right?*
On Monday, October 1, 2012 3:50:05 PM UTC-7, F.S. wrote:
As I learn more about Leo my approach will surely evolve along with Leo.
--
You received this message because you are subscribed to the Google Groups
leo
:
On Tue, Oct 2, 2012 at 5:06 PM, F.S. speec...@gmail.com javascript:
wrote:
What I was referring to was that when we eval everything at the top
level of course we break all the module restrictions.
I have no idea what you are worried about.
Let's say we are working on a class/function
The more REPL friendly languages (Common Lisp e.g.) provide a way to switch
the namespace that the interpreter is in at any time. That way the
package/module system no longer hinders REPL.
On Friday, October 5, 2012 9:07:20 AM UTC-7, F.S. wrote:
On Friday, October 5, 2012 5:35:47 AM UTC-7
As of build 5482, dabbrev-completion and dabbrev-expand cause the insertion
point to scroll to the bottom of the body pane. I would also count these
scrolls as unwanted. Interestingly undo restores the scroll position to
exactly before the edit was initiated.
--
You received this message
Running 5481 on file with large nodes. set g.cache_color_info to True;
removed @killcolor, first impression large nodes switching seems sluggish
as ever. But oh wait! There is significant improvement if I come back to a
node that was previously selected. Of course! At first time selection the
Very cool! Default bindings a la Emacs -- as suggested in the source code
nodes! -- would be great. I've copied them out of the (@ignored) emacs key
bindings and put them in myLeoSettings.
On Tuesday, October 2, 2012 8:53:15 AM UTC-7, Edward K. Ream wrote:
On Mon, Oct 1, 2012 at 12:32 AM, F.S
On Tuesday, October 2, 2012 6:18:22 AM UTC-7, Edward K. Ream wrote:
On Mon, Oct 1, 2012 at 5:50 PM, F.S. speec...@gmail.com javascript:
wrote:
c) is the lack of dabbrev support for now. codewise is impressive but
when I
am writing new code dabbrev really makes it easier to use
In Emacs M-/ (dabbrev-expand) just expands to the first choice. You then
cycle through the choices by repeating M-/. If you go too far you can cycle
back with C-/. C-M-/ (dabbrev-completion) expands to the longest common
prefix.
With 5473 I seem to already get the behavior you are talking
AM UTC-7, Edward K. Ream wrote:
On Mon, Oct 1, 2012 at 12:32 AM, F.S. speec...@gmail.com javascript:
wrote:
The answer seems to be no based on the exchange here:
https://groups.google.com/forum/?fromgroups=#!searchin/leo-editor/dabbrev/leo-editor/3A4JOHqhJSU/W1DjTvooNCkJ
Just
, 2012 at 12:44 PM, F.S. speec...@gmail.com javascript:
wrote:
However in
Emacs it is easy to attach arbitrary action to any text through buttons
that
can be placed anywhere in any buffer.
That's what Leo's script buttons do. A script button script could act
on the entire file
All the standard outline operations only work on a single node. How do I
cut, paste, move a group of nodes?
Context: In my mind Leo is perfect for refactoring. So I rewrote a bunch of
functions, and tested that they work so now I am ready to move the original
nodes into a storage node outside
out if group operation is actually doable ... Source code indicates that is
just what is intended. I wonder why: something to do with node caching,
node file correspondence ... ?
On Tuesday, October 2, 2012 5:12:35 PM UTC-7, F.S. wrote:
All the standard outline operations only work
BTW it is great to be able to move codes in logical units. I knew this is a
great way to work with code but actually doing it feels wonderful.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To view this discussion on the web visit
There is a bug in the script:
g.es_print('done: %s formats %s sec' % (n,t2-t2))
is guaranteed to print zero every time :-) Should be t2-t1.
Thanks for the education for us all.
However in terms of importance I would rank dabbrev much ahead of syntax
coloring. My large nodes tend to be very
Here are my current thoughts w.r.t. work flow using Leo:
1) I will most definitely continue using Leo for the things I already use
it for, where it is natural fit.
2) Now that Edward is getting a handle on the scroll issue, I have a better
understanding of the performance issue related to
colorizes the whole new node. This takes time.
On Sep 29, 2012 8:00 PM, F.S. speec...@gmail.com javascript: wrote:
5468 appears to be problem free! Turning off syntax color made switching
large nodes snappy as well.
I would like to understand why syntax color causes such a slow down
On Friday, September 28, 2012 4:40:46 PM UTC-7, Edward K. Ream wrote:
On Thursday, September 27, 2012 6:49:10 PM UTC-5, Edward K. Ream wrote:
I now have a prototype for a more complete solution to the unwanted
scrolling.
Rev 5465 fixes some more scroll-related problems. These were
This was reported to the scroll issues thread already. I added a bit more
details below:
Rev 5465 is fairly unusable.
1) Switching between large nodes takes forever. It used to be snappy.
2) Cursor is no longer visible if I navigate away from a node and then come
back to it. Coming back to a
On Friday, September 28, 2012 11:57:44 PM UTC-7, F.S. wrote:
This was reported to the scroll issues thread already. I added a bit more
details below:
Rev 5465 is fairly unusable.
1) Switching between large nodes takes forever. It used to be snappy.
Okay. I was wrong about the snappy
files, yet one is able to
navigate around the nodes without effort.
On Saturday, September 29, 2012 12:16:33 AM UTC-7, F.S. wrote:
On Friday, September 28, 2012 11:57:44 PM UTC-7, F.S. wrote:
This was reported to the scroll issues thread already. I added a bit more
details below:
Rev 5465
, 2012 5:30:43 AM UTC-7, Edward K. Ream wrote:
On Wed, Sep 26, 2012 at 12:25 AM, F.S. speec...@gmail.com javascript:
wrote:
I just noticed that after some usage the background color of the body
pane
turns from the default pink to yellow (the default color of outline
pane).
...this might
This does not apply to Linux but on Windows if your installation path has
space, you need to quote the executable string. The following would work:
@string vim_cmd = c:\Program Files (x86)\Vim\vim73\gvim --servername LEO
@string vim_exe = c:\Program Files (x86)\Vim\vim73\gvim
The example given
I don't think there is a key or mouse binding for vim now. You need to
alt-x vim-open-node.
Also make sure that vim,py is turned on in @enabled-plugins. You should see
it listed in the plugins menu.
On Tuesday, September 18, 2012 5:05:31 PM UTC-7, Joon Ro wrote:
Thanks for the reply. So in
with the out-of-box leoSettings.
On Monday, September 24, 2012 1:48:19 PM UTC-7, Terry wrote:
On Mon, 24 Sep 2012 11:47:45 -0700 (PDT)
F.S. ██@ wrote:
The scroll issue was getting unbearable for me so I tried switching back
to
older versions. As of Leo 4.8 final the scroll
That is very good news! I will definitely give clone-find-all a try.
I have some other issues and questions in general and I will ask them in
separate threads.
On Tuesday, September 25, 2012 1:52:23 PM UTC-7, Edward K. Ream wrote:
On Tue, Sep 25, 2012 at 11:28 AM, F.S. speec...@gmail.com
1. The find panel does not work. As I was tracking down the first
appearance of the scroll bug by trying all revisions of Leo I noticed that
the find panel hasn't worked for a very long while. It works in 4.8 but
soon after that no text can be entered into the find panel. Minibuffer find
I have used Leo for a long time but I probably only use 1% of Leo features
:-) I have been using it to do book keeping in Python. I created some
simple classes and as things happen I add instances to record the new
events. I use the outline to organize these by time periods. I write Python
window, or sometimes after scrolling.
The two colors are close anyway so no big deal. Just thought this might be
a side effect of a stylesheet lockout and thought you may be interested in
knowing.
I suspect that the latest code is at least as good as the Leo 4.8 code
base. F.S., I hope you
I found Terry's answer to an earlier post that explains the vr pane
commands:
https://groups.google.com/forum/?fromgroups=#!searchin/leo-editor/hide$20rendered/leo-editor/NtmvVym1RKY/3_h9Ej3YPIsJ
That answers the second part of #3.
On Tuesday, September 25, 2012 4:02:08 PM UTC-7, F.S. wrote
This one is also a FAQ, answered here by Edward:
https://groups.google.com/forum/?fromgroups=#!searchin/leo-editor/find$20tab$20not$20working/leo-editor/DL9T057UyCo/JX9aDt9j46gJ
On Tuesday, September 25, 2012 4:02:08 PM UTC-7, F.S. wrote:
1. The find panel does not work. As I was tracking
:02:08 PM UTC-7, F.S. wrote:
3. I used apropos-find-commands and my body pane split into two windows
with the help content in the right window. Firstly all the help texts are
in one long string with no proper line breaks (Windows line separator
issue?). Secondly I couldn't figure out how
The scroll issue was getting unbearable for me so I tried switching back to
older versions. As of Leo 4.8 final the scroll issue is not present but it
is in Leo 4.9. So for now I will be using Leo 4.8 instead. I back ported
Terry Brown's fix to qt log printing and so far I am happy with 4.8.
experimental code. Fortunately, only a few methods were changed.
I will have to leave the heavy lifting to Ed and you.
On Monday, September 24, 2012 1:48:19 PM UTC-7, Terry wrote:
On Mon, 24 Sep 2012 11:47:45 -0700 (PDT)
F.S. ██@ wrote:
The scroll issue was getting
resolution would affect the line height etc. I do
remember that resizing the body text pane does not change things.
On Tuesday, August 14, 2012 12:19:31 PM UTC-7, Terry wrote:
On Tue, 14 Aug 2012 11:42:27 -0700 (PDT)
F.S. ██@ wrote:
I tried the new build (rev 5423
wrote:
On Tue, 17 Jul 2012 10:49:11 -0700 (PDT)
F.S. wrote:
Now sub node 8 has grown to over 422 lines and it now always jumps to
line
422 as the last line. The increment with the last jump threshold is 24
lines. Not sure what is magic about 24? My edit panel is sized to
display
displayed.
On Wednesday, July 4, 2012 8:27:26 AM UTC-7, F.S. wrote:
Here are some of the details of the scroll jumping issue I noticed. It
very reliably occurs on a large file node of mine. The workbook was until
days ago edited using 4.7 and I just switched to 4.10 and now 4.11. I have
Snapshot 20120704 fixed the printing issuing. Thanks Terry!
I will report more details on the scroll jumping issue in a new post.
On Tuesday, July 3, 2012 11:11:40 AM UTC-7, F.S. wrote:
I downloaded the 20120703 snapshot from the website. Your fix didn't seem
to make into it. I will try
to additionally do File-Open to open the file I wanted. In 4.7 I
was able to double click and open a file.
Thanks for any help,
F.S.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To view this discussion on the web visit
https://groups.google.com/d
.
On Tuesday, July 3, 2012 5:03:34 AM UTC-7, Terry wrote:
On Mon, 2 Jul 2012 22:13:36 -0700 (PDT)
F.S. speech.f...@gmail.com wrote:
Also in 4.7 the log pane used monospace fonts so one can print out a
table
nicely using Python print formatting but in 4.10 the log pane seems to
default
, Service Pack 1
On Tuesday, July 3, 2012 5:47:53 AM UTC-7, Terry wrote:
On Mon, 2 Jul 2012 22:13:36 -0700 (PDT)
F.S. speech.f...@gmail.com wrote:
I seem to be getting line breaks inserted after each item in the print
statement: that is print a, b, c would insert line breaks after a and
b
52 matches
Mail list logo
