Re: attrib_edit doesn't seem to work

[Edward K. Ream]

On Mon, Oct 23, 2017 at 3:01 PM, Terry Brown  wrote:

Drawers: I don't think this is something Leo needs other than in the
> context of importing org mode files.


​I agree.
​

> And in that context, only an
> implementation wholly compatible with org mode makes sense to me.
>

​Imo, either a uA or an in-text representation ​would be compatible with
org mode because the exporter will write the uA in a compatible way back to
the org mode file.

>
> IPython / Jupyter - depending on configuration, this system can let you
> move results between multiple languages (Python, R, javascript, etc.),
> access cloud storage (AWS etc.) and distributed computation (Spark,
> Hadoop, etc.) and so on.  I don't think we want to emulate those
> features in Leo,


​I agree.  There is no need to emulate "every little thing".

I didn't have time earlier today to say this, but the Leo for
org-mode/jupyter user documents are not just quick starts.  They should
point out the various design decisions made by Leo and the other programs,
and tell how those decisions affect the feature sets.

For example, *everything* in org mode is plain text.  This simplifies some
things, and makes other things much harder, even impossible.  So in org
mode drawers *must* be (usually hidden) text.  In Leo, the situation is
completely different.  All Leo has to do is to convert to/from uA's and
text when importing and exporting org mode files.

Org mode has features that Leo could use, but there is no great urgency to
replace todo.py with agenda's, for example.  Otoh, agenda's might suggest
features to add to todo.py.

Org mode doesn't have gnx's, so it is going to have a hard time doing
clones. Org mode does have workarounds, including text-based filters, which
work pretty well.

In short, the "Leo for X programmers" documents will discuss how the
overall Leo ecology differs from org mode, jupyter or whatever.

The situation may be more complicated for jupyter files.  At present, the
importer translates everything to nodes.  It would likely be more natural
to use uA's for many of the .json elements that jupyter uses.  I'll be
looking to rewrite the importer/exporter to make this happen.
​

> but I think Leo can be a great interface to the
> IPython / Jupyter system - I think Leo's tree can be a viable
> alternative to the HTML notebook interface, not to mention the power it
> brings to Leo users if Leo can use IPython / Jupyter as a computational
> resource.


​I agree completely.
​

> Too bad Ville's not here to opine, would be interesting to
> see what he'd say.
>

​Sigh.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Terry Brown]

On Mon, 23 Oct 2017 14:30:40 -0500
"Edward K. Ream"  wrote:

> On Mon, Oct 23, 2017 at 12:38 PM, Terry Brown 
> wrote:
> 
> > On Mon, 23 Oct 2017 09:25:51 -0500
> 
> Stepping back from implementation and separate vs. combined plug-ins,
> > sort of feeling that the velocity (speed and direction :-) of the
> > drawer and jupyter/ipython threads are different than they were in
> > pre-vacation discussions.  Do you share that sense?
> 
> ​Yes. I've decided to use uA's for drawers.
> ​
> > Particularly I
> > was thinking of Leo as a new interface to / client of
> > jupyter/ipython, rather than any emulation / duplication of
> > jupyter/ipython features in Leo, for reasons discussed earlier.
> 
> ​I plan to improve the jupyter importer in addition to mining ipython
> for features.​
> 
> > On drawers, again thinking back to earlier recent discussion, I'm
> > not sure quite what the goal is.  In one sense it seems Leo would
> > have different solutions for the need met by drawers in org. mode,
> > most simply just sub-nodes.  But in another sense drawers seem to
> > be an in-line body text feature handled by collapsing / folding,
> > which makes sense in a flat text document world but isn't something
> > Leo with it's tree often does.
> 
> ​That's the way drawers work in org mode, but we are free to choose a
> smoother way for Leo.
> 
> In particular, org mode delimits code blocks with fairly horrible
> syntax. The advantage for org mode is that there is no confusion
> about where code starts and stops.  In contrast, Leo uses @doc, @c
> etc to delimit code vs doc parts.
> ​
> > If it did, the most exact duplication of behavior
> > would be with something like the wikiview.  Note that there's no
> > recent activity on
> > https://github.com/leo-editor/leo-editor/issues/489, and I feel as
> > if I've been using wikiview without issues, so I'm not currently
> > sure there's a bug there, but would still like the answers to the
> > questions posed by #489 just for clarity.
> 
> ​#489 is worthwhile on its own, but that is not enough to use it for
> drawers.  Making drawers plain text will complicate all of Leo's
> execute-script code.  I don't want to do that, especially when eying
> support for executing code in languages other than Python using
> Ctrl-B. ​
> 
> > If there is to be a uA based implementation of drawers (a) I think
> > it would be easiest to extend attrib_edit, but (b) am not sure how
> > the uA approach addresses the in-line text position of the drawer
> > in the body text, it seems only wikiview type approaches do that,
> > and it seems necessary for any real drawer mode emulation.
> 
> ​This is a separate issue.  I would be happy even with a popup window
> to display the drawer.  But there are probably better ways.  Imo,
> icons denoting uA's and drawers will be an important addition.
> 
> Got to go now. There is no rush about these choices.

