Re: Playing well with other apps, tools and languages

[Offray Vladimir Luna Cárdenas]

As discussed in other threads, I think such playing well with others
should be done by client/server architecture, in the case of IPython.
The main issue is the rendering of enhanced content, like math, 3D plots
and so on. I don't know if some Qt web related technologies can be
helpful here. I think that Leo has been too focused in playing well by
interchanging files back and forth with others, and is time to think in
playing well by communicating well with others (services). This has been
mosly unexplored until now is showing to be critical for the Jupyter
integration, where Leo has a lot to offer with its advanced
self-referential and programmable DOM (beyond HTML).

Cheers,

Offray


On 20/10/17 09:34, Edward K. Ream wrote:
> ​In another thread I wrote: "Leo can already render LaTex math markup
> using reStructuredText
> .
> But not very well."
>
> ​It may be possible to better render LaTeX ​using the richtext.py
> plugin. I haven't tried it yet.  It would require installing this
> ckeditor plugin , presumably
> as part of the richtext plugin.
>
> More generally, Leo needs to make common tasks easier for the user.
> This goal became clear during my vacation.  It will require
> considerable work behind the scenes. Several tasks come to mind:
>
> - Support all ipython "magics" that are applicable in Leo, perhaps
> including magics defined in ipython plugins. This includes support for
> executing scripts in languages other than python, or for specific
> versions of python.  This should be fairly straightforward.
>
> - Support JavaScript-based tools somehow.  I love python, but the
> world seems to be moving away from it.  For example, Leo should render
> mathjax properly, without relying on buggy intermediate layers such as
> docutils or Qt widgets.
>
> - Better support for moving between Jupyter and Leo.
>
> Your comments, please.
>
> 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.

-- 
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: Rendering math in Leo

[Offray Vladimir Luna Cárdenas]

I second Terry's idea of going with Markdown, particularly Pandoc's
variant, which is pretty mature and with an active community discussing
a lot of details to support a complete writing & publishing workflow,
the ubiquity advantage with a lot of variants everywhere (Ghost, Stack
Overflow, GitHub, Fossil). Recently, at our local hackerspace [1] we
opened the Data Journalism Handbook [2][2a] as a Grafoscopio document
and produced a PDF (13 Mb) [3] from a Pandoc's Markdown file (500Kb) [4]
generated from a single Grafoscopio notebook/outline (600 Kb). This
workflow was pretty well supported by Pandoc's Markdown.

I proposed some Qt Web technology to show markdown (including math)
inside Leo nodes. Maybe the IPython Qt Console, which supports this
rendering could be inspiring here[6], but I don't know about the math
rendering support in that case..

=== Extra Links:
[1] http://hackbo.co/
[2] http://datajournalismhandbook.org/
[2a] http://mutabit.com/repos.fossil/mapeda/
[3] http://mutabit.com/repos.fossil/mapeda/uv/mapeda.pdf
[4] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.markdown
[5] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.ston
[6] https://ipython.org/ipython-doc/3/interactive/qtconsole.html

Cheers,

Offray


