Re^3: Hacking a source filter into the #! line

Certainly. I'm going to be doing quite a bit of writing code and thoughts related to the code over the next few months. However, my solution will be to keep the code and thoughts in separate files, and scatter "include" tags in the thoughts, so that they can be "compiled" into a single document.

toby döt ink

Comment on Re^3: Hacking a source filter into the #! line

Replies are listed 'Best First'.
Re^4: Hacking a source filter into the #! line by dcmertens (Scribe) on Jul 24, 2014 at 17:20 UTC
One of the really nice things about my source filter is that it converts math inset strings into Perl-acceptable barewords. This means I can use subscripts, superscripts, decorations, and other general math symbols in my variable and function names. LyX renders these using standard TeXish math typography, so my variable and function names are visually concise and descriptive. In the end, this means that you and I have slightly different use situation. I plan on simply reading my ideas and code within the LyX editor itself. It can produce a PDF for me, but I don't plan to use that to review my code. I use that to read through the results, with small references to the code. (I often place the bulk of the code in non-rendered Note blocks within LyX.) This whole idea sprang from a back-and-forth experiment in which I would write up my ideas in a LyX document, then hack an implementation of the idea in Perl, then return to the document and write up my analysis and next ideas, then hack away. I found this to be rather disjointed.	[reply]

Replies are listed 'Best First'.

Re^4: Hacking a source filter into the #! line
by dcmertens (Scribe) on Jul 24, 2014 at 17:20 UTC

One of the really nice things about my source filter is that it converts math inset strings into Perl-acceptable barewords. This means I can use subscripts, superscripts, decorations, and other general math symbols in my variable and function names. LyX renders these using standard TeXish math typography, so my variable and function names are visually concise and descriptive.

In the end, this means that you and I have slightly different use situation. I plan on simply reading my ideas and code within the LyX editor itself. It can produce a PDF for me, but I don't plan to use that to review my code. I use that to read through the results, with small references to the code. (I often place the bulk of the code in non-rendered Note blocks within LyX.)

This whole idea sprang from a back-and-forth experiment in which I would write up my ideas in a LyX document, then hack an implementation of the idea in Perl, then return to the document and write up my analysis and next ideas, then hack away. I found this to be rather disjointed.

[reply]