- From: sylvain <address@hidden>
- To: address@hidden
- Subject: Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in
- Date: Fri, 15 Oct 2010 10:56:33 +0200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=dAWZWlus9sMUEbJ/9m3+QtKTw0ZlQexJUFie6Lom+YGY7BGryjY+MW9G41bfvumx3Z IGOA4jSw6UA2PEO3BLwix4DgjbmDTNnyE9rm8jAYYfbpnpZEPQc/c0iZj13ti/iP8r8J nR/6GPwWSw92qlqz3naKKRMYXInAuo7Gr/JaM=
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]
Archive powered by MHonArc 2.6.19.