mailing-list for TeXmacs Users

[sylvain <address@hidden>]

Hi Sam,

for my part, I was rather thinking about using the lazy-input-converter
mechanism, that instruct Texmacs how to convert mathematical construct
in a session in ASCII one. Don't forget that one language may have a
notational convention differing from the other, that's why fedit is
structured with a plug-in by language.

I don't known if lazy-input-converter would work with the design of the
newfangle plug-in. If it is so, it would be something that could be
shared.

Sylvain 

Le vendredi 15 octobre 2010 à 09:21 +0100, Sam Liddicott a écrit :
> On 14/10/10 12:19, sylvain wrote: 
> > 
> > Another problem I wanted to try to solve is to explore the possibility
> > to convert Texmacs advanced typesetting into one-lined ASCII concrete
> > syntax understood by a compiler. I believe the one-dimensional one-line
> > input from the good old 70's is holding us back. Not when you program in
> > traditional languages, but when you want to program in modern languages
> > like ATS, whose text source, when forced to be one-dimensional, become
> > rapidly unreadable. Other languages I can think of that would benefit of
> > that are Agda and Haskell.
> > (The trouble is, I am stuck with a bug in my version of Texmacs
> > (1.0.7.3, Ubuntu) and didn't made much progress on this front.)
> > 
> On idea I have considered a few times is being able convert between
> source representations and rich representations, so that a pleasant
> table of initialization values can be converted to a C static array
> initializer.
> 
> Likewise, for rendering of BNF grammars, entity relationship diagrams
> and so forth.
> 
> An in effort to avoid this one dimensional stuff you speak of I cause
> the code chunks to be able to take parameters, so that an algorithm
> may be expressed generally as an abstract code chunk that can then be
> included in any file or other chunk with placeholders expanded to
> actual data references. Thus even high level concepts like generics
> are provided for 
> 
> - although meaningful typeset representations of "syntactic sugar"
> needs further examination, the "invoke paramterized chunk" notation is
> not helpful.
> 
> texmacs <with|...> construct seems a better idea. I was going to
> expand to named parameters but I now think that ZERO parameters is a
> better idea and that abstract chunks can be invoked inside some kind
> of <with|...> construct as this better suits the humans understanding
> of what is being done. It also has the effect of avoiding unwieldy
> parameter lists when an abstract chunk invokes other abstract chunks -
> instead an outer <with|...> environment can be established and then
> the chunks invoked without any parameter lists. The <with|...>
> environment can be expressed as an annotation or margin-comment at the
> point of invocation.
> 
> I'm also probably gong to avoid #line type comments in generated
> output but instead produce a separate map file, and a converter to
> convert row/column compiler errors to the document - to even work if
> the generated source has been pretty-printed. This should also
> facilliate back-annotation if someone edits the source, to take a diff
> of the edit and then backtrack to see what changes need making to the
> document (even into invoked sub-chunks).
> 
> Anyway... these are the lines of my thinking.
> 
> -- 
> [FSF Associate Member #2325]