Yesterday morning, and again last night, the solutions to several long-
standing questions became apparent. The solutions are simple and
unforgettable.
The train of thought that lead to the Ahas has something to do with a
chance remark made by somebody recently, I don't know who or in what
This may have more practical significance than today's Eurekas. Or
not.
A frequently requested feature is the ability to put @ignore trees in
@file trees. In the past, I have always responded that this is not
possible: each external file must contain all information in the files
@file tree.
On Mar 2, 9:04 am, Edward K. Ream edream...@gmail.com wrote:
This might be an example of a beautiful theory being killed by an ugly
fact. However, I'm not ready to give up on tag files just yet ;-)
Creating a global repository for all nodes does not in any way solve
this problem. Indeed, the
On Fri, Mar 2, 2012 at 10:04 AM, Edward K. Ream edream...@gmail.com wrote:
= The synchronization problem
There is a potentially fatal problem with this scheme. Any time *any*
data is composed from multiple sources, the question arises,
what happens if the two sources get out of
On Fri, Mar 2, 2012 at 10:15 AM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Mar 2, 2012 at 10:04 AM, Edward K. Ream edream...@gmail.com wrote:
= The synchronization problem
There is a potentially fatal problem with this scheme. Any time *any*
data is composed from multiple
This got me quite excited, because half way in I realized (my understanding
of) this ties in very closely to an aha experience I had using TiddlyWiki's
TagglyTagging - I'll try not to dwell on specific implementation details,
just wanted to set a context on which to hang these somewhat abstract
I was thinking that this might have an application to a recent request
of mine to add the ability of interposing test nodes, (that end up in
a test file), with code that ends up in a code file.
Rather than expanding the @file directive to take two file arguments,
have two separate @file
On Friday, March 2, 2012 8:05:53 AM UTC+2, tfer wrote:
Anyone else having problems with Launchpad?
IIRC there was a thread about this some time ago, but it was related only
to memory problems when running bzr in Windows. Just did a test branch from
launchpad:
$ time bzr branch
Standing at the sink doing dishes, a bzr error message suddenly
flashed into consciousness::
bzr: ERROR: Working tree C:/leo.repo/trunk/ has uncommitted
changes
Use --no-strict to force the push
I have just updated my bazaar.conf file so that bzr push gets
translated automatically to bzr
On Mar 2, 9:04 am, Edward K. Ream edream...@gmail.com wrote:
= The synchronization problem
...
This might be an example of a beautiful theory being killed by an ugly fact.
As discussed in the thread: OMG! Synchronization is not a problem! I
have been worried about something that is
On Fri, Mar 2, 2012 at 10:05 AM, tfer tfethers...@aol.com wrote:
I was thinking that this might have an application to a recent request
of mine to add the ability of interposing test nodes, (that end up in
a test file), with code that ends up in a code file.
Yes. I guess my subconscious
[ ktenney@lappy: ~/work ]$ Traceback (most recent call last):
File /usr/fetching/leo-editor/leo/plugins/contextmenu.py, line
211, in editnode_rclick_cb
c.openWith(data = ('subprocess.Popen', [editor], None))
TypeError: openWith() got an unexpected keyword argument 'data'
Thanks,
Kent
--
On Sat, 25 Feb 2012 22:15:01 -0800 (PST)
HansBKK hans...@gmail.com wrote:
I've been coming across a few anomalies lately, but haven't reported them
since I've held off updating since mid-January or so, due to the major
reworking going on lately and their attendant cautionary postings here,
On Fri, Mar 2, 2012 at 2:01 PM, Kent Tenney kten...@gmail.com wrote:
[ ktenney@lappy: ~/work ]$ Traceback (most recent call last):
File /usr/fetching/leo-editor/leo/plugins/contextmenu.py, line
211, in editnode_rclick_cb
c.openWith(data = ('subprocess.Popen', [editor], None))
TypeError:
I guess the executive summary is that this is akin to googling over
your leo document. I also have some preliminary plans to add full text
search, so you could search foo bar baz, and it would score the
nodes along the lines of how good the hit is (where words can appear
anywhere in a node).
On
On Fri, Mar 2, 2012 at 3:54 PM, Edward K. Ream edream...@gmail.com wrote:
Oops. I forgot to change the calls in leoPlugins.leo. I'll fix this
immediately.
Done at rev 5058.
I tested the code by getting the vim and xemacs plugins to work. That
was successful, but apparently the contextmenu
Dang, I'd bound leo to trunk, I see that the head is now trunk3, no
wonder I wasn't able to pull latest.
On Mar 2, 1:05 am, tfer tfethers...@aol.com wrote:
So I tried a checkout instead of branch, seemed to work but got:
Working tree is up to date at revision 4935.
That is not the latest
Yes, contextmenu has the functionality that polls the files for changes. I
don't see this as a problem - contextmenu can just be considered mandatory
dependency.
Is there a sane reason why someone would not be using the plugin?
On Mar 3, 2012 1:16 AM, Edward K. Ream edream...@gmail.com wrote:
18 matches
Mail list logo
