Re: Leo must have another lock on the H-bomb

On Wed, Jan 15, 2014 at 6:03 AM, Matt Wilkie wrote: > A required environment variable to enable processing startup scripts seems > like a reasonable precaution. And/or perhaps a command line option? > > leo --autoexec=True %home%\workbook.leo > ​Good idea. But I think the more locks the better

Re: the "sh" subprocess module

On Wed, Jan 15, 2014 at 6:06 AM, Matt Wilkie wrote: > ran across this today, looks interesting (haven't tried it yet): > > *sh (previously pbs > ) is a full-fledged subprocess interface > for Python that allows you to call any progra

Re: the "sh" subprocess module

On Wednesday, January 15, 2014 7:40:14 AM UTC-6, Terry wrote: > > On Wed, 15 Jan 2014 04:06:44 -0800 > Matt Wilkie > wrote: > > > ran across this today, looks interesting (haven't tried it yet): > > It's actually distributed with Leo :-) in either extensions or external. > Correct, but I don'

Re: Leo must have another lock on the H-bomb

On Wednesday, January 15, 2014 6:39:44 AM UTC-6, Edward K. Ream wrote: > > On Wed, Jan 15, 2014 at 6:03 AM, Matt Wilkie wrote: > >> A required environment variable to enable processing startup scripts >> seems like a reasonable precaution. And/or perhaps a command l

Re: @views status report

On Monday, January 13, 2014 11:59:39 AM UTC-6, Edward K. Ream wrote: > > ​​ > ​​ > ​ > On Mon, Jan 13, 2014 at 9:26 AM, Edward K. Ream wrote: > > ​> ​ > All the hard work is complete! > Alas not. Moving existing organizer nodes is turning out to be quite a puzzl

Re: @views status report

On Wednesday, January 15, 2014 11:53:46 AM UTC-6, Edward K. Ream wrote: Theorem: Any position can be moved provided *only* that both p's parent > vnode and p's childIndex are correct... > > Proof: All the "real" work in moving a position happens in the low-level &

Re: @views status report

On Wednesday, January 15, 2014 11:53:46 AM UTC-6, Edward K. Ream wrote: >>> All the hard work is complete! This post will be pre-writing for the theory of operation. The project is, truly, moving ever closer to completion. Earlier last evening I spent several hours improvi

Re: @views status report

​​ ​​ On Thu, Jan 16, 2014 at 3:16 AM, Edward K. Ream wrote: ​> ​ vc.compute_organized_positions can easily compute the unl of where Y will be found. If od.exists, just remove the penultimate part of the unl! ​> ​ This simple change *might* suffice to handle existing organizer nodes. We

Re: Leo must have another lock on the H-bomb

On Wed, Jan 15, 2014 at 5:38 PM, Don Dwiggins wrote: > How about "quarantining" scripts? I did a web search for "python sandbox" > and got several interesting hits. > Unless I am mistaken, Guido has given up on sandboxes. A command-line options seems simpler and safer EKR -- You received thi

Re: @views status report

On Thursday, January 16, 2014 9:58:16 AM UTC-6, Edward K. Ream wrote: Rev 6589 gets a lot closer to success. It passes for a realistic @auto file. The vast majority of the code now works reliably. The present code fails for nested existing organizer nodes. Not a big surprise ;-) The code

Re: How do I learn leo for non-python programming

On Wed, Jan 15, 2014 at 8:07 PM, cafea wrote: > > Is leo capable of handling C++ projects? > ​Certainly. Early versions of Leo were written in Borland C contained in a Leo outline.​ > > I notice that "Leo Cheat Sheet"->"Leo Directives" has an entry > @language c > is that what I'd use, or sho

Re: @views status report

On Mon, Jan 13, 2014 at 9:26 AM, Edward K. Ream wrote: > > A new @headlines node (a child of the @auto-view node for the @auto file) > will contain > ​...pairs of lines, much like @clones:: > > unl: > head: > > The unls in the @headlines node must use stand