On 20/10/17 10:24, Terry Brown wrote:
> On Fri, 20 Oct 2017 07:05:44 -0700 (PDT)
> "Edward K. Ream"  wrote:
>
>> Leo can already render LaTex math markup using reStructuredText 
> Although I quite like reStructuredText my impression is that it has all
> but lost the competition for market share to markdown.  GitHub,
> obviously, favors markdown.  I suspect Jupyter does too.  R-markdown is
> the literate analysis markup of choice for R focused work.  Pandoc
> (backend for at least R-markdown if not others) seems to have more
> markdown extensions for handling citations, math, tables of content,
> etc. than it does reStructuredText extensions.  Maybe Sphinx still
> favors reStructuredText?
>
> The leo_edit_pane view widget currently uses markdown.py to convert
> markdown to HTML for viewing in a QWebkit / QTheOtherHTMLWidget pane.
> Not sure but markdown.py may not handle math.  But an obvious
> alternative is to use pandoc for markdown -> html, which definitely
> supports math.
>
> Cheers -Terry
>
>> .
>>  
>> But not very well.
>>
>> Enter the following in any body pane, and look at the results in the 
>> viewrendered pane. Blank lines are significant in some places:
>>
>> @language rst
>>
>> \int_{b^a} \, x^2 \, dx: :math:`\int_{b^a} \, x^2 \, dx`
>>
>> d/dx \int_{0^x}\,f(u)\,du=f(x): :math:`d/dx \int_{0^x}\,f(u)\,du=f(x)`
>>
>> \int_{0^x}: :math:`\int_{0^x}`
>>
>> block:
>>
>> .. math::
>>
>> x + 5 = -3
>>
>> \int_{b^a} \, x^2 \, dx
>>
>> d / dx \, \left(\int_{0^x} f(u)\,du\right)=f(x)
>>
>> d / dx (\int_{0^x} f(u)\,du ) = f(x)
>>
>> y_k(\mathbf{x},\mathbf{w}) = p(C_1|\mathbf{x})
>> 
>> Alignment with  in \\begin{equation}:
>>
>> .. math::
>>
>> \begin{equation}
>> x + 5 = -3 \\
>> \int_{b^a} \, x^2 \, dx\\
>> d / dx \left(\int_{0^x} f(u)\,du\right)=f(x)\\
>> d / dx (\int_{0^x} f(u)\,du) = f(x)\\
>> y_k(\mathbf{x},\mathbf{w}) = p(C_1|\mathbf{x})
>> \end{equation}
>> 
>> Inline: :math:`y_k(\mathbf{x},\mathbf{w}) = p(C_1|\mathbf{x})`
>>
>> Inline: :math:`(\sum_{t=0}^{N}\,f(t,k))/N`
>> 
>> The final output will be a vector :math:`Y` with :math:`K` elements, 
>> :math:`y_k`, where
>> :math:`y_k(\mathbf{x},\mathbf{w}) = p(C_1|\mathbf{x})` is the
>> probability that node
>> :math:`k` is in class :math:`C_1` and
>> :math:`p(C_2|\mathbf{x}) = 1-p(C_1|\mathbf{x})`
>>
>> This is kinda cool, but it has serious problems. The first two are
>> visual:
>>
>> - The rendering is poor for integrals, \int, and sums, \sum.
>>
>> - There is no easy control over font size.  It may be possible using
>> css for rST.
>>
>> Worse, there are at least two serious markup incompatibilities:
>>
>> - \frac does not render as in Jupyter or the mathjax viewer 
>> .
>>
>> - The :math:`` syntax is clumsy.  In contrast, Jupyter
>> notebooks use $$.
>>
>> *Summary*
>>
>> These kinds of incompatibilities will substantially limit the appeal
>> of rST :math: markup.
>>
>> More generally, Leo is faced with a never-ending task of playing as
>> well as possible with existing apps, tools and languages. This task
>> requires continuous invention, so it could be called a source of
>> pleasure ;-)
>>
>> 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 

Re: Merging leo_edit_pane into master?

[Edward K. Ream]

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

> I think to make progress leo_edit_pane should be merged into master.
>

​Excellent.​

I think this requires only three lines to change in core:
>

​I'm surprised that the footprint is so small.

Thoughts?
>

​I'll run my typical tests in the branch and let you know soon.

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

[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: The plan for the near future

[Edward K. Ream]

On Mon, Oct 23, 2017 at 3:56 PM, Kent Tenney  wrote:

> Python 3.7 may offer some assistance here
> https://www.python.org/dev/peps/pep-0553/
>

​This is still a console-based approach, just like g.pdb().  And is more to
type ;-)

It's interesting that ipython is content with something similar, namely the
"magic" %pdb.

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: The plan for the near future

[Kent Tenney]

Python 3.7 may offer some assistance here
https://www.python.org/dev/peps/pep-0553/

On Mon, Oct 23, 2017 at 9:16 AM, Edward K. Ream  wrote:

