Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Allen Barker]

On 3/16/20 1:03 AM, Richard Kimberly Heck wrote:

On 3/13/20 2:32 PM, Allen Barker wrote:


One thing I noticed is that after an external edit to a text inset
(both Flex and ERT) in either gvim or gedit, where the file is saved
(even if the text is not changed), the inset has an extra newline
added to the end after the inset-end-edit.


I see that, too. I am not sure what is causing it.


It's happening because on a write Vim and gview by default
always add an EOL at the end of a file if there isn't one (at
least on Posix systems).  Lyx doesn't use that Posix
convention, at least in this case.  If the last line in the
inset contains text then the file Lyx writes does not end in
EOL and Vim gives a warning notification [noeol] at the
bottom.

Adding this line in .vimrc:

   set nofixendofline

makes the inset editing work as expected for insets which
don't end in newline.

But if the inset ends in newline then that last (empty) line
doesn't show up in the editor for editing whether or not that
option is set.

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline


The code fix that I'm working with now is to replace this line (609) in
src/insets/InsetCollapsible.cpp:

    theFormats().edit(buffer(), tempfilename, format);

with this:

    if (cmd.argument() == "noeditor")
   cur.message(from_utf8(name));
    else
   theFormats().edit(buffer(), tempfilename, format);

That seems to work (assuming I haven't overlooked something) and creates
the parameter "noeditor" for the inset-edit LFUN which just returns the
temporary filename.

The question is then whether that is good from an API viewpoint.


It seems all right, I think.



The inset-edit LFUN already takes a filename parameter, but that
parameter is
not respected in the InsetCollapsible::doDispatch routine anyway.  In
the case of collapsible insets a temp file is always used.


The filename is only used with 'file based' insets, or so it says in
LyXAction.cpp.
Those are cases like the bibliography inset where it would make sense to
specify
a filename. So, in the case of collapsible insets, it doesn't, and so
"noeditor" won't
yield any conflict.


After I test the code some more I'll put an enhancement request
ticket on the bug tracker with the proposed patch.


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 3/13/20 2:32 PM, Allen Barker wrote:
> On 3/10/20 10:05 PM, Richard Kimberly Heck wrote:
>> On 3/10/20 9:24 PM, Allen Barker wrote:
>>> On 6/25/19 12:42 PM, Richard Kimberly Heck wrote:
 Thanks for these ideas. I'm not an R user myself, though, so it
 would be
 helpful to me if you could explain what it is you are trying to
 achieve.
 It's best when thinking through issues like this one to separate the
 problem from the solution. What's below seems to be a mix between
 those.

 One reason I ask about this is that LyX 2.3.3 has added the ability to
 edit the LaTeX preamble or the contents of an ERT inset using some
 external editor. LyX 2.4.0 will extend that to 'collapsible' insets
 generally, controlled by a layout tag EditExternal. So by activating
 this tag for the appropriate kind of inset, you can edit its
 contents in
 whatever editor you define for its format. That seems, if I'm reading
 you right, to give you much of what you want---and to use your
 editor of
 choice.
>>>
>>> I'm very interested to hear about the new 2.4.0 editable insets.  As I
>>> mentioned in my other recent posting in a related thread, I ran into
>>> this
>>> same problem a few years back when I implemented my Lyx Notebook
>>> project.
>>> I had to resort to an ugly kludge to get the inset text.
>>>
>>> Is this new feature already implemented in the 2.4.0 code in the git
>>> repo?  Does it work for Flex insets, too?  If so, how do you enable it
>>> for a Flex inset?
>>
>> Yes. Just do:
>>
>>  EditExternal 1
>>
>> in the inset layout to enable it. The inset should then have a context
>> menu item allowing it to be edited, as ERT insets do.
>>
>>> I assume this uses the inset-edit LFUN, which opens an editor on the
>>> text.  I'm not sure how to set the particular editor to use, though.
>>
>> This uses the editor defined in Preferences for the document's output
>> format.
>
> I messed around with the feature a bit, and it's a nice addition.  As you
> mentioned in another posting, it would be nice to have a way to define a
> particular editor to be used to edit certain insets.  As it is it seems
> that everything will be edited by default as "LaTeX (plain)".
>
> One thing I noticed is that after an external edit to a text inset
> (both Flex and ERT) in either gvim or gedit, where the file is saved
> (even if the text is not changed), the inset has an extra newline
> added to the end after the inset-end-edit.

I see that, too. I am not sure what is causing it.


>>> It would be nice to have an option to have the LFUN just return the
>>> filename rather than running an editor process on the file.
>>> Sometimes users might want to edit the inset text and sometimes you
>>> might want to process the text with your already-running program
>>> (Lyx Notebook uses Lyx server pipes).
>>
>> There must be some reasonable way to do that. Can't be too hard.
>
> The code fix that I'm working with now is to replace this line (609) in
> src/insets/InsetCollapsible.cpp:
>
>    theFormats().edit(buffer(), tempfilename, format);
>
> with this:
>
>    if (cmd.argument() == "noeditor")
>   cur.message(from_utf8(name));
>    else
>   theFormats().edit(buffer(), tempfilename, format);
>
> That seems to work (assuming I haven't overlooked something) and creates
> the parameter "noeditor" for the inset-edit LFUN which just returns the
> temporary filename.
>
> The question is then whether that is good from an API viewpoint.  

It seems all right, I think.


> The inset-edit LFUN already takes a filename parameter, but that
> parameter is
> not respected in the InsetCollapsible::doDispatch routine anyway.  In
> the case of collapsible insets a temp file is always used.

The filename is only used with 'file based' insets, or so it says in
LyXAction.cpp.
Those are cases like the bibliography inset where it would make sense to
specify
a filename. So, in the case of collapsible insets, it doesn't, and so
"noeditor" won't
yield any conflict.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Allen Barker]

On 3/11/20 9:45 AM, Scott Kostyshak wrote:

On Tue, Mar 10, 2020 at 10:05:58PM -0400, Richard Kimberly Heck wrote:

On 3/10/20 9:24 PM, Allen Barker wrote:

It would be nice to have an option to have the LFUN just return the
filename rather than running an editor process on the file.
Sometimes users might want to edit the inset text and sometimes you
might want to process the text with your already-running program
(Lyx Notebook uses Lyx server pipes).


There must be some reasonable way to do that. Can't be too hard.


I'm not suggesting the following as a solution, but perhaps it can serve
as a workaround: it would be easy to specify a command called
"editor-wrapper" that checks if the editor is running and if so uses
whatever mechanism that editor uses to open a file in a running instance
of the program; and if it is not running it starts the program as usual.


In this case the running program isn't an editor but the Lyx
Notebook Python program, communicating over Lyx server pipes with Lyx.
I messed around with a simple mock-editor script that writes the
filename to a file, which works.  The Python code would then have to
read the filename from that file.  That would work, but the process
communication becomes a little Rube Goldberg.  Users would also have
to set that mock editor for any output format type that is selected.

For code insets you'd ideally like the user be able to edit them the
normal way as text, via the right-click menu, even when Lyx Notebook
is running.  But you'd also want Lyx Notebook to be able to
set or obtain the filename via Lyx server in order to modify it
directly.


On a separate note, I don't know if it would be useful for your use case
but another feature that would be useful for the case of the knitr
module would be the possibility to open *all* knitr chunks in a separate
file. The chunks could be separated by comments, and that's how LyX
would know how to import edits back to which insets. Currently it's
necessary to go to File > Export > R, do debugging there, then port the
fix back to the .lyx file. I'm not sure how complicated this feature
would be, but I log it here just in case.


I like the idea of editing all the insets at once in a comment-separated
file.  I might try to implement that in Lyx Notebook if I get motivated.
Given the current LFUNs that is in some ways easier to do over Lyx server
pipes than editing just the current cell.  As a workaround to getting the
text from the cells I am already writing out the file and then parsing
through it to extract the relevant chunks (and even experimentally to
batch-evaluate all the chunks).  So it seems like Lyx could temporarily
be made non-editable while an editor is opened on the combined cells
of a given type and then the modified Lyx file could be reloaded.  (Lyx
apparently now always immediately asks about reloading when the current
file is modified, which isn't too bad in this case but it might be nice
to have an LFUN to turn that off and on.  I saw the related ticket
at https://www.lyx.org/trac/ticket/10997.)

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Allen Barker]

On 3/10/20 10:05 PM, Richard Kimberly Heck wrote:

On 3/10/20 9:24 PM, Allen Barker wrote:

On 6/25/19 12:42 PM, Richard Kimberly Heck wrote:

Thanks for these ideas. I'm not an R user myself, though, so it would be
helpful to me if you could explain what it is you are trying to achieve.
It's best when thinking through issues like this one to separate the
problem from the solution. What's below seems to be a mix between those.

One reason I ask about this is that LyX 2.3.3 has added the ability to
edit the LaTeX preamble or the contents of an ERT inset using some
external editor. LyX 2.4.0 will extend that to 'collapsible' insets
generally, controlled by a layout tag EditExternal. So by activating
this tag for the appropriate kind of inset, you can edit its contents in
whatever editor you define for its format. That seems, if I'm reading
you right, to give you much of what you want---and to use your editor of
choice.


I'm very interested to hear about the new 2.4.0 editable insets.  As I
mentioned in my other recent posting in a related thread, I ran into this
same problem a few years back when I implemented my Lyx Notebook project.
I had to resort to an ugly kludge to get the inset text.

Is this new feature already implemented in the 2.4.0 code in the git
repo?  Does it work for Flex insets, too?  If so, how do you enable it
for a Flex inset?


Yes. Just do:

     EditExternal 1

in the inset layout to enable it. The inset should then have a context
menu item allowing it to be edited, as ERT insets do.


I assume this uses the inset-edit LFUN, which opens an editor on the
text.  I'm not sure how to set the particular editor to use, though.


This uses the editor defined in Preferences for the document's output
format.


I messed around with the feature a bit, and it's a nice addition.  As you
mentioned in another posting, it would be nice to have a way to define a
particular editor to be used to edit certain insets.  As it is it seems
that everything will be edited by default as "LaTeX (plain)".

One thing I noticed is that after an external edit to a text inset
(both Flex and ERT) in either gvim or gedit, where the file is saved
(even if the text is not changed), the inset has an extra newline
added to the end after the inset-end-edit.


It would be nice to have an option to have the LFUN just return the
filename rather than running an editor process on the file.
Sometimes users might want to edit the inset text and sometimes you
might want to process the text with your already-running program
(Lyx Notebook uses Lyx server pipes).


There must be some reasonable way to do that. Can't be too hard.


The code fix that I'm working with now is to replace this line (609) in
src/insets/InsetCollapsible.cpp:

   theFormats().edit(buffer(), tempfilename, format);

with this:

   if (cmd.argument() == "noeditor")
  cur.message(from_utf8(name));
   else
  theFormats().edit(buffer(), tempfilename, format);

That seems to work (assuming I haven't overlooked something) and creates
the parameter "noeditor" for the inset-edit LFUN which just returns the
temporary filename.

The question is then whether that is good from an API viewpoint.  The
inset-edit LFUN already takes a filename parameter, but that parameter is
not respected in the InsetCollapsible::doDispatch routine anyway.  In
the case of collapsible insets a temp file is always used.


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Scott Kostyshak]

On Wed, Mar 11, 2020 at 10:05:10AM -0400, Richard Kimberly Heck wrote:
> On 3/11/20 9:45 AM, Scott Kostyshak wrote:
> > On Tue, Mar 10, 2020 at 10:05:58PM -0400, Richard Kimberly Heck wrote:
> >> On 3/10/20 9:24 PM, Allen Barker wrote:
> >>> It would be nice to have an option to have the LFUN just return the
> >>> filename rather than running an editor process on the file.
> >>> Sometimes users might want to edit the inset text and sometimes you
> >>> might want to process the text with your already-running program
> >>> (Lyx Notebook uses Lyx server pipes).
> >> There must be some reasonable way to do that. Can't be too hard.
> > I'm not suggesting the following as a solution, but perhaps it can serve
> > as a workaround: it would be easy to specify a command called
> > "editor-wrapper" that checks if the editor is running and if so uses
> > whatever mechanism that editor uses to open a file in a running instance
> > of the program; and if it is not running it starts the program as usual.
> >
> > On a separate note, I don't know if it would be useful for your use case
> > but another feature that would be useful for the case of the knitr
> > module would be the possibility to open *all* knitr chunks in a separate
> > file. The chunks could be separated by comments, and that's how LyX
> > would know how to import edits back to which insets. Currently it's
> > necessary to go to File > Export > R, do debugging there, then port the
> > fix back to the .lyx file. I'm not sure how complicated this feature
> > would be, but I log it here just in case.
> 
> In 2.4.0, it should be possible to make chunks editable externally, and
> then you can open each one separately. I didn't actually add this flag.
> You might want to check it out and add it if you think it makes sense.
> It occurs to me that we might also want to have a way to define a
> particular editor to be used to edit certain insets. Now, it will always
> be the editor defined for the document format.
> 
> I'm not sure about opening them all at once. What if you added a new
> inset in the meantime?

One option would be to lock editing of LyX, or of editing of those types
of insets. Another option would be that the exported file would contain
inset identifiers in comments so that LyX would know what goes where.
The comment character would be specified as a layout parameter. This is
getting complicated though, so it will be interesting to see how the
basic feature goes and get feedback on that before thinking of advanced
features.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 3/11/20 9:45 AM, Scott Kostyshak wrote:
> On Tue, Mar 10, 2020 at 10:05:58PM -0400, Richard Kimberly Heck wrote:
>> On 3/10/20 9:24 PM, Allen Barker wrote:
>>> It would be nice to have an option to have the LFUN just return the
>>> filename rather than running an editor process on the file.
>>> Sometimes users might want to edit the inset text and sometimes you
>>> might want to process the text with your already-running program
>>> (Lyx Notebook uses Lyx server pipes).
>> There must be some reasonable way to do that. Can't be too hard.
> I'm not suggesting the following as a solution, but perhaps it can serve
> as a workaround: it would be easy to specify a command called
> "editor-wrapper" that checks if the editor is running and if so uses
> whatever mechanism that editor uses to open a file in a running instance
> of the program; and if it is not running it starts the program as usual.
>
> On a separate note, I don't know if it would be useful for your use case
> but another feature that would be useful for the case of the knitr
> module would be the possibility to open *all* knitr chunks in a separate
> file. The chunks could be separated by comments, and that's how LyX
> would know how to import edits back to which insets. Currently it's
> necessary to go to File > Export > R, do debugging there, then port the
> fix back to the .lyx file. I'm not sure how complicated this feature
> would be, but I log it here just in case.

In 2.4.0, it should be possible to make chunks editable externally, and
then you can open each one separately. I didn't actually add this flag.
You might want to check it out and add it if you think it makes sense.
It occurs to me that we might also want to have a way to define a
particular editor to be used to edit certain insets. Now, it will always
be the editor defined for the document format.

I'm not sure about opening them all at once. What if you added a new
inset in the meantime?

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Scott Kostyshak]

