Re: Playing well with other apps, tools and languages

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

Re: Rendering math in Leo

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,

Re: Merging leo_edit_pane into master?

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

Re: attrib_edit doesn't seem to work

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.

Re: The plan for the near future

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

Re: The plan for the near future

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

Merging leo_edit_pane into master?

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,

Re: attrib_edit doesn't seem to work

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

Re: attrib_edit doesn't seem to work

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

Changes to g.Debugging functions

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

Re: attrib_edit doesn't seem to work

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

Re: The plan for the near future

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

Re: attrib_edit doesn't seem to work

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

Re: The plan for the near future

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,

Re: The plan for the near future

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

The plan for the near future

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