> On Mon, Oct 23, 2017 at 8:58 AM, Kent Tenney  wrote:
>
> The feature I'd like to see in some shape or form is
>> breakpoints/stepping/inspection
>>
>
> ​A reasonable request.  I've just created #558
> . This would be a
> major project, but it's well worth doing.​
>
>
>> There's a gap between
>> import pdb; pdb.set_trace()
>>
>> and the IDEs which assume all development roles: editor, project
>> management etc.
>>
>
> ​In Leo you can use g.pdb(), provided that g is available.​
>
> ​The gap isn't as large as you might think, but I agree that it would be
> good for Leo's body pane to support breakpoints.
>
> 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.
>

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

Merging leo_edit_pane into master?

[Terry Brown]

I think to make progress leo_edit_pane should be merged into master.

Currently in the edit component I have Leo syntax coloring working, but
not Leo keys, but I think there's enough to be gained in fast-tracking
other aspects of leo_edit_pane development (viewing results from code,
markdown, etc., multi node editors, and so on) that merging is
worthwhile, with the key handling issue on the back burner for now.

I think this requires only three lines to change in core:
https://github.com/leo-editor/leo-editor/compare/ad260d...d57c1bc#diff-757d2eb054f3277c84501d178222699f
(tch, no direct link, you have to click "Files changed" then "13
changed files" to see the changes to core)

Obviously the signal emit is in a very sensitive place. I tested the
performance impact here:
https://github.com/leo-editor/leo-editor/issues/465

It might be possible to avoid the signal related changes... as my
signal manager evolved I realized it was closer to Leo's hooks than I
thought.  Using hooks would require fixing a bug(?) such that
bodykey[1|2] doesn't report all keys, particularly it misses
backspace / delete I think.  Also, the placement of the signal in the
above is more obviously omniscient than bodykey[1|2].  So I'd rather
not dump the new signal if it can be accepted as is.

The changes to core do nothing without other new code being executed to
utilize them, so I think they're quite safe.

Thoughts?

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

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

Changes to g.Debugging functions

[Edward K. Ream]

Rev ad260d improves  g.print* and g.*ToString functions.  They produce more 
readable output than pprint.pprint.

The revised functions all have the same signatures, eliminating several 
unused keyword args, and putting the remaining kwargs in alphabetical 
order.  pylint is happy with all of Leo's source files and plugins, but 
these changes might affect existing scripts.

One more round of cleanups is coming, but this round will make no further 
changes to signatures.

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: The plan for the near future

[Edward K. Ream]

On Monday, October 23, 2017 at 8:21:55 AM UTC-5, Edward K. Ream wrote:

My plan is simple: to read the *user* docs for org mode, ipython and 
> jupyter, looking for features that Leo presently lacks.  
>

Or looking for features that Leo already has, in one form or another ;-)  
This suggests several new documents:

- Leo for IPython/Jupyter users.
- Leo for org mode users
- Leo for vim users.

These documents will explain the correspondence between, for example, 
magics in IPython and directives in Leo.

As another example, @button loosely corresponds to org mode's library of 
babel , except that org 
mode doesn't have a real DOM.

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

