On Feb 24, 7:47 am, Edward K. Ream edream...@gmail.com wrote:
As I write this, I think the safe thing to do will be to withdraw Leo 4.7
final.
On second thought, this wouldn't help much: all versions of Leo 4.7
suffer the same problem, roughly speaking.
Edward
--
You received this
Unless things have changed, it should be pointed out that Leo's unit
testing is only set up to work on Leo code, that is that code set up
with unit testing can only be tested if it is run alongside Leo, not
if it is python code written with Leo but run outside of it.
Changes would have to be made
On Wed, Feb 24, 2010 at 8:38 AM, tfer tfethers...@aol.com wrote:
Unless things have changed, it should be pointed out that Leo's unit
testing is only set up to work on Leo code, that is that code set up
with unit testing can only be tested if it is run alongside Leo, not
if it is python code
On Wed, Feb 24, 2010 at 1:25 AM, Matt Wilkie map...@gmail.com wrote:
4. I read your post, and thought, again, I really need to try these unit
test things.
...and I'm thinking, I really need to *learn* what these unit test
thingies are. Being a fledging developer, barely into kindergarten, it
On Wed, Feb 24, 2010 at 12:17 AM, ne1uno eltro...@gmail.com wrote:
this sounds like what I call scaffolding. it precedes unittesting and
is the only thing that works in the initial design.
The Aha is that unit tests can verify design issues as well.
I don't want to make a rigid distinction
The problems with @file that have just resurfaced show how hard it can
be to manage complex engineering projects. I got blind-sided by this
problem, despite the fact that it had been dealt with before.
The problem was compounded by the fact that the unit tests for @file
never failed. Looking at
On Feb 23, 11:16 pm, Ville M. Vainio vivai...@gmail.com wrote:
The names without the prefix seem a little too generic (commands,
plugins...). It might also break lots of code not in leo repo.
Do you mean eventual namespace conflicts?
--
You received this message because you are subscribed to
On Wed, Feb 24, 2010 at 5:50 PM, zpcspm zpc...@gmail.com wrote:
On Feb 23, 11:16 pm, Ville M. Vainio vivai...@gmail.com wrote:
The names without the prefix seem a little too generic (commands,
plugins...). It might also break lots of code not in leo repo.
Do you mean eventual namespace
On Wed, Feb 24, 2010 at 7:47 AM, Edward K. Ream edream...@gmail.com wrote:
Leo 4.7.1 will indeed be needed to fix a bug that can (will) cause
data loss in the conversion of @file nodes to the new (thin-like)
sentinels.
I am planning to base 4.7.1 on rev 3002 of the trunk. The alternative
On Wed, Feb 24, 2010 at 7:47 AM, Edward K. Ream edream...@gmail.com wrote:
Leo 4.7.1 will indeed be needed to fix a bug that can (will) cause
data loss in the conversion of @file nodes to the new (thin-like)
sentinels.
The following bug-tracker discusses various versions of this bug:
On Wed, Feb 24, 2010 at 10:21 AM, Edward K. Ream edream...@gmail.com wrote:
Yes, I did check the diffs, but as I said somewhere else, these kinds
of changes are the very essence of stupidity. It would be good
(essential) to have a tool to verify all the diffs of that rev affect
only blanks
Unfortunately my freetime has disappeared for a prolonged period,
however, I thought I would dump the stuff I *would* do if I had some
(I know this is not immensely helpful):
* Plugin system cleanup (easy)
- Remove the weird way leo loads plugins (forcing a reload), change it
to use __import__
Hello
I think that menu command Outline - Paste node as a clone (Alt+Ctrl
+V) seems that has no effect at all.
It is possible to create clone and to move it around but it is not
very handy when I have to move it far away.
I thought that maybe I missed something in this group (maybe it was
I have found what was causing trouble :-)
Putting @bool enable_alt_ctrl_bindings = True in myLeoSettings.leo
solved the problem.
It is interesting that in leoSettings.leo there is no such setting. I
couldn't find any thing in documentation either about it. I was lucky
to find it through
14 matches
Mail list logo