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