On Tue, Mar 10, 2020 at 10:05:58PM -0400, Richard Kimberly Heck wrote:
> On 3/10/20 9:24 PM, Allen Barker wrote:
> > It would be nice to have an option to have the LFUN just return the
> > filename rather than running an editor process on the file.
> > Sometimes users might want to edit the inset text and sometimes you
> > might want to process the text with your already-running program
> > (Lyx Notebook uses Lyx server pipes).
> 
> There must be some reasonable way to do that. Can't be too hard.

I'm not suggesting the following as a solution, but perhaps it can serve
as a workaround: it would be easy to specify a command called
"editor-wrapper" that checks if the editor is running and if so uses
whatever mechanism that editor uses to open a file in a running instance
of the program; and if it is not running it starts the program as usual.

On a separate note, I don't know if it would be useful for your use case
but another feature that would be useful for the case of the knitr
module would be the possibility to open *all* knitr chunks in a separate
file. The chunks could be separated by comments, and that's how LyX
would know how to import edits back to which insets. Currently it's
necessary to go to File > Export > R, do debugging there, then port the
fix back to the .lyx file. I'm not sure how complicated this feature
would be, but I log it here just in case.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 3/10/20 9:24 PM, Allen Barker wrote:
> On 6/25/19 12:42 PM, Richard Kimberly Heck wrote:
>> Thanks for these ideas. I'm not an R user myself, though, so it would be
>> helpful to me if you could explain what it is you are trying to achieve.
>> It's best when thinking through issues like this one to separate the
>> problem from the solution. What's below seems to be a mix between those.
>>
>> One reason I ask about this is that LyX 2.3.3 has added the ability to
>> edit the LaTeX preamble or the contents of an ERT inset using some
>> external editor. LyX 2.4.0 will extend that to 'collapsible' insets
>> generally, controlled by a layout tag EditExternal. So by activating
>> this tag for the appropriate kind of inset, you can edit its contents in
>> whatever editor you define for its format. That seems, if I'm reading
>> you right, to give you much of what you want---and to use your editor of
>> choice.
>
> I'm very interested to hear about the new 2.4.0 editable insets.  As I
> mentioned in my other recent posting in a related thread, I ran into this
> same problem a few years back when I implemented my Lyx Notebook project.
> I had to resort to an ugly kludge to get the inset text.
>
> Is this new feature already implemented in the 2.4.0 code in the git
> repo?  Does it work for Flex insets, too?  If so, how do you enable it
> for a Flex inset?