Ok.  Well I don't want to be repetitive, but my thoughts are:

Drawers: I don't think this is something Leo needs other than in the
context of importing org mode files.  And in that context, only an
implementation wholly compatible with org mode makes sense to me.

IPython / Jupyter - depending on configuration, this system can let you
move results between multiple languages (Python, R, javascript, etc.),
access cloud storage (AWS etc.) and distributed computation (Spark,
Hadoop, etc.) and so on.  I don't think we want to emulate those
features in Leo, but I think Leo can be a great interface to the
IPython / Jupyter system - I think Leo's tree can be a viable
alternative to the HTML notebook interface, not to mention the power it
brings to Leo users if Leo can use IPython / Jupyter as a computational
resource.  Too bad Ville's not here to opine, would be interesting to
see what he'd say.

Cheers -Terry


-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Edward K. Ream]

On Mon, Oct 23, 2017 at 12:38 PM, Terry Brown  wrote:

> On Mon, 23 Oct 2017 09:25:51 -0500
>

Stepping back from implementation and separate vs. combined plug-ins,
> sort of feeling that the velocity (speed and direction :-) of the
> drawer and jupyter/ipython threads are different than they were in
> pre-vacation discussions.  Do you share that sense?


​Yes. I've decided to use uA's for drawers.
​

> Particularly I
> was thinking of Leo as a new interface to / client of jupyter/ipython,
> rather than any emulation / duplication of jupyter/ipython features in
> Leo, for reasons discussed earlier.
>

​I plan to improve the jupyter importer in addition to mining ipython for
features.​

>
> On drawers, again thinking back to earlier recent discussion, I'm not
> sure quite what the goal is.  In one sense it seems Leo would have
> different solutions for the need met by drawers in org. mode, most
> simply just sub-nodes.  But in another sense drawers seem to be an
> in-line body text feature handled by collapsing / folding, which makes
> sense in a flat text document world but isn't something Leo with it's
> tree often does.


​That's the way drawers work in org mode, but we are free to choose a
smoother way for Leo.

In particular, org mode delimits code blocks with fairly horrible syntax.
The advantage for org mode is that there is no confusion about where code
starts and stops.  In contrast, Leo uses @doc, @c etc to delimit code vs
doc parts.
​

> If it did, the most exact duplication of behavior
> would be with something like the wikiview.  Note that there's no recent
> activity on https://github.com/leo-editor/leo-editor/issues/489, and I
> feel as if I've been using wikiview without issues, so I'm not
> currently sure there's a bug there, but would still like the answers to
> the questions posed by #489 just for clarity.
>

​#489 is worthwhile on its own, but that is not enough to use it for
drawers.  Making drawers plain text will complicate all of Leo's
execute-script code.  I don't want to do that, especially when eying
support for executing code in languages other than Python using Ctrl-B.
​

> If there is to be a uA based implementation of drawers (a) I think it
> would be easiest to extend attrib_edit, but (b) am not sure how the uA
> approach addresses the in-line text position of the drawer in the body
> text, it seems only wikiview type approaches do that, and it seems
> necessary for any real drawer mode emulation.
>

