[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] literate programming for TeXmacs
From: |
Felix Breuer |
Subject: |
Re: [Texmacs-dev] literate programming for TeXmacs |
Date: |
Mon, 23 Jan 2006 04:52:34 +0000 |
On Sun, 22 Jan 2006 21:31:04 +0100
Joris van der Hoeven <address@hidden> wrote:
> Hi Felix and David,
>
> On Mon, Jan 16, 2006 at 12:19:33PM +0000, Felix Breuer wrote:
> > almost a year ago I published a working version of a small literate
> > programming
> > system for use with TeXmacs.
> [...]
> > I started working on a proper plugin for TeXmacs, but then realized that for
> [...]
>
> I followed a bit of your discussion.
> Let me quickly tell you a few thoughts:
>
> 1) I think that source files with TeXmacs comments (a la David) and
> TeXmacs files with special serializing/export (a la Felix)
> are both of independent interest.
To avoid misunderstandings: I think there were actually three concepts
in discussion, namely
1) David's original idea: Use TeXmacs to work on source files that have
tm markup as comments.
2) My original idea: Generate (multiple) source files (without comments)
from a single TeXmacs document.
3) What I am currently suggesting: Serialize a TeXmacs document as a
source file where TeXmacs markup is commented. (This is a variant
of David's suggestion.)
I am in favour of 3) because it seems to be the easiest way to get
a literate programming system that works both ways.
> 2) In both cases, notice that you may wish to override the standard
> load and save routines. Using the contextual overloading mechanism
> this can be done extremely elegantly, just by redefining
> load-buffer/save-buffer in case that the user included a certain
> style package. The overloaded routine would typically do some
> (un)commenting or additional serialization (i.e. generate
> the necessary "source" files when you save your document).
I will have a look. This might take some time, though. It's not that
I hate Scheme, or something. I can read and write Scheme (even though
I have not worked on a project with it) and I think it is a very elegant
language. It's just that I am having a hard time reading and
understanding TeXmacs' API.
> 3) The handling of TeXmacs comments in source files should be
> very easy to implement. Something like
>
> /* TeXmacs 1.0.5.7 markup
> ....
> end TeXmacs markup */
>
> would probably be a good marker in the case of C/C++ files.
Can the string "*/" appear in TeXmacs markup?
> 4) For the roadmap after version 1.1, I plan to include an internal
> linking mechanism based on tree obervers. This should be very robust
> and completely outdate the current linking/referencing mechanism,
> mutators and the Proclus plug-in. Also this will allow you to think
> of documents as graphs rather than trees. However, I have no idea when
> I will have time.
That is very good news. Given this plan for tree observers, I will put
my plans for clones on hold for the time being. I understand that tree
observers may be a long way off, but I think that focusing on an easy
literate serialization mechanism may gain the most. If I, at some point,
think I need clones ASAP I can still start implementing them as an
intermediate solution.
> 5) Independently from me, I think that it would be good to develop
> a "TeXmacs file system" as suggested a month or so ago on this list.
> This should be done in a server based way and the development can be
> done quite independently from TeXmacs itself (Felix: I do strongly
> recommend the use of Scheme). I think that such a file system would
> be of a great help for litterate programming too: it basically
> would consider the file system to be a big document.
That is a great idea. I have been thinking about something like this
myself after reading an article on 9P (the Plan 9 protocol). Can you
point me to the relevant posting? I had a look but couldn't find that
email.
Thanks,
Felix
Re: [Texmacs-dev] literate programming for TeXmacs, Joris van der Hoeven, 2006/01/22
- Re: [Texmacs-dev] literate programming for TeXmacs,
Felix Breuer <=