Yes. Just do:

    EditExternal 1

in the inset layout to enable it. The inset should then have a context
menu item allowing it to be edited, as ERT insets do.


> I assume this uses the inset-edit LFUN, which opens an editor on the
> text.  I'm not sure how to set the particular editor to use, though.

This uses the editor defined in Preferences for the document's output
format.


> It would be nice to have an option to have the LFUN just return the
> filename rather than running an editor process on the file.
> Sometimes users might want to edit the inset text and sometimes you
> might want to process the text with your already-running program
> (Lyx Notebook uses Lyx server pipes).

There must be some reasonable way to do that. Can't be too hard.


> I also had a few other wish-list LFUNs from back when I implemented
> that program (such as "goto the next inset of a given type").  Perhaps
> I'll post them for discussion in a new thread at some point.  There
> might already be ways to do some of them.

OK!

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Allen Barker]

On 6/25/19 12:42 PM, Richard Kimberly Heck wrote:

Thanks for these ideas. I'm not an R user myself, though, so it would be
helpful to me if you could explain what it is you are trying to achieve.
It's best when thinking through issues like this one to separate the
problem from the solution. What's below seems to be a mix between those.

One reason I ask about this is that LyX 2.3.3 has added the ability to
edit the LaTeX preamble or the contents of an ERT inset using some
external editor. LyX 2.4.0 will extend that to 'collapsible' insets
generally, controlled by a layout tag EditExternal. So by activating
this tag for the appropriate kind of inset, you can edit its contents in
whatever editor you define for its format. That seems, if I'm reading
you right, to give you much of what you want---and to use your editor of
choice.


