On Thu, Oct 19, 2017 at 4:34 AM, vitalije <[email protected]> wrote:

> In rev:df3d88bb1, I have added one simple method to try each of selected
> lines in sequence. First line that matches will win. That will cover I
> believe most cases like nested definitions, python decorators and such.
> However, it will be broken if the last pattern matches always.
>
> The rev:df3d88bb1 will successfully extract the example code Terry has
> given.
>
​The code looks good to me.

Finally, the user can always changed the newly-created node by hand, using
>> all of her natural pattern-matching abilities ;-)
>>
> ​...​

>  It is more trouble than that. If extractDef doesn't find headline, it
> strips the first line from the selection and uses it as headline. In effect
> it deletes the first line of selected code and it can be frustrating for
> the user. If it however, finds a match even a wrong one, it will keep all
> selected lines intact and the only a headline can possibly be wrong.
>

​Ok.  I had forgotten that.​

> I don't know if anyone else was using this command very often. I know that
> I had written a private plugin whose sole purpose was to patch commander
> with the new definition of extractDef. It was long time ago before I got
> commit access to Leo repository, so it was the only way for me to change
> Leo code.
>
​...​

> When importing and analyzing code written in coffeescript, javascript or
> clojurescript, this command was tremendously helpful (in patched version)
> and totally useless in its original version. That made me wander if there
> is anyone else there who uses this command at all.
>

​I used to use this command.  Now I typically use parse-body.​

> Of course, it was designed to work with python definitions, but surely
> there are users who use Leo for writing code in other languages as well. My
> conclusion was that most probably those users haven't been using extract
> command at all. How else could it be possible that nobody ever complained
> about its shortcomings before?
>
​I can't answer that.  We have to rely on complaints, including our own.

> This is how I use the extract command when importing foreign code. Usually
> I open source file with the '@edit` node. It places the whole code in one
> large body. Then I try to find the largest blocks of code (classes, exports
> objects,...). Reading from the top of the file, whenever I find the
> beginning of a block (class definition, or very often comment line that
> announces a block of correlated classes/functions), I search for the
> beginning of next such block. When I find the next block (or the end of
> file if it is the last block), I select all lines from current position up
> to the beginning of the block and execute extract command (Ctrl+Shift+d).
>
​Have you tried parse-body?  It uses Leo's importer code for the @language
in effect, if one exists. See the node "ic.parse_body & helper".  This
should save you lots of work for the languages for which importers exist,
including coffeescript and javascript. I don't see an importer for
clojurescript, but it probably would not be too difficult to create it.

> That gives me a few nodes smaller than the original one. In each of them I
> look for smaller blocks like methods or functions and repeat the process
> with those blocks. I add '@others' where necessary in parent nodes. And so
> I repeat this process until I have chunked all code into small enough
> nodes. The alternative would be to use '@auto' import for a source file,
> but I was never truly satisfied with the results at least not for
> coffeescript, javascript and clojurescript files. That is why I find the
> extract command so useful to me. If you have never heard of extract command
> or you have tried it before and weren't satisfied with what it did, now is
> the time to give it a try.
>
​You can always rearrange nodes after doing parse-body, which you can't do
when using @auto, so parse-body plus manual tweaks is likely to save you
lots of work.

Edward

-- 
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.

Reply via email to