texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in
Date: Sun, 17 Oct 2010 21:51:11 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Michael,

On Sun, Oct 17, 2010 at 08:59:58PM +0200, Michael Lachmann wrote:
> I also think that TeXmacs could be an amazing tool for literate  
> programming. (I already use it for that...)
> I think though, that Sylvain and Sam's efforts are a bit different. I  
> would need them both.
>
> What Sylvain gives is a quick and easy way to edit a file inside  
> TeXmacs. I think this is also a good enhancement for interactive work in 
> TeXmacs. So, if I work interactively with R, I might want to edit a file 
> instead of entering expressions line by line. Or I might whip up a quick 
> perl filter for processing a file for R.

Yes.

> Sam on the other hand, gives a way to convert the whole document to  
> various things - so real "literate programming". Or parts of the  
> document.

Sure, as I said, I plan to include editable hyperlinks later this academic year.
This will make it even easier to edit external files from within TeXmacs.

> If I understand correctly, it isn't mainly intended for  
> interactive work, but to create files that can be compiled or processed 
> in other ways.

Yes.

> Of course, it could be that one can combine both. Provide a way to  
> interactively edit a file, and create it right there, but also convert  
> the whole document.

As I said before, the main problem I see with literate programming is
the fact that you have the choice between two evils:

  1) Force all developers to use the same literate programming tool:
     the TeXmacs documents become the actual source code.

  2) Clobber the native ASCII source code with special comments which
     contain directives for the literate programming tool.

I fully understand that making a decision on which evil you prefer
naturally leads to two different blends of literate programming tools.
Nevertheless, it might still be best to have a tool which
can operate in both modes: use TeXmacs documents as source code,
or use native source code.

Another challenge is to reduce the clobbering in 2) as much as possible.
One idea is to make TeXmacs grammar-aware, so that searching for a particular
piece of code becomes very robust, even in absence of special directives.
Unfortunately, this does not entirely solve the problem, because an external
person might delete or rename our particular piece of code using another editor.
Actually, the external person is not even be aware of the fact that
our piece of code was annotated.

Anyway, at a certain point, I will dive into these issues.
At the moment, I will just try to follow the ongoing experimentations.

Best wishes, --Joris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]