I'm very interested to hear about the new 2.4.0 editable insets.  As I
mentioned in my other recent posting in a related thread, I ran into this
same problem a few years back when I implemented my Lyx Notebook project.
I had to resort to an ugly kludge to get the inset text.

Is this new feature already implemented in the 2.4.0 code in the git
repo?  Does it work for Flex insets, too?  If so, how do you enable it
for a Flex inset?

I assume this uses the inset-edit LFUN, which opens an editor on the
text.  I'm not sure how to set the particular editor to use, though.

It would be nice to have an option to have the LFUN just return the
filename rather than running an editor process on the file.
Sometimes users might want to edit the inset text and sometimes you
might want to process the text with your already-running program
(Lyx Notebook uses Lyx server pipes).

I also had a few other wish-list LFUNs from back when I implemented
that program (such as "goto the next inset of a given type").  Perhaps
I'll post them for discussion in a new thread at some point.  There
might already be ways to do some of them.




--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 6/25/19 4:24 PM, Jason Sun wrote:
> One of the reason of embedding a terminal to basically ensure the
> jupyter_client is running in the backend. Say I want to write a stats
> book in latex that contains a lot of python and R code. After
> executing one piece of code, I might want to keep all the variables so
> that I can refer it later. Currently, I cannot do this in any special
> latex editor including lyx without compiling the tex file first. I
> could do it in vim or emacs or vscode because they are general purpose
> editors. However, writing latex in them is not a very pleasant
> experience for me personally. 
>
> That is the reason why I came with this idea of building a bridge
> between LyX and Jupyter to combine their powers. I thought about bring
> LyX to jupyter, but it is extremely difficult since Qt has limited
> support for web. Even if we take a step back to use python as a glue,
> we still need to port the whole lyx implementation to Python and use
> PySide2. It is by no means easy. Plus, PySide2 is relatively new. It's
> hard to predict the quality of the ported work.
>
> So the only viable option left, in my opinion, is to bring Jupyter to
> LyX.

I'm not familiar with Jupyter beyond my just-now explorations on the
web, so most of my questions and comments are probably naive. But have
you looked into external templates for LyX? That's another way we have
to interface with external programs. There's also the Preview inset,
which can be used to compile and embed almost anything into LyX.

The problem of persistent variables is maybe more complicated.

Anyway, I don't mean to be discouraging. But it always seems best to
spend a lot of time thinking about design issues before coding too much.
I've learned that the hard way.

Riki



>
> On Tue, Jun 25, 2019 at 4:10 PM Jason Sun  > wrote:
>
> So the overall question is: Why not instead figure out how to make LyX
> work well WITH jupyter notebook?
>
> One way to make it work well with jupyter notebook is to let it
> communicate with jupyter_client. CS and Stats community uses
> Jupyter and Latex a lot, but the two don't work well together. LyX
> has the advantage of being one of the best Latex editor. It would
> be kind of cool to let it have jupyter's capabilities. LyX already
> has knitr support. So it could takes a bit of extra work to extend
> it to be an interface to jupyter_client or jupyter console. One of
> the disadvantage of Jupyter Notebook is its latex capabilities. Cf
> this discussion: https://github.com/jupyter/notebook/issues/1604
>
> On Tue, Jun 25, 2019 at 3:50 PM Richard Kimberly Heck
> mailto:rikih...@lyx.org>> wrote:
>
> On 6/25/19 2:57 PM, Jason Sun wrote:
> > I have attached a prototype in the screenshots in the
> attachment. 
> >
> > This is what I am trying to achieve - combining the
> computing power of
> > jupyter and the latex power of LyX. It is still in early
> stages. More
> > testing and further extension could easily be developed.
> Ideally, one
> > could do the following few things with this feature
> >
> > 1. Edit the ERT box inside a code editor that is embeded in LyX
> > powered by QScintilla2 with syntax highlighting and clangformat.
>
> Why is it an advantage to be able to edit the code inside LyX, as
> opposed to in an external editor of one's own choosing? We
> have tended
> to resist embedding things inside LyX that can be done just as
> well, or
> better, by an external program devoted to the task. For
> example, it was
> once suggested that LyX should have an embedded BibTeX editor.
> But why?
> Better, we thought, just to allow databases to be opened in
> external
> programs and edited there.
>
>
> > 2. Copy and paste the code in the ERT or codeListing  in the lyx
> > editing pane or the code in the embeded code editor  and
> execute them
> > in the embeded jupyter-console and get output(plots)
> displayed in the
> > console(a separate plot pane) inside LyX.
>
> Same question, basically.
>
>
> > I looked at the current 2.4 dev source files, the design for
> external
> > editor is a good idea. However, it does not seem to close
> the external
> > editor properly. At least I tried on vscode and atom.
>
> We do not close the external editor ourselves. The user might
> want to
> leave it open for some reason. (E.g., there might be other
> files open in
> the editor.)
>
>
> > I also think that the tmp file approach could be internalized.
>
> Not sure what you mean here.
>
>
> > The end goal is to enable LyX be stronger if not as strong
> as jupyter
>

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Jason Sun]