Re: @views status report

​​ ​​ ​​ ​​ ​​ ​​ On Thu, Jan 16, 2014 at 10:13 PM, Edward K. Ream wrote: The read code consists of three *completely independent* phases: > > 1. Initing the OrganizerData nodes and other global data > (precompute_all_data & helpers) > 2. Generating the global moved node lis

Re: @views status report

On Friday, January 17, 2014 10:28:07 AM UTC-6, Edward K. Ream wrote: > ​I am going to completely rewrite phase 2... The new phase 2 code will treat all (parent) nodes in the same way. Some more details 1. There is probably no need for the distinction between @existing-organizer: and @organi

Re: @views status report

​​ ​​ ​​ ​​ ​​ ​​ ​​ On Fri, Jan 17, 2014 at 10:28 AM, Edward K. Ream wrote: ​I am writing this in the middle of the night, hoping I can get back to sleep when I'm finished ;-)​​ ​> ​ ​I am going to completely rewrite phase 2. ​Still true, and for the reasons given. However, the det

Re: @views status report

On Saturday, January 18, 2014 1:51:30 AM UTC-6, Edward K. Ream wrote: > ​​I am going to completely rewrite phase 2. Done. > It's much simpler to ground everything in the actual imported nodes, *not* a simulated tree that includes organizer nodes. > Dropping organizer headlines fr

Traveling Monday

I'll be traveling tomorrow. Rebecca's mother is ill, and I'll be spending an unknown amount to time in Naples. I'll have my laptop with me, so I should be able to work on Leo from time to time. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" g

Re: @views status report

On Sunday, January 19, 2014 10:01:30 AM UTC-5, Edward K. Ream wrote: > > On Saturday, January 18, 2014 1:51:30 AM UTC-6, Edward K. Ream wrote: > > > ​​I am going to completely rewrite phase 2. > > Done. > Earlier today I completed the last part of the "hard part&quo

Re: @views, new auto on trunk

On Fri, Jan 24, 2014 at 1:21 PM, Terry Brown wrote: > Hi Edward, twice now it seems your IRC connection has dropped just as I > was commenting on new auto, so I'll post here, you may have seen this. > ​Thanks for all these comments. First, rev. 6602 has new auto enabled on trunk, so people using

Re: @views status report

On Thursday, January 23, 2014 1:10:20 PM UTC-5, Edward K. Ream wrote: > The project now has met its original design goals! > Next up: restoring custom headlines. It's tricky, but nowhere near as tricky as moving nodes. This post documents yesterday's work. It has two par

Re: @views status report

On Sunday, January 26, 2014 5:06:01 PM UTC-5, Kent Tenney wrote: > > >The last part of the new @auto project will be saving and restore uas > from an @uas trees containing one @ua node for every node having an ua. > > So far, the new @auto looks to be concerned with issues I don't encounter, >

Re: @views status report

On Sunday, January 26, 2014 5:43:05 AM UTC-5, Edward K. Ream wrote: > I expect several hours of work remain before the at-file-to-at-auto command works on all of Leo's @file nodes. The last part of the new @auto project will be saving and restore uas from an @uas trees containing one

Re: @views status report

On Monday, January 27, 2014 7:10:24 AM UTC-5, Edward K. Ream wrote:> > I expect several hours of work remain before the at-file-to-at-auto command works on all of Leo's @file nodes. I hit the post button by mistake. Yesterday got bogged down in fixing bugs. At present,

Re: @views status report

Debugging continues. Good, if slow, progress yesterday: 1. cc.strip_sentinels now uses the @file write code to strip sentinels. This is *much* better than using the @auto write code: it guarantees that section references hare handled correctly during the conversion. The alternative would hav

Re: @views status report

