Offray Vladimir Luna Cárdenas 于2018年10月12日周五 上午12:21写道：
> Most of my documentation happens today in my own interactive outliner
> and not in Leo, but I remember having simple Leo outlines I wanted to
> share about my workflow with Markdown that where relatively
> self-contained via @buttons.
>
> The first evidence of my using Leo (a .leo file in a back-up) was in 2007.
> My first question to the google group was in 2012. During those five years
> I visited Leo occasionally to check and see if I was any less of an idiot
> for not understanding how to make it work for my use case.
>
> You have to insert calls to u.beforeSomething and u.afterSomething, where
> u is c.undoer and "Something" is one of a list of possible actions. The
> complete list is in leoUndo.py. In essence, the "before" method saves the
> *relevant* data before executing the command, and the "after"
>
> First of all, Leo's add-comments and delete-comments commands probably do
> what you want.
They don't behave the way I would like. I had already been through their
code (it helped me in writing my own commenting functions). There's nothing
objectively wrong with Leo's commenting system -
On Mon, 8 Oct 2018 02:58:28 -0700 (PDT)
"Edward K. Ream" wrote:
> - Why can't we put unit tests near the code being tested?
I'd argue (for Python) for using the best in class unit testing
framework's practice. pytest puts tests for
.../foo/my_module.py->my_func()
in
Hi,
Comments inlined below.
On 10/8/18 4:58 AM, Edward K. Ream wrote:
> When I finished swimming yesterday, the thought appeared that *Leo
> isn't nearly good enough*. This was a /constructive/ thought, as I'll
> explain here. These questions came to mind:
>
> - Why must we be continually
Hi,
This goes in the same line I have proposed in this thread (but I
answered before coming to this particular message). I think that this
idea of documenting a new feature via a small notebook that implements
that would help to bridge the gap between the documentation and the
mailing list.
I will chime in on the documentation issue. Better documentation and
especially examples would have worked to speed my adoption of Leo as my
primary information management and writing tool.
I am not a programmer.
The first evidence of my using Leo (a .leo file in a back-up) was in 2007.
My
Hi,
It's good to see this thread about Big Dreams and their forks, including
documentation.
My use of Leo is know kind of the same, and I'm using Grafoscopio[1] for
the possibilities I want to explore on outlining and interactive
documentation. But anyway, I would like Leo to be a vehicle for
On Thursday, October 11, 2018 at 6:12:16 AM UTC-5, Edward K. Ream wrote:
But there may be an easier way. See the FAQ entry: How can I use dev nodes
> to develop and test Leo's own code?
>
When I originally wrote this I knew that I had documented this somewhere.
It took me awhile to realize
On Sat, Oct 6, 2018 at 8:10 AM wrote:
I recently tried writing my own logic for commenting and uncommenting lines.
>
First of all, Leo's add-comments and delete-comments commands probably do
what you want. There are unit tests in unitTest.leo. See the node Active
Unit Tests-->@file
Rather than reloading Leo each time I want to experiment with Qt, I would
like to just run a script within Leo:
*@file c:/test/qt_prototype.py*
import sys
from PyQt5 import QtWidgets # Qt, QtCore, QtGui
app = QtWidgets.QApplication(sys.argv)
w = QtWidgets.QWidget()
w.resize(250, 150)
On Wednesday, October 10, 2018 at 6:01:29 PM UTC-5, anli...@gmail.com wrote:
>
> Below are some random examples.
>
A few comments.
Will any command I create that manipulates texts/nodes automatically be
> undo-able?
>
No. Imo, there is no way to do this automatically.
If not, what do I need
On Wed, Oct 10, 2018 at 6:01 PM wrote:
Below are some random examples.
>
Thanks. None of the examples would have been easy for me to find. I've
just created #992 for this. It will be fixed soon.
Edward
--
You received this message because you are subscribed to the Google Groups
On Thu, Oct 11, 2018 at 2:56 AM Zoom.Quiet wrote:
in fact in any tech community, there is one hide rule:
> propose by who, make it by who ;-)
>
Heh. I'm all for that rule.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe
On Thu, Oct 11, 2018 at 1:06 AM wrote:
> > Yes, i meet same problems,
> > but the reason is simple:
> > - Leo release so many years, but the core developer always only EKR
> > - so means more and more knowledge for EKR as natural truth, not need
> explain
> > - and servicing big document.leo
于2018年10月11日周四 下午2:06写道：
>
> > Yes, i meet same problems,
> > but the reason is simple:
> > - Leo release so many years, but the core developer always only EKR
> > - so means more and more knowledge for EKR as natural truth, not need
> > explain
> > - and servicing big document.leo project is
On Wed, Oct 10, 2018 at 11:56 PM Matt Wilkie wrote:
> "fatal: No names found, cannot describe anything" is from executing `git
> describe --tags` in a shallow clone that isn't deep enough to include a
> tagged commit. Fixed in travis.yml by increasing the clone depth from
> default of 50 to 100
> Yes, i meet same problems,
> but the reason is simple:
> - Leo release so many years, but the core developer always only EKR
> - so means more and more knowledge for EKR as natural truth, not need
explain
> - and servicing big document.leo project is not funny and tired... v
Now that I
19 matches
Mail list logo