One of the reason of embedding a terminal to basically ensure the
jupyter_client is running in the backend. Say I want to write a stats book
in latex that contains a lot of python and R code. After executing one
piece of code, I might want to keep all the variables so that I can refer
it later. Currently, I cannot do this in any special latex editor including
lyx without compiling the tex file first. I could do it in vim or emacs or
vscode because they are general purpose editors. However, writing latex in
them is not a very pleasant experience for me personally.

That is the reason why I came with this idea of building a bridge between
LyX and Jupyter to combine their powers. I thought about bring LyX to
jupyter, but it is extremely difficult since Qt has limited support for
web. Even if we take a step back to use python as a glue, we still need to
port the whole lyx implementation to Python and use PySide2. It is by no
means easy. Plus, PySide2 is relatively new. It's hard to predict the
quality of the ported work.

So the only viable option left, in my opinion, is to bring Jupyter to LyX.



On Tue, Jun 25, 2019 at 4:10 PM Jason Sun  wrote:

> So the overall question is: Why not instead figure out how to make LyX
> work well WITH jupyter notebook?
>
> One way to make it work well with jupyter notebook is to let it
> communicate with jupyter_client. CS and Stats community uses Jupyter and
> Latex a lot, but the two don't work well together. LyX has the advantage of
> being one of the best Latex editor. It would be kind of cool to let it have
> jupyter's capabilities. LyX already has knitr support. So it could takes a
> bit of extra work to extend it to be an interface to jupyter_client or
> jupyter console. One of the disadvantage of Jupyter Notebook is its latex
> capabilities. Cf this discussion:
> https://github.com/jupyter/notebook/issues/1604
>
> On Tue, Jun 25, 2019 at 3:50 PM Richard Kimberly Heck 
> wrote:
>
>> On 6/25/19 2:57 PM, Jason Sun wrote:
>> > I have attached a prototype in the screenshots in the attachment.
>> >
>> > This is what I am trying to achieve - combining the computing power of
>> > jupyter and the latex power of LyX. It is still in early stages. More
>> > testing and further extension could easily be developed. Ideally, one
>> > could do the following few things with this feature
>> >
>> > 1. Edit the ERT box inside a code editor that is embeded in LyX
>> > powered by QScintilla2 with syntax highlighting and clangformat.
>>
>> Why is it an advantage to be able to edit the code inside LyX, as
>> opposed to in an external editor of one's own choosing? We have tended
>> to resist embedding things inside LyX that can be done just as well, or
>> better, by an external program devoted to the task. For example, it was
>> once suggested that LyX should have an embedded BibTeX editor. But why?
>> Better, we thought, just to allow databases to be opened in external
>> programs and edited there.
>>
>>
>> > 2. Copy and paste the code in the ERT or codeListing  in the lyx
>> > editing pane or the code in the embeded code editor  and execute them
>> > in the embeded jupyter-console and get output(plots) displayed in the
>> > console(a separate plot pane) inside LyX.
>>
>> Same question, basically.
>>
>>
>> > I looked at the current 2.4 dev source files, the design for external
>> > editor is a good idea. However, it does not seem to close the external
>> > editor properly. At least I tried on vscode and atom.
>>
>> We do not close the external editor ourselves. The user might want to
>> leave it open for some reason. (E.g., there might be other files open in
>> the editor.)
>>
>>
>> > I also think that the tmp file approach could be internalized.
>>
>> Not sure what you mean here.
>>
>>
>> > The end goal is to enable LyX be stronger if not as strong as jupyter
>> > notebook.
>> So the overall question is: Why not instead figure out how to make LyX
>> work well WITH jupyter notebook?
>>
>> Riki
>>
>>
>>
>
> --
> *Daqian Sun*
>
> *Tel:607-379-5149*
> *Department of Mathematics *
> *Department of Economics*
> *Cornell University*
>
>

-- 
*Daqian Sun*

*Tel:607-379-5149*
*Department of Mathematics *
*Department of Economics*
*Cornell University*

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Jason Sun]

So the overall question is: Why not instead figure out how to make LyX
work well WITH jupyter notebook?

One way to make it work well with jupyter notebook is to let it communicate
with jupyter_client. CS and Stats community uses Jupyter and Latex a lot,
but the two don't work well together. LyX has the advantage of being one of
the best Latex editor. It would be kind of cool to let it have jupyter's
capabilities. LyX already has knitr support. So it could takes a bit of
extra work to extend it to be an interface to jupyter_client or jupyter
console. One of the disadvantage of Jupyter Notebook is its latex
capabilities. Cf this discussion:
https://github.com/jupyter/notebook/issues/1604

On Tue, Jun 25, 2019 at 3:50 PM Richard Kimberly Heck 
wrote:

> On 6/25/19 2:57 PM, Jason Sun wrote:
> > I have attached a prototype in the screenshots in the attachment.
> >
> > This is what I am trying to achieve - combining the computing power of
> > jupyter and the latex power of LyX. It is still in early stages. More
> > testing and further extension could easily be developed. Ideally, one
> > could do the following few things with this feature
> >
> > 1. Edit the ERT box inside a code editor that is embeded in LyX
> > powered by QScintilla2 with syntax highlighting and clangformat.
>
> Why is it an advantage to be able to edit the code inside LyX, as
> opposed to in an external editor of one's own choosing? We have tended
> to resist embedding things inside LyX that can be done just as well, or
> better, by an external program devoted to the task. For example, it was
> once suggested that LyX should have an embedded BibTeX editor. But why?
> Better, we thought, just to allow databases to be opened in external
> programs and edited there.
>
>
> > 2. Copy and paste the code in the ERT or codeListing  in the lyx
> > editing pane or the code in the embeded code editor  and execute them
> > in the embeded jupyter-console and get output(plots) displayed in the
> > console(a separate plot pane) inside LyX.
>
> Same question, basically.
>
>
> > I looked at the current 2.4 dev source files, the design for external
> > editor is a good idea. However, it does not seem to close the external
> > editor properly. At least I tried on vscode and atom.
>
> We do not close the external editor ourselves. The user might want to
> leave it open for some reason. (E.g., there might be other files open in
> the editor.)
>
>
> > I also think that the tmp file approach could be internalized.
>
> Not sure what you mean here.
>
>
> > The end goal is to enable LyX be stronger if not as strong as jupyter
> > notebook.
> So the overall question is: Why not instead figure out how to make LyX
> work well WITH jupyter notebook?
>
> Riki
>
>
>