​This is a separate issue.  I would be happy even with a popup window to
display the drawer.  But there are probably better ways.  Imo, icons
denoting uA's and drawers will be an important addition.

Got to go now. There is no rush about these choices.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Terry Brown]

On Mon, 23 Oct 2017 09:25:51 -0500
"Edward K. Ream"  wrote:

> On Sun, Oct 22, 2017 at 8:02 PM, Terry Brown 
> wrote:
> 
> > It doesn't edit all attributes, only a subset, most easily managed
> > by using it to create the attribute in the first place (once the
> > attribute's created on one node, editing it on others is trivial).
> 
> ​Thanks for the clarification.
> 
> I think Leo will soon need two new optional icons.  The first will​
> indicate that a node has a uA.  The second will indicate that a node
> a a specific (as yet unspecified) uA associated with org-mode drawers.
> 
> ​Leo needs a dead easy way to handle uA's and drawers.  That will be
> part of the org mode project, #414
> .​  This might be
> based on attrib_edit, or perhaps a separate plugin would be best.
> What do you think?
> 
> Edward

Stepping back from implementation and separate vs. combined plug-ins,
sort of feeling that the velocity (speed and direction :-) of the
drawer and jupyter/ipython threads are different than they were in
pre-vacation discussions.  Do you share that sense?  Particularly I
was thinking of Leo as a new interface to / client of jupyter/ipython,
rather than any emulation / duplication of jupyter/ipython features in
Leo, for reasons discussed earlier.

On drawers, again thinking back to earlier recent discussion, I'm not
sure quite what the goal is.  In one sense it seems Leo would have
different solutions for the need met by drawers in org. mode, most
simply just sub-nodes.  But in another sense drawers seem to be an
in-line body text feature handled by collapsing / folding, which makes
sense in a flat text document world but isn't something Leo with it's
tree often does.  If it did, the most exact duplication of behavior
would be with something like the wikiview.  Note that there's no recent
activity on https://github.com/leo-editor/leo-editor/issues/489, and I
feel as if I've been using wikiview without issues, so I'm not
currently sure there's a bug there, but would still like the answers to
the questions posed by #489 just for clarity.

If there is to be a uA based implementation of drawers (a) I think it
would be easiest to extend attrib_edit, but (b) am not sure how the uA
approach addresses the in-line text position of the drawer in the body
text, it seems only wikiview type approaches do that, and it seems
necessary for any real drawer mode emulation.

Cheers -Terry

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Edward K. Ream]

On Sun, Oct 22, 2017 at 8:02 PM, Terry Brown  wrote:

It doesn't edit all attributes, only a subset, most easily managed by
> using it to create the attribute in the first place (once the
> attribute's created on one node, editing it on others is trivial).
>

​Thanks for the clarification.

I think Leo will soon need two new optional icons.  The first will​
indicate that a node has a uA.  The second will indicate that a node a a
specific (as yet unspecified) uA associated with org-mode drawers.

​Leo needs a dead easy way to handle uA's and drawers.  That will be part
of the org mode project, #414
.​  This might be
based on attrib_edit, or perhaps a separate plugin would be best. What do
you think?

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Terry Brown]

p.s. it's working fine as far as I can see.

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: attrib_edit doesn't seem to work

[Terry Brown]

On Sun, 22 Oct 2017 10:28:25 -0700 (PDT)
"Edward K. Ream"  wrote:

> On both Windows and Ubuntu the attrib_edit plugin seems to do
> nothing.  I have the default v.u mode checked.
> 
> 1. The Attribs pane is empty, even when p.u isn't.
> 
> 2. The attrib-edit-scan command doesn't find uA's for the icons
> created by the todo plugin.
> 
> Is anyone actually using the attrib_edit plugin successfully? This is 
> becoming important for #414 
> .

It doesn't edit all attributes, only a subset, most easily managed by
using it to create the attribute in the first place (once the
attribute's created on one node, editing it on others is trivial).

See under "Technical information" in its docs.

Cheers -Terry

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.