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" wrote:
> On Fri, Mar 2, 201
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 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 rev, something is
On Fri, Mar 2, 2012 at 3:54 PM, Edward K. Ream 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 plugin is now requ
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).
O
On Fri, Mar 2, 2012 at 2:01 PM, Kent Tenney 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: openWith()
On Sat, 25 Feb 2012 22:15:01 -0800 (PST)
HansBKK 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, and
> the fact
[ 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 Fri, Mar 2, 2012 at 10:05 AM, tfer 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 turned your idea into
On Mar 2, 9:04 am, "Edward K. Ream" 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 easily preventable.
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
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 lp:le
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 statements
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
On Fri, Mar 2, 2012 at 10:15 AM, Seth Johnson wrote:
> On Fri, Mar 2, 2012 at 10:04 AM, Edward K. Ream 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,
>>
>>
On Fri, Mar 2, 2012 at 10:04 AM, Edward K. Ream 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 synch?
>
> For exam
On Mar 2, 9:04 am, "Edward K. Ream" 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 problem becomes,
This may have more practical significance than today's Eurekas. Or
not.
A frequently requested feature is the ability to put @ignore trees in
@ trees. In the past, I have always responded that this is not
possible: each external file must contain all information in the files
@ tree.
But this is
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
thre
18 matches
Mail list logo