-- 
*Daqian Sun*

*Tel:607-379-5149*
*Department of Mathematics *
*Department of Economics*
*Cornell University*

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

On 6/25/19 2:57 PM, Jason Sun wrote:
> I have attached a prototype in the screenshots in the attachment. 
>
> This is what I am trying to achieve - combining the computing power of
> jupyter and the latex power of LyX. It is still in early stages. More
> testing and further extension could easily be developed. Ideally, one
> could do the following few things with this feature
>
> 1. Edit the ERT box inside a code editor that is embeded in LyX
> powered by QScintilla2 with syntax highlighting and clangformat.

Why is it an advantage to be able to edit the code inside LyX, as
opposed to in an external editor of one's own choosing? We have tended
to resist embedding things inside LyX that can be done just as well, or
better, by an external program devoted to the task. For example, it was
once suggested that LyX should have an embedded BibTeX editor. But why?
Better, we thought, just to allow databases to be opened in external
programs and edited there.


> 2. Copy and paste the code in the ERT or codeListing  in the lyx
> editing pane or the code in the embeded code editor  and execute them
> in the embeded jupyter-console and get output(plots) displayed in the
> console(a separate plot pane) inside LyX.

Same question, basically.


> I looked at the current 2.4 dev source files, the design for external
> editor is a good idea. However, it does not seem to close the external
> editor properly. At least I tried on vscode and atom.

We do not close the external editor ourselves. The user might want to
leave it open for some reason. (E.g., there might be other files open in
the editor.)


> I also think that the tmp file approach could be internalized.

Not sure what you mean here.


> The end goal is to enable LyX be stronger if not as strong as jupyter
> notebook.
So the overall question is: Why not instead figure out how to make LyX
work well WITH jupyter notebook?

Riki

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[William Adams]

For an interesting contrast, please see the document/app mentioned at:

https://email.esm.psu.edu/pipermail/macosx-tex/2019-June/056685.html

LyX being able to author such would be huge.

William

On Tue, Jun 25, 2019 at 2:50 PM Jason Sun  wrote:

> Sorry, forgot to include the list. Here is another iteration:)
>
> I have attached a prototype in the screenshots in the attachment.
>
> This is what I am trying to achieve - combining the computing power of
> jupyter and the latex power of LyX. It is still in early stages. More
> testing and further extension could easily be developed. Ideally, one could
> do the following few things with this feature
>
> 1. Edit the ERT box inside a code editor that is embeded in LyX powered by
> QScintilla2 with syntax highlighting and clangformat.
> 2. Copy and paste the code in the ERT or codeListing  in the lyx editing
> pane or the code in the embeded code editor  and execute them in the
> embeded jupyter-console and get output(plots) displayed in the console(a
> separate plot pane) inside LyX.
> 3. Save a code piece in the embeded code editor to file, or insert them to
> the main LyX workarea with the click of one button.
>
> Now I have embeded successfully a quite powerful terminal (true terminal,
> separate process) inside LyX that allows to me to do some of the things
> listed above. In my opinion, the code editor part is not hard.
>
> I looked at the current 2.4 dev source files, the design for external
> editor is a good idea. However, it does not seem to close the external
> editor properly. At least I tried on vscode and atom. I also think that the
> tmp file approach could be internalized.
>
> The end goal is to enable LyX be stronger if not as strong as jupyter
> notebook.
>
> On Tue, Jun 25, 2019 at 2:40 PM Jason Sun  wrote:
>
>> I have attached a prototype in the screenshots in the attachment.
>>
>> This is want I am trying to achieve - combining the computing power of
>> jupyter and the latex power of LyX. It is still in early stages. More
>> testing and further extension could easily be developed. Ideally, one could
>> do the following few things with this feature
>>
>> 1. Edit the ERT box inside a code editor that is embeded in LyX powered
>> by QScintilla2 with syntax highlighting and clangformat.
>> 2. Copy and paste the code in the ERT or codeListing  in the lyx editing
>> pane or the code in the embeded code editor  and execute them in the
>> embeded jupyter-console and get output(plots) displayed in the console(a
>> separate plot pane) inside LyX.
>> 3. Save a code piece in the embeded code editor to file, or insert them
>> to the main LyX workarea with the click of one button.
>>
>> Now I have embeded successfully a quite powerful terminal (true terminal,
>> separate process) inside LyX that allows to me to do some of the things
>> listed above. In my opinion, the code editor part is not hard.
>>
>> I looked at the current 2.4 dev source files, the design for external
>> editor is a good idea. However, it does not seem to close the external
>> editor properly. At least I tried on vscode and atom. I also think that the
>> tmp file approach could be internalized.
>>
>> The end goal is to enable LyX be stronger if not as strong as jupyter
>> notebook.
>>
>> On Tue, Jun 25, 2019 at 12:42 PM Richard Kimberly Heck 
>> wrote:
>>
>>>
>>> Hi, Jason,
>>>
>>> Thanks for these ideas. I'm not an R user myself, though, so it would be
>>> helpful to me if you could explain what it is you are trying to achieve.
>>> It's best when thinking through issues like this one to separate the
>>> problem from the solution. What's below seems to be a mix between those.
>>>
>>> One reason I ask about this is that LyX 2.3.3 has added the ability to
>>> edit the LaTeX preamble or the contents of an ERT inset using some
>>> external editor. LyX 2.4.0 will extend that to 'collapsible' insets
>>> generally, controlled by a layout tag EditExternal. So by activating
>>> this tag for the appropriate kind of inset, you can edit its contents in
>>> whatever editor you define for its format. That seems, if I'm reading
>>> you right, to give you much of what you want---and to use your editor of
>>> choice.
>>>
>>> Riki
>>>
>>>
>>> On 6/20/19 10:42 AM, Jason Sun wrote:
>>> > I thought about this long and hard. It is possible to extend Lyx's
>>> > functionality beyond the document processer. With the help you pybind
>>> > 11 and Qt5, I think is it possible to implement some of the IDE
>>> > features(think RStudio) in LyX. This would be extremely helpful in
>>> > writing scientific document. Currently, my workflow is to write code
>>> > in VS Code/Emacs and copy and paste everything back and forth between
>>> > LyX and code editor.
>>> >
>>> > * It is not terribly cumbersome. But if we can development LyX into
>>> > something like RStudio, it would definitely save some time.
>>> >
>>> > * Because LyX has support for knitr. Provided the script editor
>>> > QtWidget and console Widget has been 

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Richard Kimberly Heck]