On Tuesday, January 28, 2014 9:01:49 AM UTC-5, Edward K. Ream wrote: > Debugging continues. Good, if slow, progress yesterday: Same again yesterday, perhaps in a round-about manner. I spent several hours yesterday afternoon attempting a "complete" documentation of vc.demote,

Re: Blog post: Leo scripting tutorial

On Tue, Jan 28, 2014 at 2:32 PM, Jacob Peck wrote: > Hi all, > > I've written a fairly long-winded Leo scripting intro tutorial on my blog. > It's here: http://blog.suspended-chord.info/2014/01/28/intro-to-leo- > scripting/ > > I've also linked it on the Leoblog. > > Let me know if you have any

Re: @views status report

​​ ​​ ​​ On Wed, Jan 29, 2014 at 8:25 AM, Edward K. Ream wrote: The plan now is straightforward: Ignore the documentation, create minimal > tests that illustrate the bugs, get traces that illustrate the bugs, fix > the bugs ;-) Refactoring code that manipulates the anchors dict may help

Re: @views status report

​On Thursday, January 30, 2014 8:48:41 AM UTC-5, Edward K. Ream wrote: > The plan is this: > > 1. Regularize (by hand) the large test file I have been using, a copy of > leoGlobals.py. This will show what can at-file-to-at-auto can do in the > best case (assuming remaining

Re: @views status report

​​ ​​ On Thu, Jan 30, 2014 at 5:46 PM, Edward K. Ream wrote: > = Summary > > 1. A prepass will probably be needed to ensure that all nodes in the @file > tree have the proper format. > ​In fact, the regularizer prepass will probably be needed whenever writing with new_auto

Re: @views status report

On Friday, January 31, 2014 9:31:49 AM UTC-5, Edward K. Ream wrote: > 1. A prepass will probably be needed to ensure that all nodes in the @file tree have the proper format. Yesterday I created the infrastructure needed to make this happen. Rather than stupidly creating a separate scanner

Re: @views status report

On Saturday, February 1, 2014 8:50:26 AM UTC-5, Edward K. Ream wrote: > Yesterday I became quite concerned about the speed of the new @auto code...vc.compute_all_organized_positions [is] obviously the culprit. Imo, it should be possible to make this code run in 0.1 sec. or less. That'

Re: @auto option request

On Sun, Feb 2, 2014 at 8:50 AM, Kent Tenney wrote: > I would really like to turn off the lines that Leo prepends to the node > body > of @auto files, like: > @language unknown_language > and > @nocolor > > My workflow often involves writing p.b out as a file to be consumed in > various ways, requ

Re: @views status report

On Saturday, February 1, 2014 5:20:47 PM UTC-5, Edward K. Ream wrote: > > > As of rev 6628, vc.compute_all_organized_positions takes 0.02 sec instead > of 5+ seconds , a speedup of more than 200x. All the new code is in > vc.find_position_for_relative_unl..This saves a stupe

Re: @views status report

On Thursday, January 30, 2014 5:46:18 PM UTC-5, Edward K. Ream wrote: Note the date: several days ago. This is an ENB (Engineering Notebook) post: feel free to ignore. Otoh, unlike most of the recent status reports, I would appreciate any comments you may have. > I think @auto sho

Re: @views status report

On Sunday, February 2, 2014 10:50:57 AM UTC-5, Edward K. Ream wrote: > [The is no] reason to create @existing-organizer: nodes for class nodes. This is just wrong. We need all such nodes in order to place other organizers, as a now-passing unit tests now shows. Edward -- You received t

Re: @url, @path, @image: Can we use them without them interfering in our scripts?

On Mon, Feb 3, 2014 at 6:07 AM, Fidel N wrote: ​> ​ I would like to use @image, @path, @url, etc in the following way: ​[snip] ​> ​ So, the idea is to have the possibility to include nodes with directives seamlessly into your scripts, without breaking them, and being able to still use all Leo fun

Re: @auto option request

On Sun, Feb 2, 2014 at 11:02 AM, Fidel N wrote: > Kent, perhaphs you could be getting your nodes text through this command: > > g.getScript(c,p) > ​Yes. I often do this, and it looks like a better suggestion than mine ;-)​ Perhaps there could be a more accessible way of getting a node's true

