On Sunday, March 26, 2017 at 5:26:43 AM UTC-4, Edward K. Ream wrote:
>
> On Sat, Mar 25, 2017 at 9:33 PM, Eric S. Johansson <[email protected]
> <javascript:>> wrote:
>
>> Like Ed's engineering notebook posts, it's a public declaration of
>> thoughts with an invitation a comment if I'm going to far off the rails
>>
> I'm glad to help.
>
>
>> In my simplistic use of Leo, I will have at most one document directive
>> followed by a code directive.
>>
>
> I assume you mean:
>
> @doc
> ...
> @c
>
yes it was
>
>
>
>> I don't know if it's possible or even a good idea to have multiple
>> document and code directives. Somewhere I picked up the idea that one
>> thought per node is a good idea.
>>
>
> It's possible to have more than one @doc/@c (or simply @/@c) directive
> pairs.
>
> It's a moot point in python programming because docstrings are considered
> better style.
>
Interesting. I have different take on writing code and that I tend to
prefer narrative descriptions for each small thought/code fragment. I'm
going to find example I can publish so I can show you concretely what I'm
talking about.
By the way, I developed a "standard frameworks" for all of my future work
with bottle. If things work is planned, I will have a scaffold on which I
can build a bottle based program. As an aside, I do think that scaffolding
is far more practical in Leo that it is a plain text editor. But I want to
make that a separate thread of discussion when I'm ready for it.
> Keeping things simple, I need to figure out how to select everything in a
>> code directive region and replace it with a new body of text.
>>
>
> Exactly as stated, this might indeed be "full of hairballs". There are at
> leas two preliminary questions that may help you make this simpler.
>
> 1. Whenever dealing with sections (<< whatever >> ) and their expansions,
> you should think first of top-level code in leoAtFile.py that "pretends" to
> write the file, but instead writes the file to a string:
>
> def write(self, root,
> kind='@unknown', # Should not happen.
> nosentinels=False,
> perfectImportFlag=False,
> scriptWrite=False,
> thinFile=False,
> toString=False,
> ):
>
> This method really should have a better docstring. In particular, the
> docstring should mention that at.stringOutput contains the resulting string
> when toString is True.
>
> The following is tested code (in an @button node):
>
> at = c.atFileCommands
> at.write(
> p,
> kind='@file',
> nosentinels=True,
> toString=True,
> )
> print(at.stringOutput)
>
> 2. I wouldn't try to *replace *the parts of an outline unless there is
> absolutely no other way. Instead, I would write the result of point 1
> somewhere, say in an @toggle-name tree:
>
> @toggle-name
> @toggle-@file-a
> @toggle-@clean-b
> ...
>
> Something like this should save you from having to touch actual code.
>
Okay. That helps I'm not sure how much yet but it does help. :-) I want to
think on it for a bit but here's something I hope will illustrate something
I talked about earlier which is you have the editable version and the
presentation version. Above, you gave a code fragment (def write...). Here
is how I would speak it:
def write (self, root,
kind = '@unknown',
no sentinels = False,
perfect import flag = False,
script write = False,
thin file = False,
two string = False,
):
After going through the whole toggle name transformation process, I would
end up with your example:
def write(self, root,
kind='@unknown', # Should not happen.
nosentinels=False,
perfectImportFlag=False,
scriptWrite=False,
thinFile=False,
toString=False,
):
normally, this transformation is bidirectional in that I can transform from
string name codename and then back again. I should emphasize that the
transformation between string naming codename is a database lookup, not a
calculation. The reason for this is that well calculations can work well
for a code base that stands alone, it doesn't work well when you're trying
to integrate with other people's work.
I don't know if this is what you meant by not having to touch code but
ideally there should be the source form, mutable, and rendered form,
immutable. One way to think of it is that the source form is used in the
weaving process and the rendered form in the tangle process. For me the
advantage of keeping the split is that I can now enhance the source form
environment to do other things necessary for programming by speech and
preserve metadata about the environment. The downside is that it really
messes up the ability to let other team members muck on your@clean sections
without using Leo and they may get confused if they had to use the source
form.
I believe I mentioned this in an earlier post I talked about flipping back
and forth between rendered form and source form inside of the display of
one node or maybe using the rendering window to hold the rendered version
of the code.
For example, one place where a calculated name would work is this:
at = c.atFileCommands
If I was to say "at = C.at file commands" in a future version of toggle
name I should be able to know the methods belonging to the object instance
held in C and match on the closest calculated possibility or, have a object
specific database of spoken name and codename. In theory, should be able to
embedded in a doc string but I'm not sure I want to go there right now.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