Hi, Jason,

Thanks for these ideas. I'm not an R user myself, though, so it would be
helpful to me if you could explain what it is you are trying to achieve.
It's best when thinking through issues like this one to separate the
problem from the solution. What's below seems to be a mix between those.

One reason I ask about this is that LyX 2.3.3 has added the ability to
edit the LaTeX preamble or the contents of an ERT inset using some
external editor. LyX 2.4.0 will extend that to 'collapsible' insets
generally, controlled by a layout tag EditExternal. So by activating
this tag for the appropriate kind of inset, you can edit its contents in
whatever editor you define for its format. That seems, if I'm reading
you right, to give you much of what you want---and to use your editor of
choice.

Riki


On 6/20/19 10:42 AM, Jason Sun wrote:
> I thought about this long and hard. It is possible to extend Lyx's
> functionality beyond the document processer. With the help you pybind
> 11 and Qt5, I think is it possible to implement some of the IDE
> features(think RStudio) in LyX. This would be extremely helpful in
> writing scientific document. Currently, my workflow is to write code
> in VS Code/Emacs and copy and paste everything back and forth between
> LyX and code editor. 
>
> * It is not terribly cumbersome. But if we can development LyX into
> something like RStudio, it would definitely save some time.
>
> * Because LyX has support for knitr. Provided the script editor
> QtWidget and console Widget has been implemented, it won't be very
> hard to build a communication mechanism between the IDE portion and
> the LyX main buffer&main view portion. This is a little bit like
> Jupyter Console (think IPython), but with much better Latex support. 
>
> My rough idea: 
>
> * I think the GUI and UI design part it not so hard. We could just
> create another ViewSource-like class that inherit DockView but with
> editable text field. As for console portion, there are quite a few
> example QtConsole, are we could develop our own wheel. I remember in
> my undergrad OS class. the first project was to implement a
> terminal-ish stuff. As far as I am concerned it is not terribly
> difficult as long as the signals child processes are handled right. 
>
> * The major work should be in the building a python repl inside LyX. I
> think LyX has its own Python for some of the scripting procedures, but
> it is not ideal to use this one. The better solution, IMO, is to
> enable loading the Python Interpreter the user assigned. This gives a
> larger flexibility for various reasons (say, some user might want to
> use TensorFlow. This would be greatly helpful). 
>
> * with pybind11, it is not really hard to open up a python interpreter
> inside c++ applications. The developers of pybind11 gave various
> examples on how to do it. Moreover, pybind11 is a header only library,
> which makes it easy to be built into other applications.
>
>
> These are my thoughts so far. Would be nice to hear some of your ideas
> on this. 
>
>
> Jason Sun
> Cornell University 

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Jason Sun]

it seems a better idea is to just use the jupyter_client and develop a new
Jupyter DockView in LyX. The jupyter console does not play well with python
subprocess.

On Thu, Jun 20, 2019 at 3:27 PM Jason Sun  wrote:

> I am trying to embed the jupyter console into the current LyX 2.3.2
> branch. It seems doable. There is a jupyter qtconsole but it uses pyqt
> which makes it cumbersome to migrate to C++Qt, which LyX uses. So I wanna
> spend some time  in developing a persistent DockView Widget in which embeds
> the jupyter console with the help of pybind11. It might be a long shot,
> though. To get it working on Windows might take some doing, but in Linux or
> Mac this could be easier.
>
> On Thu, Jun 20, 2019 at 2:52 PM William Adams 
> wrote:
>
>> I'd just like to note that I really like this idea, and would really love
>> to see it happen --- I tried to use Jupyter Notebook a while back, but got
>> bogged down for various reasons, and having its functionalities as a
>> stand-alone desktop app which would make nice PDFs would suit my needs
>> quite nicely.
>>
>> On Thu, Jun 20, 2019 at 10:42 AM Jason Sun  wrote:
>>
>>> I thought about this long and hard. It is possible to extend Lyx's
>>> functionality beyond the document processer. With the help you pybind 11
>>> and Qt5, I think is it possible to implement some of the IDE features(think
>>> RStudio) in LyX. This would be extremely helpful in writing scientific
>>> document. Currently, my workflow is to write code in VS Code/Emacs and copy
>>> and paste everything back and forth between LyX and code editor.
>>>
>>> * It is not terribly cumbersome. But if we can development LyX into
>>> something like RStudio, it would definitely save some time.
>>>
>>> * Because LyX has support for knitr. Provided the script editor QtWidget
>>> and console Widget has been implemented, it won't be very hard to build a
>>> communication mechanism between the IDE portion and the LyX main
>>> buffer&main view portion. This is a little bit like Jupyter Console (think
>>> IPython), but with much better Latex support.
>>>
>>> My rough idea:
>>>
>>> * I think the GUI and UI design part it not so hard. We could just
>>> create another ViewSource-like class that inherit DockView but with
>>> editable text field. As for console portion, there are quite a few example
>>> QtConsole, are we could develop our own wheel. I remember in my undergrad
>>> OS class. the first project was to implement a terminal-ish stuff. As far
>>> as I am concerned it is not terribly difficult as long as the signals child
>>> processes are handled right.
>>>
>>> * The major work should be in the building a python repl inside LyX. I
>>> think LyX has its own Python for some of the scripting procedures, but it
>>> is not ideal to use this one. The better solution, IMO, is to enable
>>> loading the Python Interpreter the user assigned. This gives a larger
>>> flexibility for various reasons (say, some user might want to use
>>> TensorFlow. This would be greatly helpful).
>>>
>>> * with pybind11, it is not really hard to open up a python interpreter
>>> inside c++ applications. The developers of pybind11 gave various examples
>>> on how to do it. Moreover, pybind11 is a header only library, which makes
>>> it easy to be built into other applications.
>>>
>>>
>>> These are my thoughts so far. Would be nice to hear some of your ideas
>>> on this.
>>>
>>>
>>> Jason Sun
>>> Cornell University
>>>
>>
>
> --
> *Daqian Sun*
>
> *Tel:607-379-5149*
> *Department of Mathematics *
> *Department of Economics*
> *Cornell University*
>
>