Re: @views status report

On Sunday, February 2, 2014 10:50:57 AM UTC-5, Edward K. Ream wrote: > Today's work will go back to basics: I'll attempt to fix some failing unit tests. Done. Also, the prepass now correctly reports all nodes that must be "regularized" by splitting body text into sepa

Re: @auto option request

On Mon, Feb 3, 2014 at 8:51 AM, Jacob Peck wrote: On 2/3/2014 8:49 AM, Edward K. Ream wrote: > > > Perhaps there could be a more accessible way of getting a node's true >> text and auto clean, such as c.p.truebody or something like that. >> > > ​Another good i

Re: @auto option request

On Mon, Feb 3, 2014 at 9:18 AM, Kent Tenney wrote: > Does Leo require the @xxx sentinels to appear in the body? > ​No. All but the @ directives may appear in headlines. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe fro

Re: @auto option request

On Mon, Feb 3, 2014 at 8:56 AM, Edward K. Ream wrote: ​> [p.script] is on the list to do today. It's just a few lines of code.​ Done at rev 6636. Here it is:: ​def __get_script(self): p = self return g.getScript(p.v.context,p, useSelectedText=False,

Re: @auto option request

On Mon, Feb 3, 2014 at 10:06 AM, Jacob Peck wrote: I would argue against sentinels, simply because not all users are going to > be using this for python scripts -- for example, you could use this to get > a complex text document that you have broken into pieces -- one where you > would certainly

Re: @url, @path, @image: Can we use them without them interfering in our scripts?

On Mon, Feb 3, 2014 at 11:57 AM, Fidel N wrote: > > What I was trying to ask hehe... is about possibility to make nodes such > as the following: > > ​​ > header: @url My_Url_Name > body: http://www.websitename.com > > > header: @path My_Favourite_Folder > body: path/to/that/folder > > And same

Re: @auto option request

On Mon, Feb 3, 2014 at 11:36 AM, Kent Tenney wrote: > Sorry, I think I muddied the water here. > > > Does Leo require the @xxx sentinels to appear in the body? > > was referring to the lines Leo inserts into @auto file node bodies: > @no-color @language etc > > I was asking if they could be moved

Re: @auto option request

On Monday, February 3, 2014 10:09:35 AM UTC-5, Edward K. Ream wrote: > > > On Mon, Feb 3, 2014 at 10:06 AM, Jacob Peck wrote: > > I would argue against sentinels, simply because not all users are going to >> be using this for python scripts -- for example, you could

Re: @url, @path, @image: Can we use them without them interfering in our scripts?

On Tue, Feb 4, 2014 at 12:57 AM, Fidel N wrote: > Very happy with the directives suggestions you gave me Edward. Im going to > solve this by using those, and its going to be very quick. > ​Glad my suggestions were useful. Please let us know your progress. EKR -- You received this message bec

Re: Impossible to use alt-codes in body editor?