[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: The plan for the near future

[Edward K. Ream]

On Mon, Oct 23, 2017 at 8:58 AM, Kent Tenney  wrote:

The feature I'd like to see in some shape or form is
> breakpoints/stepping/inspection
>

​A reasonable request.  I've just created #558
. This would be a
major project, but it's well worth doing.​


> There's a gap between
> import pdb; pdb.set_trace()
>
> and the IDEs which assume all development roles: editor, project
> management etc.
>

​In Leo you can use g.pdb(), provided that g is available.​

​The gap isn't as large as you might think, but I agree that it would be
good for Leo's body pane to support breakpoints.

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: The plan for the near future

[Kent Tenney]

I'm developing a workflow with Leo at the helm, it's working
well, managing my issues with multiple machines and locations.
Based on lsyncd for synchronization, and tmuxp for program launching.

The feature I'd like to see in some shape or form is
breakpoints/stepping/inspection, something not in ipython/jupyter,
but found in the IDEs
https://wiki.python.org/moin/IntegratedDevelopmentEnvironments

There's a gap between
import pdb; pdb.set_trace()

and the IDEs which assume all development roles: editor, project management
etc.

If Leo could provide 'run to cursor' and then 'step over' 'step into',
while displaying a window showing value of selected variables ...
I for one, would be tickled.

Thanks,
Kent







On Mon, Oct 23, 2017 at 8:21 AM, Edward K. Ream  wrote:

> On vacation I kept thoughts about near-term plans in the background.  When
> I returned the plan became clear.
>
> *Goals*
>
> 1. Make it easier for users to switch between Leo and other programs,
> especially Leo and Emacs (org mode) and Jupyter. See #477
> .
>
> 2. Provide all significant features of org mode and Jupyter within Leo. See
> #414 .
>
> I considered a client/server architecture for Leo. I am going to reject
> that approach for now.  Jupyter provides those capabilities if desired.
>
> *Actions*
>
> My plan is simple: to read the *user* docs for org mode, ipython and
> jupyter, looking for features that Leo presently lacks.  There is little
> point in reading *dev* docs for these programs, except in special
> circumstances.  Leo's "ecology" is significantly richer than other IDE's,
> so the implementation of features within Leo will be quite different from
> in Emacs or IPython/Jupyter, again, except for special cases.
>
> *Consequences*
>
> The browser world continues to develop at a rapid pace, but I see little
> advantage in trying to do Leo in a browser.  The security implications
> alone seem daunting.  Instead, I'll continue to focus on the python world,
> looking for continuous incremental improvement.
>
> Reading the user docs has already given me several ideas:
>
> - As Kent (and others) have requested, it would be good to support
> @language python2 and @language python3, to support specific interpreters.
>
> - Ctrl-B (execute-script) should execute languages other than python in
> separate processes. This includes JavaScript.  And Ctrl-B should could also
> be extended to run python scripts in a separate process.  This should be
> straightforward.  Leo already has the infrastructure to run pylint in a
> separate process.
>
> - It *might* be good to supply arguments to scripts, as in org mode
> #+BEGIN_SRC blocks.
>
> - Providing some IPython/Jupyter features will almost certainly be a good
> idea.
>
> *Conclusions*
>
> For the foreseeable future Leo will remain a desktop app, based on Python,
>
> My focus will be on better cooperation and competition with org mode and
> IPython/Jupyter.
>
> 2018 may see the completion of the work discussed here.  I have no plans
> to stop working on Leo.
>
> 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.
>

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

The plan for the near future

[Edward K. Ream]

On vacation I kept thoughts about near-term plans in the background.  When 
I returned the plan became clear.

*Goals*

1. Make it easier for users to switch between Leo and other programs, 
especially Leo and Emacs (org mode) and Jupyter. See #477 
.

2. Provide all significant features of org mode and Jupyter within Leo. See 
#414 .

I considered a client/server architecture for Leo. I am going to reject 
that approach for now.  Jupyter provides those capabilities if desired.

*Actions*

My plan is simple: to read the *user* docs for org mode, ipython and 
jupyter, looking for features that Leo presently lacks.  There is little 
point in reading *dev* docs for these programs, except in special 
circumstances.  Leo's "ecology" is significantly richer than other IDE's, 
so the implementation of features within Leo will be quite different from 
in Emacs or IPython/Jupyter, again, except for special cases.

*Consequences*

The browser world continues to develop at a rapid pace, but I see little 
advantage in trying to do Leo in a browser.  The security implications 
alone seem daunting.  Instead, I'll continue to focus on the python world, 
looking for continuous incremental improvement.

Reading the user docs has already given me several ideas:

- As Kent (and others) have requested, it would be good to support 
@language python2 and @language python3, to support specific interpreters.

- Ctrl-B (execute-script) should execute languages other than python in 
separate processes. This includes JavaScript.  And Ctrl-B should could also 
be extended to run python scripts in a separate process.  This should be 
straightforward.  Leo already has the infrastructure to run pylint in a 
separate process.

- It *might* be good to supply arguments to scripts, as in org mode 
#+BEGIN_SRC blocks.

- Providing some IPython/Jupyter features will almost certainly be a good 
idea. 

*Conclusions*

For the foreseeable future Leo will remain a desktop app, based on Python, 

My focus will be on better cooperation and competition with org mode and 
IPython/Jupyter.

2018 may see the completion of the work discussed here.  I have no plans to 
stop working on Leo.

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.