-- 
*Daqian Sun*

*Tel:607-379-5149*
*Department of Mathematics *
*Department of Economics*
*Cornell University*

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[Jason Sun]

I am trying to embed the jupyter console into the current LyX 2.3.2 branch.
It seems doable. There is a jupyter qtconsole but it uses pyqt which makes
it cumbersome to migrate to C++Qt, which LyX uses. So I wanna spend some
time  in developing a persistent DockView Widget in which embeds the
jupyter console with the help of pybind11. It might be a long shot, though.
To get it working on Windows might take some doing, but in Linux or Mac
this could be easier.

On Thu, Jun 20, 2019 at 2:52 PM William Adams 
wrote:

> I'd just like to note that I really like this idea, and would really love
> to see it happen --- I tried to use Jupyter Notebook a while back, but got
> bogged down for various reasons, and having its functionalities as a
> stand-alone desktop app which would make nice PDFs would suit my needs
> quite nicely.
>
> On Thu, Jun 20, 2019 at 10:42 AM Jason Sun  wrote:
>
>> I thought about this long and hard. It is possible to extend Lyx's
>> functionality beyond the document processer. With the help you pybind 11
>> and Qt5, I think is it possible to implement some of the IDE features(think
>> RStudio) in LyX. This would be extremely helpful in writing scientific
>> document. Currently, my workflow is to write code in VS Code/Emacs and copy
>> and paste everything back and forth between LyX and code editor.
>>
>> * It is not terribly cumbersome. But if we can development LyX into
>> something like RStudio, it would definitely save some time.
>>
>> * Because LyX has support for knitr. Provided the script editor QtWidget
>> and console Widget has been implemented, it won't be very hard to build a
>> communication mechanism between the IDE portion and the LyX main
>> buffer&main view portion. This is a little bit like Jupyter Console (think
>> IPython), but with much better Latex support.
>>
>> My rough idea:
>>
>> * I think the GUI and UI design part it not so hard. We could just create
>> another ViewSource-like class that inherit DockView but with editable text
>> field. As for console portion, there are quite a few example QtConsole, are
>> we could develop our own wheel. I remember in my undergrad OS class. the
>> first project was to implement a terminal-ish stuff. As far as I am
>> concerned it is not terribly difficult as long as the signals child
>> processes are handled right.
>>
>> * The major work should be in the building a python repl inside LyX. I
>> think LyX has its own Python for some of the scripting procedures, but it
>> is not ideal to use this one. The better solution, IMO, is to enable
>> loading the Python Interpreter the user assigned. This gives a larger
>> flexibility for various reasons (say, some user might want to use
>> TensorFlow. This would be greatly helpful).
>>
>> * with pybind11, it is not really hard to open up a python interpreter
>> inside c++ applications. The developers of pybind11 gave various examples
>> on how to do it. Moreover, pybind11 is a header only library, which makes
>> it easy to be built into other applications.
>>
>>
>> These are my thoughts so far. Would be nice to hear some of your ideas on
>> this.
>>
>>
>> Jason Sun
>> Cornell University
>>
>

-- 
*Daqian Sun*

*Tel:607-379-5149*
*Department of Mathematics *
*Department of Economics*
*Cornell University*

Re: Path to extending Lyx to a full featured Jupyter-like IDE

[William Adams]

I'd just like to note that I really like this idea, and would really love
to see it happen --- I tried to use Jupyter Notebook a while back, but got
bogged down for various reasons, and having its functionalities as a
stand-alone desktop app which would make nice PDFs would suit my needs
quite nicely.

On Thu, Jun 20, 2019 at 10:42 AM Jason Sun  wrote:

> I thought about this long and hard. It is possible to extend Lyx's
> functionality beyond the document processer. With the help you pybind 11
> and Qt5, I think is it possible to implement some of the IDE features(think
> RStudio) in LyX. This would be extremely helpful in writing scientific
> document. Currently, my workflow is to write code in VS Code/Emacs and copy
> and paste everything back and forth between LyX and code editor.
>
> * It is not terribly cumbersome. But if we can development LyX into
> something like RStudio, it would definitely save some time.
>
> * Because LyX has support for knitr. Provided the script editor QtWidget
> and console Widget has been implemented, it won't be very hard to build a
> communication mechanism between the IDE portion and the LyX main
> buffer&main view portion. This is a little bit like Jupyter Console (think
> IPython), but with much better Latex support.
>
> My rough idea:
>
> * I think the GUI and UI design part it not so hard. We could just create
> another ViewSource-like class that inherit DockView but with editable text
> field. As for console portion, there are quite a few example QtConsole, are
> we could develop our own wheel. I remember in my undergrad OS class. the
> first project was to implement a terminal-ish stuff. As far as I am
> concerned it is not terribly difficult as long as the signals child
> processes are handled right.
>
> * The major work should be in the building a python repl inside LyX. I
> think LyX has its own Python for some of the scripting procedures, but it
> is not ideal to use this one. The better solution, IMO, is to enable
> loading the Python Interpreter the user assigned. This gives a larger
> flexibility for various reasons (say, some user might want to use
> TensorFlow. This would be greatly helpful).
>
> * with pybind11, it is not really hard to open up a python interpreter
> inside c++ applications. The developers of pybind11 gave various examples
> on how to do it. Moreover, pybind11 is a header only library, which makes
> it easy to be built into other applications.
>
>
> These are my thoughts so far. Would be nice to hear some of your ideas on
> this.
>
>
> Jason Sun
> Cornell University
>