On Tue, Feb 4, 2014 at 12:17 PM, Chris George wrote: > I am using Leo on a Linux box. In web browsers and word processors I can > use the shortcuts to get unicode characters like Δ. (This is created by > holding down Ctrl-Shift, typing the letter u, releasing Ctrl-Shift, typing > the 4 character

Re: @views status report

On Monday, February 3, 2014 8:54:27 AM UTC-5, Edward K. Ream wrote: > A proper (and safe!) prepass will save a *lot* of work for users of the at-file-to-at-auto command. The prepass now kinda works. When it does split nodes, it (mostly?) does so properly. It doesn't split nodes co

I'm back

Rebecca's mother died just before dawn on Thursday, the day I had picked to leave Florida. It was fortunate that I was able to be with Rebecca and her siblings at that time. After a day of puttering around, I'm ready to resume work. Here are my current priorities: 1. Transition to git. 2. Tr

Big problems with @auto

I've been saying that the new @auto project solves a problem that I've been working on for almost 20 years, namely, how to represent structure without using sentinels. Alas, this is only partially true. As explained below, the new @auto project does not solve serious, fundamental problems with

Re: I'm back

On Sat, Feb 8, 2014 at 6:09 AM, Zoom.Quiet wrote: > WoW! > > - but why git? Hg is enough, and pure Python ! > ​Git seems to be the "sexy" way these days. I'm open to discussion. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubs

Re: Big problems with @auto

​​ On Sat, Feb 8, 2014 at 9:47 AM, Kent Tenney wrote: If ONLY there was a way to survey the demands of current and > future Leo users: I think you would find your expectations to be > outliers. Those of us who use and love @auto have no > need for the magic @file offers, we want to edit text with

Re: I'm back

On Sat, Feb 8, 2014 at 7:30 AM, gatesphere wrote: we have a tested transition path from bzr to git: > https://gist.github.com/gatesphere/3705ae43f0327a510e7e > ​Thanks. I'll be working with this next. EKR -- You received this message because you are subscribed to the Google Groups "leo-edit

Re: Big problems with @auto

On Sat, Feb 8, 2014 at 11:28 AM, Fidel N wrote: > > What if every definition were to be included as a new node, using @others > for the code beneath. > ​This makes the fundamental problem worse.​ ​ The fundamental problem isn't that the imported data is wrong, it's that important relationships

Re: Big problems with @auto

On Sat, Feb 8, 2014 at 11:28 AM, Fidel N wrote: > > What if every definition were to be included as a new node, using @others > for the code beneath. > ​On second thought, this could work. It's ugly, but we could define an organizer node that would include leading and trailing definitions. In

Any objections to moving from bzr to git in the next day or so?

Jake has produced a detailed road map for migrating Leo's bzr to git: https://gist.github.com/gatesphere/3705ae43f0327a510e7e Does anyone have any reason why we *shouldn't* do this? Speak up immediately if you do. To do this, we will need to pick a time to freeze all bzr development. I'll an

Re: Big problems with @auto

On Saturday, February 8, 2014 12:29:26 PM UTC-6, Edward K. Ream wrote: > In short, replacing @file with @auto isn't quite dead yet. An Aha: we can get most of the effects of section references simply by creating corresponding *organizer* nodes. This possibility never occurred to m

Comments & problems following the git migration script

I'm doing a trial run through Jake's git migration script at: https://gist.github.com/gatesphere/3705ae43f0327a510e7e 1. You have to install the bzr-fastimport plugin. NP. 2. Attempting: # still in the 'leo-editor' (git) directory $ bzr fast-export --plain ../leo/leo-editor ../leo.fi fa

Moving to git tomorrow

Leo's repo will move to github about this time tomorrow. Please let me know immediately if this is a problem for you. On a fairly fast machine it takes less than 15 minutes to convert the bzr trunk to a git, so problems can be fixed easily enough. Edward -- You received this message because

Re: Big problems with @auto

On Saturday, February 8, 2014 6:42:50 AM UTC-6, Edward K. Ream wrote: I've been saying that the new @auto project solves a problem that I've been > working on for almost 20 years, namely, how to represent structure without > using sentinels. Alas, this is only partially tru

Restarting the vim project

The new @auto project, while now officially back on track, has taken far longer than I ever imagined, and I would like to take a break from it. I would like to restart the vim project now. It might be possible to get it to a usable state in just a week or so. We shall see. Edward -- You rec

The bzr trunk is now frozen at rev 6651

Leo's trunk will be moving to github in the next hour or so. Please do not make any further commits to Leo's bzr trunk. Any commits beyond 6651 will be ignored. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this g

Re: Big problems with @auto

On Tuesday, February 11, 2014 1:20:27 AM UTC-6, nakedmind wrote: > what if the outline structure of an @auto node is saved as attributes of the @auto node. That is, instead of saving the sentinels in the external file (as what @file does), save the sentinel information as attributes of the pa

@file, @shadow and @auto compared

This post attempts to explain, as clearly as possible, the strengths and weaknesses of @file, @shadow and @auto = @file: the platinum standard @file will always be the best alternative in situations in which it can be used. The reason is simple: it preserves all outline data (including clo

The new @auto project is dead

My dominant emotion is relief :-) As my last post shows, @auto, no matter how improved, will not (and can not) replace @file for power, reliability and speed. The @auto project seemed like a good idea at the time, but I have no regrets at killing it. The new @auto code is complex, buggy and in

Re: @file, @shadow and @auto compared

On Tuesday, February 11, 2014 4:41:50 AM UTC-6, Zoom.Quiet wrote: > but through words, look like @auto just base bad name? @auto isn't a great name, but it's not terrible. Having two names for the same code does not seem like a good idea to me. > if one future [feature?] can not significantly

Leo's git repo is ready for testing

git clone https://github.com/leo-editor/leo-editor.git Leo loads successfully from the new repo, so all appears to have worked. Please report any problems immediately. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from t

A practical way to share Leo's outline structure without using sentinels in sccs repos

We *must* have the data in sentinels for robust sharing of outline structure. Here's another way to get that data: 1. We need only a single Leo-centric line for each external file. This would be very similar to a vim-outline line. The line would have the form:: #leo-data This line give

Re: A practical way to share Leo's outline structure without using sentinels in sccs repos

On Tuesday, February 11, 2014 10:16:16 AM UTC-6, Edward K. Ream wrote: > We *must* have the data in sentinels for robust sharing of outline structure. Here's another way to get that data: As I reread this post, I'm not sure that it's clear that the sha-1 key represe

Re: A practical way to share Leo's outline structure without using sentinels in sccs repos

On Tue, Feb 11, 2014 at 10:16 AM, Edward K. Ream wrote: > > The obvious place for the #leo-data line is either the first or last line > of the file, but it could occur anywhere. > ​Hahaha. The line need not appear in the file at all! The sha1 key is computed from the file's co

Re: Leo's git repo is ready for testing

On Tue, Feb 11, 2014 at 7:45 AM, Jacob Peck wrote: Works fabulously for me. I also tested write access for myself by pushing > a .gitignore file (just a copy of .bzrignore). > > Congratulations and well done, Edward! > ​It would not have happened without your clear directions, Jake. EKR -- Y

Re: The new @auto project is dead

On Tue, Feb 11, 2014 at 12:38 PM, Chris George wrote: > > “You never change things by fighting the existing reality. To change > something, build a new model that makes the existing model obsolete.” ― > Richard Buckminster Fuller > > I think that the path to making Leo work well in collaborative

Re: Can't start leo with leo.run() from external script

On Tue, Feb 11, 2014 at 12:48 PM, Rand Batchelder wrote: > I am trying to start leo from ipythonqt per instructions from the web site; > > import leo > leo.run() > ​This works for me, when run from Python 2.7. Another alternative is to use the Leo bridge: http://leoeditor.com/leoBridge.html H

Re: Big problems with @auto

On Wed, Feb 12, 2014 at 2:56 AM, nakedmind wrote: > This is related more on @file than on @auto. Please bear with me if i'm > being too persistent but looking at the outline metadata embedded in an > @file node's external file, it got me thinking if it's possible to store > those sentinels in the

Re: A practical way to share Leo's outline structure without using sentinels in sccs repos

On Tue, Feb 11, 2014 at 11:03 AM, Seth Johnson wrote: > So if someone gets a non-sentinel file from git and changes it -- how > do those changes get processed against the sentinel-ed file and get > posted as a new sentinel file along with a new sha-1? > Changes from non-Leo users must b​e handled

How is the move to git going for you?

I am slowly coming up to speed with git. The workflow isn't smooth yet, but it's improving. Anyone have any problems to report or tips or suggestions to share? Here are a few notes: 1. It seems that we will want a .gitattributes file. It's important that we handle line endings properly: htt

Re: How is the move to git going for you?

On Wed, Feb 12, 2014 at 7:45 AM, Jacob Peck wrote: > On 2/12/2014 8:41 AM, Edward K. Ream wrote: > > 2. Storing credentials avoids having to type passwords: >> https://www.kernel.org/pub/software/scm/git/docs/git- >> credential-store.html >> >> So does

Re: What you see what you get? Also various errors.

On Tue, Jan 21, 2014 at 9:50 AM, Kent Tenney wrote: > Aaargh. > > Yet another set of commands which subvert the > brilliance of tab completion. > > print- > > Now, spend some time trying to decipher which commands are > about listing, which are about rendering/previewing, and which > are actual

Re: spell as you type

On Fri, Jan 17, 2014 at 1:56 PM, Terry Brown wrote: > I added spell as you type: > ​Excellent work. I'll add this to the project notes (the precursor to release notes). Edward​ -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe fro

Re: How is the move to git going for you?

On Wednesday, February 12, 2014 7:41:49 AM UTC-6, Edward K. Ream wrote: Sometime today I'll update Leo's home page to point to the new repo. What about the daily snapshots? Can they capture the git repo? Edward -- You received this message because you are subscribed to the Goo

Re: How is the move to git going for you?

On Wed, Feb 12, 2014 at 8:30 AM, Ville M. Vainio wrote: > "git gui" is a quirky tool that I wouldn't recommend for beginners. I > recommend installing SourceTree if you are on windows or mac: > http://www.sourcetreeapp.com/ > ​Thanks. I'm playing with it now.​ > > Also: I have never heard of

Re: How is the move to git going for you?

On Wed, Feb 12, 2014 at 7:41 AM, Edward K. Ream ​I'll be away most of today. ​ I've been following this thread with interest. Thanks for all your help. ​EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe

Re: How is the move to git going for you?

Should we restrict access to the git repo? Your thoughts, please. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com.

Re: How is the move to git going for you?

On Wednesday, February 12, 2014 7:41:49 AM UTC-6, Edward K. Ream wrote: > > I am slowly coming up to speed with git. > Here are the git-related items on my to-do list for today. 1. Change Leo's web site to refer to git rather than bzr. 2. Add a .gitattributes file to the r

Re: How is the move to git going for you?

On Fri, Feb 14, 2014 at 7:38 AM, Jacob Peck wrote: > On 2/14/2014 7:52 AM, Edward K. Ream wrote: > >> Should we restrict access to the git repo? Your thoughts, please. >> >> Edward >> >> Define 'restrict access'. As it stands now, only those

Warning: dealing with git line endings

I am considering adding a .gitattributes file at the top level of the repo containing:: text eol=lf If I am not mistaken, this forces all line endings to be Linux line endings. Without this setting, reStructuredText and/or Sphinx has trouble with .rst files. However when I did "git add ." I g

Re: Warning: dealing with git line endings

On Fri, Feb 14, 2014 at 9:17 AM, Ville M. Vainio wrote: > Are we positive that we need .gitattributes at all? > ​No. I'm not sure. I'm going to clone a clean copy. Perhaps I did something foolish. ​ > Is there a reason that lines with LF would be converted to CRLF on local > machine? > ​To

Re: SyntaxError: encoding declaration in Unicode string

On Fri, Feb 14, 2014 at 3:35 AM, Fidel N wrote: > Hi: > > Just after updating, Im getting the following error in Leo log, and cant > run my scripts: > > line 1: # -*- coding: utf-8 -*- > > line 2: #@+leo-ver=5 > > exception executing script > > File "", line 0 > > SyntaxError: encoding decl

Re: Errro importing JavaScript file

On Sat, Feb 15, 2014 at 3:19 AM, Reinhard Engel < reinhard.engel...@googlemail.com> wrote: > The following JSLint-perfect JavaScript file will not import into Leo. Any > Ideas? > ​Thanks for this report. Rewriting the JS importer is a top priority for me. I'll start this project today. Edward

Re: How to call leo functions easily

On Fri, Feb 14, 2014 at 1:33 AM, nakedmind wrote: > > I remember there was no clear easy way to reach a desired function >> directly. >> > > I think what is needed is a single command namespace in which all commands > can be accessed. > ​There is such a namespace, namely the dict ​c.commandsDict.

The first fruits of the move to git: anyone can now generate Leo's docs

I am, at last, getting more comfortable with various git work flows. Being able to clone test branches much more quickly than with bzr is a big plus. Recent revs revised .gitignore so that various screen shots are part of each working copy. This, and a change to LeoDocs.leo means that it shoul

A security hole plugged again in mod_scripting.py

Commit 06981... undoes an important security reversion in mod_scripting.py. It re-adds the following check in the ctor of the scriptingController class:: if self.atScriptNodes and c.config.isLocalSetting('scripting-at-script-nodes','bool'): g.es('Security warning! Ignoring...',color='r

ENB: Modest yet important @auto improvements

This is an Engineering Note Book post. It consists of notes to myself. Feel free to ignore. If nothing else, the recent (defunct) @auto project reminded me of some deficiencies in the @auto code. The well-reported bugs in the JavaScript importer are probably the most grievous examples. I h

Re: ENB: Modest yet important @auto improvements

On Mon, Feb 17, 2014 at 6:32 PM, Edward K. Ream wrote: > This is an Engineering Note Book post. It consists of notes to myself. > Feel free to ignore. > ​...​ ​= Handling leading whitespace​ > The present code *assumes* that it knows how to generate the indentation

Re: unadorned node body

On Mon, Feb 17, 2014 at 9:17 AM, Kent Tenney wrote: > maybe add p.raw, or p.plain > ​An interesting idea. I think p.nosentinels would be most descriptive. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and

g.getScript no longer adds a Python encoding line

This turned out to be a bad idea: the encoding line caused all kinds of complications in unexpected places. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email t

Re: unadorned node body

On Mon, Feb 17, 2014 at 9:14 AM, Jacob Peck wrote: > > I think Edward is going to remove the encoding line. In the interim, this > works: > > p.script.split('\n',1)[1] > ​Done at the latest rev. It's not coming back ;-) EKR -- You received this message because you are subscribed to the Goog

Re: unadorned node body

On Tue, Feb 18, 2014 at 4:24 AM, Edward K. Ream wrote: > On Mon, Feb 17, 2014 at 9:17 AM, Kent Tenney wrote: > >> maybe add p.raw, or p.plain >> > > ​An interesting idea. I think p.nosentinels would be most descriptive. > ​Done on the trunk, including a unit tes

Re: unadorned node body

On Tue, Feb 18, 2014 at 5:21 AM, Fidel N wrote: > Hi Edward, thanks for this. > While we are on it, how about a p.something that returns all the stripped > bodies, including the subtree? > similar to g.getScript but already clean? > ​Isn't that what p.script does? Iirc, it has no sentinels. EK

Re: ENB: Modest yet important @auto improvements

On Tue, Feb 18, 2014 at 6:13 AM, Reinhard Engel < reinhard.engel...@googlemail.com> wrote: > >> ​= Handling leading whitespace​ >> ... >> > ​Handling leading indentation correctly leads to unavoidable >> complications​. These won't go away in the new code, but perhaps they will >> be handled

<    1   2   3   4   5   6   7   8   9   10   >