Script weirdness

49 views
Skip to first unread message

Rob

unread,
Jan 29, 2019, 10:05:57 AM1/29/19
to leo-editor
I have a script I use frequently to copy a node and its subtree to the clipboard for pasting into other applications (thanks to @Vitalije for getting me started on the script!)

s = g.getScript(c,p,useSentinels=False,forcePythonSentinels=False)
g.app.gui.replaceClipboardWith(s)
g.es(c.p.h+" (node + expansion) copied to clipboard. Paste as-is (CTRL-V) to external application as needed.")

The weirdness is that if I place the @language directive as the first line of the node and run the script, the clipboard is empty. I tried this with several different @languages (tried tex, html, plain and c) and all fail except @language python, which then works as expected. If I move the @language directive to a parent node, the script works.

Any idea why the script works for @language python and not for any other @language?

Rob...


Edward K. Ream

unread,
Jan 29, 2019, 3:38:35 PM1/29/19
to leo-editor
On Tue, Jan 29, 2019 at 10:05 AM Rob <lar...@gmail.com> wrote:

> The weirdness is that if I place the @language directive as the first line of the node and run the script, the clipboard is empty. I tried this with several different @languages (tried tex, html, plain and c) and all fail except @language python, which then works as expected. If I move the @language directive to a parent node, the script works.

g.getScript calls g.extractExecutableString(c, p, s), without any
'language' kwarg, which explains the special case for @language
python. This is a bug. Knowing its source you could work around
it...

Edward

Rob

unread,
Jan 29, 2019, 7:35:27 PM1/29/19
to leo-editor
I suspected it might be related to the 'forcePythonSentinels' line, and digging around I wasn't able to find out enough about that parameter (argument?) to understand what was happening (looked in leoPyRef.leo and a few other places). I will look around some more using your clues. As for the issue itself, it's really not a big deal, the easy workaround is to simply not have an @language in the node. However, it's possible that one of the downstream nodes will have that directive and I might miss data copied to the clipboard. Thanks for the pointer.

Rob...

Rob

unread,
Jan 29, 2019, 8:57:06 PM1/29/19
to leo-editor
RGK: Discovery Notebook (feel free to ignore)

Perhaps it might help others struggling to learn how Leo's core works; will post random thoughts as I try to figure this out, dead ends and all.

  1. After finding the code for g.extractExecutableString(c, p, s) in LeoPyRef.leo (found in Leo's core directory)  it seems to me that I'm probably not going about this the right way (even though it sorta worked).
  2. The call to g. getScript seems to be intended to only work with python scripts (based on code from #1 above). As I understand the code (which I don't), no explicit @language directive forces python as the 'assumed' language, while any other explicit @language directive will cause subsequent lines to be ignored (this is exactly what I observe).
  3. I don't see how altering that code block would work w/o screwing up the whole script mechanism (don't want to go there).
  4. So, my initial thought is to find a different way to retrieve the node and subtree expansion contents besides calling g.getScript.
  5. First guess would be to find something in Leo's write to file code. Haven't found anything yet, will continue looking.
Rob...

Edward K. Ream

unread,
Jan 31, 2019, 12:43:27 PM1/31/19
to leo-editor


On Tuesday, January 29, 2019 at 7:35:27 PM UTC-5, Rob wrote:
I suspected it might be related to the 'forcePythonSentinels' line, and digging around I wasn't able to find out enough about that parameter (argument?) to understand what was happening (looked in leoPyRef.leo and a few other places).

I was wondering that myself ;-)

#1071 has been been fixed as follows: The only change was to g.extractExecutableString.  It works like this: If there are zero or one @language directives, it returns the entire string.  Otherwise, it returns only those lines following the @language directive that "in effect", that is, the @language directive specified by ancestor @language directive, or c.target_language, corresponding to @string target_language.

The old code had no chance of working properly.  Feel free to reopen #1071 if problems remain.

Edward

Edward K. Ream

unread,
Jan 31, 2019, 12:44:55 PM1/31/19
to leo-editor


On Tuesday, January 29, 2019 at 8:57:06 PM UTC-5, Rob wrote:
RGK: Discovery Notebook (feel free to ignore)

Perhaps it might help others struggling to learn how Leo's core works; will post random thoughts as I try to figure this out, dead ends and all.

I've fixed #1071, but in general these kinds of explorations and notes will be helpful.

Edward
Reply all
Reply to author
Forward
0 new messages