while I'm being egregious I'll also hijack the thread rather than starting
a new one
I could have **sworn** I saw the option to clone multiple nodes at once
**somewhere** or was I dreaming one of these middle-of-the-night sessions?
If clone-marked-nodes is the only way, is there a way to
I vote for allowing the saving and reading of nodes to a database
table, but not attempting to replace simple flat file storage.
Instead, a node attribute could be set to define the secondary storage
and/or source. When saving a leo file you should have the option to
break the outline nodes from
On Thu, Dec 15, 2011 at 10:11 PM, Terry Brown terry_n_br...@yahoo.com wrote:
It wasn't clones that killed your work, it was refresh from disk.
But I moved the modified node *outside* the @file node I refreshed. So
I think the result is surprising. It wasn't much work.
A recent change may be
On Fri, Dec 16, 2011 at 9:08 AM, Edward K. Ream edream...@gmail.com wrote:
Correct. lp:leo-editor, that is trunk2, is now open for the usual rumpus.
For those who may not be native speakers of English, rumpus refers
to the line in Maurice Sendak's book, Where the Wild Things Are:
Let the
On Thu, Dec 15, 2011 at 8:55 PM, HansBKK hans...@gmail.com wrote:
Yes there is a question in there. . .
Not sure what your question is, but please note that sections must be
defined in some descendant of the node containing the reference.
That's the one and only constraint.
EKR
--
You
On Thu, Dec 15, 2011 at 5:32 PM, Terry Brown terry_n_br...@yahoo.com wrote:
- Edward had said don't touch the trunk at one point when he was
trying a fix, but I think they injunction's lapsed.
Correct. lp:leo-editor, that is trunk2, is now open for the usual rumpus.
EKR
--
You received
I discovered stickynote recently and liked especially the
stickynoteenc, allowing to integrate
another daily-needed thing into leo, namely having stored passwords in
there. But unfortunatly
found those not being platform independant, in my case between mac
(home) and linux (work).
I was wondering
Rev 4887 contains the new code.
**Warning**: I suffered the worst crash I have ever encountered while
running unit tests for this yesterday: all open files, of whatever
kind, got hosed. From a fleeting error message I suspect that the
culprit was trying to dismiss the splash screen twice, and
On Fri, 16 Dec 2011 09:06:32 -0500
Edward K. Ream edream...@gmail.com wrote:
But I moved the modified node *outside* the @file node I refreshed. So
I think the result is surprising. It wasn't much work.
A recent change may be relevant here. To fix a clone bug, rev 4872
saves and
As of rev 4888 Leo now issues an error and does not write @file
nodes containing @all in any node except the top-level nodes. This
fixes (or avoids) some strange behavior.
I would prefer not to put a dialog for read/write errors--typically
they are caught and fixed instantly.
Edward
--
You
On Fri, 16 Dec 2011 07:16:15 -0800 (PST)
Edward K. Ream edream...@gmail.com wrote:
All comments welcome.
I think this will save a lot of people a lot of time, and I agree with
the implementation decisions you made (repeat dialog, no @setting).
Thanks.
--
You received this message because you
On Fri, 16 Dec 2011 06:53:04 -0800 (PST)
resi147 sca...@yebu.de wrote:
But unfortunatly
found those not being platform independant, in my case between mac
(home) and linux (work).
I was wondering what could be the reason, because those encryption
mechansismn should
not depend on the
https://bugs.launchpad.net/leo-editor/+bug/882243
I'd like to discuss this bug here, because I would like us all to be
aware of the situation, and possible changes.
The surprise
=
To paraphrase the original bug report, suppose we have the following
@file tree:
+ @file test.txt
@others
On Fri, Dec 16, 2011 at 10:57 AM, Terry Brown terry_n_br...@yahoo.com wrote:
I think this will save a lot of people a lot of time, and I agree with
the implementation decisions you made (repeat dialog, no @setting).
There is related issue--a borderline case imo. Leo warns in the log
(in red)
There's also been a suggestion of putting nodes in Fossil, which seems
to offer the benefits of a db engine, plus versioning: all in one file.
http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
On Fri, Dec 16, 2011 at 7:58 AM, mdb mdbol...@gmail.com wrote:
I vote for allowing the
Not knowing how to point to trunk2 instead of the old trunk, I deleted
leo-editor/
so I could run
$ bzr branch lp:leo-editor
Now I'm seeing trunk2
On Fri, Dec 16, 2011 at 8:11 AM, Edward K. Ream edream...@gmail.com wrote:
On Fri, Dec 16, 2011 at 9:08 AM, Edward K. Ream edream...@gmail.com
Thanks for the tip, Terry,
only, what I was looking for was actually under
QTextEdit#richTextEdit
not QTreeWidget,
as I was looking for the selection background in the *body*, not the
tree.
Best regards, Josef
--
You received this message because you are subscribed to the Google Groups
On Friday, December 16, 2011 11:27:11 AM UTC+7, Terry wrote:
free_layout itself has no data consequences. But it's most useful when
you're arranging other plugin panes, it allows you to arrange the core
three panes somewhat more freely, but it doesn't do anything different
multiple-body
To clarify, my question was
Is it possible that my use of method B contributed to my data loss
problems?
and you have answered with a no.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To view this discussion on the web visit
as expected seems to be in the eye of the beholder 8-)
On Friday, December 16, 2011 11:38:39 PM UTC+7, Edward K. Ream wrote:
https://bugs.launchpad.net/leo-editor/+bug/882243
I'd like to discuss this bug here, because I would like us all to be
aware of the situation, and possible changes.
I put my question on why bzr pull was failing
https://answers.launchpad.net/bzr/+question/182160
The solution is to use
bzr pull --remember lp:leo-editor
Details of options for bzr pull are at
http://doc.bazaar.canonical.com/beta/en/user-reference/pull-help.html
Lewis
On Dec 16, 10:25 am,
I would like the facility to flag a given node in order to disable editing
it from within Leo, but still leave it receptive to reading incoming
changes from the filesystem. These are generally within @shadow trees.
Is there such a beast? Not requesting that there be, just inquiring.
I imagine
On Fri, 16 Dec 2011 15:23:53 -0800 (PST)
HansBKK hans...@gmail.com wrote:
On Friday, December 16, 2011 11:27:11 AM UTC+7, Terry wrote:
free_layout itself has no data consequences. But it's most useful when
you're arranging other plugin panes, it allows you to arrange the core
three
I suspect that if body editors could be made just slightly more
flexible it would open up whole new ways of using Leo. It seems they
just need two or three things to make them really flexible.
- a flag to indicate whether the tree pane should select the body
editor's node then the body
24 matches
Mail list logo
